From owner-freebsd-scsi Mon Apr 12 13:24:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B2D215087 for ; Mon, 12 Apr 1999 13:24:45 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id OAA07155; Mon, 12 Apr 1999 14:22:23 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904122022.OAA07155@panzer.plutotech.com> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904121928.VAA02161@yedi.iaf.nl> from Wilko Bulte at "Apr 12, 1999 9:28:10 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Mon, 12 Apr 1999 14:22:22 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (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 Wilko Bulte wrote... > As Kenneth D. Merry wrote ... > > Hmm, there are a couple of things that could cause this. One could be that > > you're actually just beyond the stack frame that contained those variables. > > > > If you go back up into the stack frame with cdprevent(), can you take a > > look at: > > > > print /x softc->flags > > print /x softc->changer->flags > > print /x softc->pinfo.index > > > > That might help things somewhat, or maybe not, since the flags will get > > changed in the routines below that. > > A bit more luck now: > > (kgdb) frame 14 > #14 0xc012720c in cdprevent (periph=0xc0780c00, action=1) > at ../../cam/scsi/scsi_cd.c:2517 > 2517 > (kgdb) print /x softc->flags > $4 = 0xe8 Okay, so the active flag is set. > (kgdb) print /x softc->changer->flags > $5 = 0x8 And the need timeout flag is set. > (kgdb) print /x softc->pinfo.index > $6 = 0xffffffff And it isn't queued. Hmm, well, I don't quite understand why it seems to be looping. It shouldn't continue in the loop once the active flag is set. It should get the CCB and keep on going. > > > > There's a loop in cdgetccb(), and the process should get put into tsleep() > > > > inside that loop at some point. My guess is that that is not happening for > > > > some reason. The loop control elements are in the above variables, so > > > > maybe that'll tell me something. > > > > > > I'm not sure, the 'cannot access memory' might not be very helpful. > > > I can try to get a couple of other dumps if needed. > > > > Do you think you might be able to get remote GDB working? You might be > > able to get better information that way. > > I'll give it a try. Soldering iron is heating up to create a cable.. Ahh, doing it the hard way, 'eh? :) In any case, it may help to have a look at those variables with remote gdb. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message