Date: Thu, 30 Aug 2001 22:22:24 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr> To: "Kenneth D. Merry" <ken@kdm.org> Cc: Thomas Quinot <thomas@cuivre.fr.eu.org>, <stable@FreeBSD.ORG>, <scsi@FreeBSD.ORG> Subject: Re: Failure to attach SCSI CD burner Message-ID: <20010830221204.D1851-100000@gerard> In-Reply-To: <20010830124617.A48136@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 Aug 2001, Kenneth D. Merry wrote: > On Thu, Aug 30, 2001 at 20:30:27 +0200, G=E9rard 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 REA= D > > CAPACITY command, for example. > > One of the reasons for the low retry count on the read capacity command i= s > 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. (Clos= e > 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 probabl= y > 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. > In this case, I'm not failing the attach, but rather just telling the use= r > 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= =2E > (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. Btw, we obviously can live with the 1 retry handling on BUSY. This is indeed not a very serious problem. G=E9rard. 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?20010830221204.D1851-100000>