tobbe@gbg.infolog.se (Tobbe Lindgren) (02/01/91)
Here is a problem I need help with. We have recently acquired a 600Mb SCSI disk. I thought I could use it on our Sun4c, but that wasn't so easy. The disk is a RZ56 (600 Mb, SCSI) from Digital, set to SCSI-ID 0. When I tried to use format, the response was: "esp0: current command timeout at target 0 lun 0" and that message was repeated several times. Actually, the disk didn't even seem to spin up. The disk IS working on a VAX though. Could someone give me a hint or tell me if it's a dead-end. Thanks in advance # Torbjorn Lindgren email: tobbe@gbg.infolog.se #
dan@breeze.bellcore.com (Daniel Strick) (03/22/91)
I don't have any DEC RZ56 disk drives to test, but I have stumbled over a similar problem with the RZ55 and RZ57 drives. The usual symptom is: esp0: current command timeout at target 0 lun 0 There is a certain SCSI bus "message" that SCSI host adapters and devices use to "negotiate" certain parameters for syncronous data transfers. Normally the host adapter sends one of these messages to a drive before the first data transfer and the drive responds with a similar message to confirm the transfer parameters. Virgin SunOS 4.0.3 running on a sun-4/60 won't send this message to a drive. Most drives will just default to asynchronous data transfers if the host adapter does not send the "synchronous data transfer request" message, but the DEC RZ drives are persistent. In this situation, the DEC RZ drives will initiate the negotiation by sending the first synchronous transfer request. This is perfectly correct behavior (according to the ANSI standard) and the host adapter must respond either by rejecting the message or by sending back another synchronous transfer request message containing compromise parameters. The sun-4/60 just sits there ... and sits there ... and eventually times out. You can work around the bug in release 4.0.3 by patching the kernel to attempt synchronous data transfers (change variable scsi_options from 0x18 to 0x38). This is not be a perfect fix because the 4.0.3 SCSI driver may decide synchronous xfers are not working right and clear the bit. I have not tested for the SCSI driver bug in SunOS releases 4.1 and 4.1.1. The rumors I have recently read in sun-spots digest say that the sun SCSI driver likes to go synchronous on the the sun-4/65 (SS1+) and sun-4/75 (SS2) but will not go synchronous on the sun-4/60 (SS1) and the old kernel patch no longer works. So if the bug is not fixed and you have sun-4/60 and a DEC RZ drive, you may be stuck. Dan Strick, aka dan@bellcore.com or bellcore!dan, (201)829-4624