Date: Thu, 30 Aug 2001 12:46:18 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: =?iso-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr> Cc: Thomas Quinot <thomas@cuivre.fr.eu.org>, stable@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Failure to attach SCSI CD burner Message-ID: <20010830124617.A48136@panzer.kdm.org> In-Reply-To: <20010830201620.M1625-100000@gerard>; from groudier@free.fr on Thu, Aug 30, 2001 at 08:30:27PM %2B0200 References: <20010830102820.A47131@panzer.kdm.org> <20010830201620.M1625-100000@gerard>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 30, 2001 at 20:30:27 +0200, Gérard Roudier wrote: > On Thu, 30 Aug 2001, Kenneth D. Merry wrote: > > > On Thu, Aug 30, 2001 at 09:06:01 +0200, Thomas Quinot wrote: > > > Le 2001-08-29, Thomas Quinot écrivait : > > > > > > > > Apply the attached patch in place of the one I gave you before and send the > > > > > output when you boot. This will print out the SCSI status byte. > > > > Thanks, applied, I'll let you know as soon as I get a chance to reboot. > > > > > > OK, here we are: > > > > > > (cd0:sym0:0:2:0): autosense is NOT valid > > > (cd0:sym0:0:2:0): flags = 0x40 status = 0x4c > > > (cd0:sym0:0:2:0): SCSI status = 0x8 > > > (cd0:sym0:0:2:0): got CAM status 0x4c > > > (cd0:sym0:0:2:0): fatal error, failed to attach to device > > > (cd0:sym0:0:2:0): lost device > > > (cd0:sym0:0:2:0): removing device entry > > > > > > Isn't that 'SCSI_STATUS_BUSY' ? > > > > Yes it is. Here's a patch that should fix your problem. The only SCSI > > status I've allowed through (besides check condition) is busy. The rest > > are either not likely or are grounds for failing the attach. > > > > Let me know if this fixes your problem. > > You patch seems incomplete to me. > > BUSY is a transient condition and a CD/ROM or a CD/R device is slow as a > 25 years old dog when it happens to deal with seeking. A 1 second delay > for the BUSY condition to go away does not seem to me a good compromise > here. Something like 3 seconds (and possibly 3 retries given that the > delay for a retry on BUSY status is hardcoded, but this doesn't matter a > lot) seems more appropriate, imo. In order to minimize changes in the > code, I suggest to also just make scsi_cd.c allow 3 retries for the READ > CAPACITY command, for example. One of the reasons for the low retry count on the read capacity command is that there are some HP/Philips drives (CD burners I think) that take a really long time to respond to a read capacity in some situations. (Close to the 20 second timeout.) Anyway, increasing the number of retries will just increase the amount of time that it takes for those drives to probe. (The probe time is probably somewhere on the order of (retries + 1) * 20 seconds.) In this case, I'm not failing the attach, but rather just telling the user that his drive is busy and I can't tell him the capacity at the moment. Hopefully the drive will be responding by the time he decides to mount it. (We do another read capacity in the open routine.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010830124617.A48136>