Problems with Delta Micro 8mm Tape Drive on 4D/20
Dave Olson
olson at anchor.sgi.com
Fri May 4 08:14:01 AEST 1990
In article <11582 at netcom.UUCP> dahl at netcom.UUCP (Michael Dahl) writes:
| We have attached a Delta Micro Systems SS-2000T 8mm tape drive to
| our 4D/20 and are having a couple of problems that make it very
| difficult to use.
| Power-on diagnostics will fail unless the tape drive is turned on,
| and the system disk will be corrupted unless the tape drive is
| powered on when unix boots. It takes a couple hours to reload the
| system software when the disk gets corrupted. The disk also gets
| corrupted if the system auto-reboots for any reason.
This kind of error happens with many SCSI devices. Basicly, when the drive
isn't powered up, the SCSI bus lines get pulled low, which is the active
state (or in some cases, certain lines may toggle, depending on capacitor
charges on the circuit boards, etc.
This results in all kinds of SCSI errors, including data getting
written to the incorrect block etc. in some cases. The solution is to
either have it powered up, or disconnect it from the SCSI bus if you aren't
going to use it (before powering up, of course). The SCSI 2 spec recommends
that vendors design their interface to be safe if the power isn't on, but
relatively few vendors have so far done so; Exabyte is not among them.
| The following is the error we get if the tape drive is turned on
| during power-on diagnostics:
| sc0 Unexpected Transfer Phase. State= 4b Phase= 31
| scsi(0, 3, 0) transfer aborted (Hardware error)
| Device 3 failed DMA test
| doscsi: sc0 error: Hardware timeout
This is because Exabyte does something different than any other vendor
of SCSI devices that I have seen; namely, when a command is sent to
them that they don't support (writebuffer in this case), they go to a
status phase after the first byte of the command. They are fixing
their firmware to do what all other vendors do, which is to accept all
bytes of the comamnd, and then return ILLEGAL REQUEST.
If your Personal Iris CPU prom revision is Feb. 1989 or later, then you
can 'setenv bootmode C' in the prom monitor to suppress running the
SCSI diagnostics entirely (for all SCSI devices). Use the command
'version' in the PROM monitor to determine your PROM revision.
(You can set it for earlier revisions, but it won't suppress the SCSI
diagnostics.)
Dave Olson
Life would be so much easier if we could just look at the source code.
More information about the Comp.sys.sgi
mailing list