NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/sys/amiga/hardware/15028

Internet Message Format | 1992-09-08 | 7.7 KB

Path: sparky!uunet!dtix!darwin.sura.net!jvnc.net!netnews.upenn.edu!dsinc!bagate!cbmvax!cbmehq!cbmger!edomdo!manfred
From: [e-mail] (Manfred Dolag)
Newsgroups: comp.sys.amiga.hardware
Subject: Re:  Re: SCSI-Streamer on A3000
Message-ID: <[e-mail]>
Date: 4 Sep 92 17:48:44 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Edotronik GmbH
Lines: 172

In article <[e-mail]> [e-mail] (Chris Wolf) writes:
>In article <[e-mail]> [e-mail] (Tom R Krotchko) writes:
>>>Well, I finally tracked down Tandberg Data USA, and I have better answers
>>>about the Tandberg 3600 refurbs from RS6000's.
>>>
>>>There are two fixes for this drive. The first is to get a new "bios" for the
>>
>>I did order the new BIOS for the drive, and guess what: it worked worse than
>>before. I replaced with it with the original U07 BIOS and it worked as "well"
>>as it had before. Tandberg would not take the BIOS back, BTW, even though I
>>bought it on their advice (just a minor update, the price is $40, no $60 as the
>
>>The key here is the Tandberg seems to drive other SCSI controllers bananas
>>the way it does asynchronous writes. I suspect is has to do with how slow the
>>drive writes to the tape (a block takes several seconds to write).
>>
>>I have it working by turning reselect off. Using the GVP, there is a command
>>that does this. The net effect is the backups go about twice as slow as they
>>would otherwise, but they work.
>
>>Tom Krotchko
>
>
>Wait a sec!  I missed the original post describing the Tandberg problems
>some people are having.  Could someone send me a copy or synopis of them?
>
>I just acquired a Tandberg 3600 drive (150/250 mb) that was supposedely
>a refurb pulled from an RS6000 and it has worked flawlessly for me so I
>am interested in hearing what problems other people are having.  I do not
>know the EEPROM or BIOS revisions on the drive.  The system I am using it
>in is an A3000T with AmiBack 2.0 software.  I have used it to back-up and
>restore MANY megs of data (and am using it as I type this as a matter of
>fact) with never a problem.  I do not need to turn reselect off and I do not
>experience any noticeable slowdown - AmiBack keeps the tape streaming
>constantly and I get data transfer rates of about 5 megs/min.    The only
>thing I had to do was set IO mode to Synchronous instead of Asynchronous
>on the AmiBack tape configuration window or else AmiBack reported some
>spurious errors.
>
>                            - Chris
>
>--
>
>   --------------------------------------------------------------------
>   Christopher Wolf    mail: [e-mail]    IRC: cwolf
>   --------------------------------------------------------------------

--

Problems with Tandberg Streamer 3600 Series BIOS 07:29


The Tandberg Streamer has problems with a WD33C93A SCSI controller used in
the Commodore Amiga 3000 and the C= SCSI board 2091.
After a Control Descriptor Block is transmitted to the streamer it usually
responds with a Message In Phase. Sometimes, though, the WD33C93A sets a
different status message which says it is expecting another CDB transfer
instead of a Message In phase. As the streamer is in a Message In Phase now
and the device driver tries to resend the CDB there is confusion which
leads to a complete hangup of the SCSI bus.

This is a protocol with comments that records all state changes in the
WD33C93A when a small test program tries to repeatedly write blocks of 512
bytes junk data to the streamer.

    Last CMD:        The last WD33C93A command issued in the
            Command Register 0x18
    DMA:        State of the Amiga DMA Controller (private)
    AUX:        Contents of the Auxiliary Status Register when
            the WD33C93A last sent an interrupt.
    SCSI:        Contents of the SCSI Status Register when
            the WD33C93A last sent an interrupt.

The WD33C93A is clocked with ca. 14MHz. Frequency select in the OWN ID/CDB
SIZE Register is therefore set to 1. The SYNCHRONOUS TRANSFER REGISTER is
set to 0x40 which means a SCSI/WD-BUS Transfer Period of 4 cycles with a
cycle time of ca. 100ns. according to the WD Data Sheets.

All values are hex.


>SDBG started...

This is the standard transmission of a 512 byte block. It always looks the
same when no error occurs:

> New Job... WD33C93A-Settings
>  OwnID:  7   Advanced Features: 0  Host Parity: 0  Frequency: 1
>
>  State -- Last CMD: 06, DMA: D1, AUX: 80, SCSI: 11
>  State -- Last CMD: 06, DMA: D1, AUX: 80, SCSI: 8E
>  State -- Last CMD: A0, DMA: D1, AUX: 80, SCSI: 1A

SCSI 1A tells us that the device driver should send a CDB to the streamer.

>  CDB Length: 0006 Data: 0A 01 00 00 01 00
>  State -- Last CMD: 20, DMA: D1, AUX: 80, SCSI: 1F

After CDB transmission with the WD33C93A command "Transfer" 0x20 we usually
get the SCSI state 1F which tells us that a Message In Phase is requested.
The streamer sends us 02, the transmission was Ok:

>  MessageIn: 02     OkFlag: FF

Now the rest of the block transfer follows:

>  State -- Last CMD: A0, DMA: D1, AUX: 80, SCSI: 20
>  State -- Last CMD: 03, DMA: D1, AUX: 80, SCSI: 8F
>  State -- Last CMD: A0, DMA: D1, AUX: 80, SCSI: 20
>  State -- Last CMD: 03, DMA: D1, AUX: 80, SCSI: 85
>  State -- Last CMD: 03, DMA: D1, AUX: 80, SCSI: 80
>  State -- Last CMD: 03, DMA: D1, AUX: 80, SCSI: 8F
>  State -- Last CMD: A0, DMA: D1, AUX: 80, SCSI: 20
>  State -- Last CMD: 03, DMA: D1, AUX: 80, SCSI: 88
>  State -- Last CMD: 20, DMA: D2, AUX: 80, SCSI: 1B
>  State -- Last CMD: 09, DMA: D2, AUX: 80, SCSI: 16
>  State -- Last CMD: 09, DMA: D2, AUX: 80, SCSI: 85

[...] (Several "New Job..." block transfers deleted)

Here we have a block transfer like the ones before. But now we have some
sort of timing or handshake problem which confuses the WD33C93A.


>
>New Job...
>WD33C93A-Settings
>  OwnID:  7   Advanced Features: 0  Host Parity: 0  Frequency: 1
>
>  State -- Last CMD: 06, DMA: D1, AUX: 80, SCSI: 11
>  State -- Last CMD: 06, DMA: D1, AUX: 80, SCSI: 8E
>  State -- Last CMD: A0, DMA: D1, AUX: 80, SCSI: 1A

Again there is SCSI 1A, a request for the CDB

>  CDB Length: 0006 Data: 0A 01 00 00 01 00
>  State -- Last CMD: 20, DMA: D1, AUX: 80, SCSI: 1A

************************************
*** Here we have the deadly bug! ***
************************************

We don't get the usual SCSI 1F for Message In but instead we get SCSI 1A
again for CDB transmission. This makes no sense whatsoever but the state
machine of the device driver is trusting the WD33C93A.

>  CDB Length: 0006 Data: 0A 01 00 00 01 00
>  State -- Last CMD: 20, DMA: D1, AUX: 80, SCSI: 41
>  State -- Last CMD: 20, DMA: D1, AUX: 80, SCSI: 80

The CDB is retransmitted and then we get some two "junk" states because of
this unexpected change in SCSI behaviour. Now the device drivers state
machine is completely confused and at this point the machine hangs.

Either the WD33C93A is under certain conditions unable to identify the
Message In phase correctly or the streamer bios is "messing up" the SCSI
timing.

This bug is *always* reproducible even though it might not show up until
several block transfers completed successfully!

It does *not* occur if we use the same CDB with a length >6 filled up with
zero! With a CDB length > 7 the device driver always gets a SCSI state of
0x4F "unexpected phase Message In" instead of the "correct" state 0x1F
after CDB transmission. The device driver can handle this difference and
proceedes correctly.

--
Manfred Dolag, Edotronik GmbH (ECG018), Tel. [phone], FAX [phone]
St.-Veit-Str. 70, 8000 Muenchen 80, Germany
-*-*-  for email from outside of Commodore Developer Group please use:    -*-*-
-*-*-*-    Path: cbmehq!cbmger!edomdo![e-mail]    -*-*-*-