Date: Wed, 29 Aug 2001 15:46:46 -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: <20010829154646.A40267@panzer.kdm.org> In-Reply-To: <20010829201629.B1561-100000@gerard>; from groudier@free.fr on Wed, Aug 29, 2001 at 08:25:31PM %2B0200 References: <20010828162812.A31937@panzer.kdm.org> <20010829201629.B1561-100000@gerard>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 29, 2001 at 20:25:31 +0200, Gérard Roudier wrote: > On Tue, 28 Aug 2001, Kenneth D. Merry wrote: > > > > > Yes, that is what it looks like is happening. Apparantly it only happens > > > > the first time we send a read capacity to the drive. (On probe.) > > > > Subsequent read capacity commands via camcontrol return CCBs with valid > > > > sense data and the CAM_AUTOSNS_VALID flag set. > > > > > > I double-checked the sym driver source and didn't find any code path > > > explaining such behaviour. I mean, the driver returning SCSI_STATUS_ERROR > > > on either CHECK CONDITION or TERMINATED STATUS. If an error occurs during > > > auto-sense, the driver should either return some severe cam status value, > > > or indicate that sense data are not valid in the cam status. > > > > Well, it looks like it's doing just that -- returning > > CAM_SCSI_STATUS_ERROR, but without the CAM_AUTOSNS_VALID flag set. > > > > > It would have been fine to also display out the actual value of the scsi > > > status returned by the device. Being 100% sure is far better than only > > > 99%. :) > > > Let me suggest Thomas to add such a trace to scsi_cd.c and to give another > > > try with his CD burner. > > > > The patch I gave him does this -- the status is 0x4c, which is > > CAM_SCSI_STATUS_ERROR | CAM_DEV_QFRZN. (See above.) > > I didn't miss a single bit, but have been unclear in my reply. Ahh. > > > This 1% of chance for another SCSI status to have been returned gives the > > > following scenario some chance to happen. :) > > > > > > The read capacity is performed with 1 retry max by the cd driver. > > > > > > 1) The device returns SCSI_STATUS_BUSY. > > > 2) 1 second later the retry is performed. > > > 3) The device still returns SCSI_STATUS_BUSY. > > > 4) cam_periph_errof() return EIO. > > > 5) then the problem reported by Thomas does happen. > > > > > > I may be wrong, obviously. Sorry if I am. > > > > You've got a point, it may well be returning busy instead of check > > condition. I'll send him another patch to check for that. > > Some other not good SCSI statuses are also candidate in theory, but very > unlikely given the situation. Even if the situation I described does not > apply to our problem (we will know very soon), it can indeed happen and > should be considered as a potential problem, in my opinion. True enough, I'll need to figure out what I want to do when the status is busy. (i.e. attach or not attach. I'll probably just attach.) 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?20010829154646.A40267>