From owner-freebsd-scsi Mon Apr 12 14: 0: 3 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 31CFA150DA for ; Mon, 12 Apr 1999 13:59:57 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id OAA07372; Mon, 12 Apr 1999 14:57:32 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904122057.OAA07372@panzer.plutotech.com> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904122033.WAA02864@yedi.iaf.nl> from Wilko Bulte at "Apr 12, 1999 10:33:12 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Mon, 12 Apr 1999 14:57:32 -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 ... > > > That might help things somewhat, or maybe not, since the flags will get > > changed in the routines below that. > > > > > > 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. > > Correct me if I'm wrong but I think I just hit a brick wall: > > - my testbox with the Pioneer changer on it is 4.0-current > - my 'production' box is 2.2.8-stable > > What I need to do a remote kdebug is a gdb running on 2.2.8 (so aout itself) > while at the same time smart enough to understand elf (the 4.0-current > kernel). > > Would/should the following work: > > - export OBJFORMAT=aout on the 4.0 machine > - run a local make in /usr/src/gnu/usr.bin/gdb > - take the resulting gdb binary to the 2.2.8 machine > ? > > Or is this cutting too many corners? Maybe also link gdb static? Yikes. You might be able to get away with it if you run a statically linked ELF gdb from your 4.0 box on your 2.2.8 box. I'm not sure, though. Obviously you'll need the source and binaries on your 2.2.8 box, which I assume you'll compile over NFS from the 4.0 box. That might work, but I'm really no expert on this. All of my machines are ELF now, running either -current or 3.1-stable. > Alternative: could I use a 4.0-current *Alpha* box to remotely gdb? I.e. > can gdb read other architectures execs/dumps? Probably not I guess.. I doubt that'll work. Wouldn't you need an i386 gdb to understand the debugging kernel and talk over the serial port? One other thing that would work is you could send me the changer. :) Of course the postage from there would probably be more than the thing is worth...and then there's customs and all. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message