Date: Wed, 29 Aug 2001 20:25:31 +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: <20010829201629.B1561-100000@gerard> In-Reply-To: <20010828162812.A31937@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Aug 2001, Kenneth D. Merry wrote: > > > Yes, that is what it looks like is happening. Apparantly it only hap= pens > > > the first time we send a read capacity to the drive. (On probe.) > > > Subsequent read capacity commands via camcontrol return CCBs with val= id > > > 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_ERR= OR > > on either CHECK CONDITION or TERMINATED STATUS. If an error occurs duri= ng > > auto-sense, the driver should either return some severe cam status valu= e, > > 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 scs= i > > 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 anot= her > > 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. > > This 1% of chance for another SCSI status to have been returned gives t= he > > 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. 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?20010829201629.B1561-100000>