Date: Fri, 31 Aug 2001 00:03:56 -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: <20010831000356.A52843@panzer.kdm.org> In-Reply-To: <20010830221204.D1851-100000@gerard>; from groudier@free.fr on Thu, Aug 30, 2001 at 10:22:24PM %2B0200 References: <20010830124617.A48136@panzer.kdm.org> <20010830221204.D1851-100000@gerard>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 30, 2001 at 22:22:24 +0200, Gérard Roudier wrote: > On Thu, 30 Aug 2001, Kenneth D. Merry wrote: > > On Thu, Aug 30, 2001 at 20:30:27 +0200, Gérard Roudier wrote: > > [...] > > > > 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.) > > Ok. I ignored that. > > > 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.) > > Then the handling of the BUSY condition should rather (also?) be based on > a timeout condition than on a retry count. You mean we should wait a specific amount of time? I think one second (the current timeout for the SCSI BUSY status) is enough for some devices to become ready, but perhaps not others. My guess is that the best way to handle it is by tuning the retry count. But, as I pointed out above, that causes other problems. > > 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.) > > Let user put a media and be hurried for some reasons :) to mount it and a > spurious mount failure may happen. True enough. That could be remedied, perhaps, by a higher retry count on the read capacity in the open() routine. > Btw, we obviously can live with the 1 retry handling on BUSY. This is > indeed not a very serious problem. I agree, it's not a big problem. 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?20010831000356.A52843>