Date: Sun, 01 Nov 1998 17:03:23 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Bernd Walter <ticso@cicely.de> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, current@FreeBSD.ORG Subject: Re: scsi disk (cam?) problems Message-ID: <199811020010.RAA04209@pluto.plutotech.com> In-Reply-To: Your message of "Mon, 02 Nov 1998 00:10:58 %2B0100." <19981102001058.41129@cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
>> pack is being invalidated is that the drive in question is not >> responding within a selection timeout period (250ms). This is >That's long - but I don't know how the drive handles media-errors. >At least my Win-NT Host on which the drive was connected before >has done serveral bus-resets in case of an media-problem. >They were reproduceable on the same sectors. >So maybe the firmware s broken. A media error may result in a command timeout, but not a selection timeout. A selection timeout occurs when you attempt to select a device in order to pass it a command. A command timeout occurs once you have issues a command to a device and are waiting for it to complete. If this MO device does not support tagged queuing, the selection timeout could only occur when we attempted to select it and the device was idle. >If it was a complete power-on reset the old SCSI-code would have given >me some information about during the next access - I asume CAM is doing >the same. It should print out an error, yes. In this case, we get the selection timeout first and stop talking to the device before we can even see that a unit attention event has occurred. >What I don't understand is why the system can't recover from that failure. >as mentioned earlier the drive is still accessable via camcontrol but not >via the mounted fsdriver. Because the driver wants to be sure you, the user, validate that the device has not been changed. You must unmount the device and remount it in order to use it. Only once all clients that had the da device open when the 'catastrophic' error occurred have closed the device will it accept and open and I/O again. The pass-thru device, as used by camcontrol, just passes commands directly to the device, and it doesn't perform the same kinds of tracking that the 'da' block device driver does. Just because the underlying device is the same does not mean that you are talking through the same driver. Multiple drivers can share the same underlying SCSI device in CAM. >> I will change the error handler for the selection timeout case to >> return EIO instead of ENXIO, but this is just a temporary work around > >By the way I'm not so deep into this - what are the differences? One says that there is no device there. The other indicates a per -transaction I/O error. EIO is retried, ENXIO is not. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811020010.RAA04209>