From owner-freebsd-scsi Thu Dec 3 15:23:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA11349 for freebsd-scsi-outgoing; Thu, 3 Dec 1998 15:23:19 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA11344 for ; Thu, 3 Dec 1998 15:23:16 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id QAA04772; Thu, 3 Dec 1998 16:22:59 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199812032322.QAA04772@panzer.plutotech.com> Subject: Re: Still errors stopping audio CDs in current In-Reply-To: from Kyle Mestery at "Dec 3, 98 04:53:02 pm" To: mestery@winternet.com (Kyle Mestery) Date: Thu, 3 Dec 1998 16:22:58 -0700 (MST) Cc: scsi@FreeBSD.ORG, gibbs@pluto.plutotech.com X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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