From owner-freebsd-stable Thu Aug 30 13:27:54 2001 Delivered-To: freebsd-stable@freebsd.org Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by hub.freebsd.org (Postfix) with ESMTP id 3300A37B406; Thu, 30 Aug 2001 13:27:46 -0700 (PDT) (envelope-from groudier@free.fr) Received: from nas-cbv-8-16-213.dial.proxad.net (nas-cbv-8-16-213.dial.proxad.net [213.228.16.213]) by postfix1-2.free.fr (Postfix) with ESMTP id 6909BAB363; Thu, 30 Aug 2001 22:25:14 +0200 (CEST) Date: Thu, 30 Aug 2001 22:22:24 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-X-Sender: To: "Kenneth D. Merry" Cc: Thomas Quinot , , Subject: Re: Failure to attach SCSI CD burner In-Reply-To: <20010830124617.A48136@panzer.kdm.org> Message-ID: <20010830221204.D1851-100000@gerard> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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