Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!mcnc!rti!bnrunix!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: dan@breeze.bellcore.com (Daniel Strick)
Newsgroups: comp.sys.sun
Subject: Re: Problems formatting disk
Keywords: Hardware
Message-ID: <2038@brchh104.bnr.ca>
Date: 21 Mar 91 21:31:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 35
Approved: Sun-Spots@rice.edu
X-Original-Date: Fri, 15 Mar 91 02:12:33 -0500
X-Refs:  Original: v10n34
X-Sun-Spots-Digest: Volume 10, Issue 60, message 1
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

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