Date: Thu, 3 Dec 1998 16:22:58 -0700 (MST) From: "Kenneth D. Merry" <ken@plutotech.com> To: mestery@winternet.com (Kyle Mestery) Cc: scsi@FreeBSD.ORG, gibbs@pluto.plutotech.com Subject: Re: Still errors stopping audio CDs in current Message-ID: <199812032322.QAA04772@panzer.plutotech.com> In-Reply-To: <Pine.GSO.4.05.9812031650530.4715-100000@tundra.winternet.com> from Kyle Mestery at "Dec 3, 98 04:53:02 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Kyle Mestery wrote... > On Wed, 2 Dec 1998, Justin T. Gibbs wrote: > > > I've been too swamped with 'real work' to really look into this, which is > > why I haven't commented so far. Sorry about that. > > > No problem, totally understandable. I just thought I'd keep trying new kernels > and new ways to test it until something happened. > > > I took a quick look at the cd ioctl code and did find at least one > > potential problem. When performing a CDIOEJECT, an allow media removal > > operation is not performed before issuing the stop unit command. This > > may confuse the device. This doesn't explain why we would hang waiting > > to get a CCB though. That indicates a resource tracking bug somewhere > > in the driver most likely triggered by something cdcontrol or cdplay is > > doing before the eject. A ktrace of what these programs do would be > > useful. > > > If you've seen the stuff I've told Ken, is a ktrace still necessary at this > point? If so, I can attempt to do that (never done it before). It looks to > me at least that cdcontrol isn't handling the error return from the IOCTL. > I'm not sure why the drive is returning an error at this point. ktrace isn't necessary. We're close to finding the problem. Justin confused the 'cbwait' state with the 'cgticb' state. The former means that we're waiting for a CCB to complete, and the latter means that we're waiting to get a CCB. If the cdcontrol program had been stuck in the 'cgticb' state, it would indicate a resource tracking problem of some sort. But, it was stuck in the 'cbwait' state, which is entirely different. And actually, it wasn't stuck, but rather kept entering that state over and over again. :) The problem appears to be that: - a SCSI status other than check condition is being returned - we retry indefinitely That only happens for "busy" and "queue full", and since this isn't a tagged queueing drive, I'd guess that the former is happening. Once you send me the camcontrol output from the patch I sent you in my previous message, we'll know for sure. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812032322.QAA04772>