Date: Fri, 9 Apr 1999 21:54:43 +0200 (CEST) From: Wilko Bulte <wilko@yedi.iaf.nl> To: ken@plutotech.com (Kenneth D. Merry) Cc: freebsd-scsi@freebsd.org Subject: Re: Getting Pioneer CD changer to work Message-ID: <199904091954.VAA15091@yedi.iaf.nl> In-Reply-To: <199904091714.LAA17078@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 9, 1999 11:14: 6 am"
next in thread | previous in thread | raw e-mail | index | archive | help
As Kenneth D. Merry wrote ... > Wilko Bulte wrote... > > As Kenneth D. Merry wrote ... > > > Wilko Bulte wrote... > > > > As Kenneth D. Merry wrote ... > > > > > Wilko Bulte wrote... > > > > > > As Kenneth D. Merry wrote ... > > > > > > > Wilko Bulte wrote... > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > Wilko Bulte wrote... > > > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > > > Wilko Bulte wrote... > > > > > > 'Most any' appears to be the right term for it ;) I'll experiment a bit > > > > > > more. Just go a solid system lockup by running a 'dd if=/dev/rcd0a' and > > > > > > a 'mount /dev/cd1a ...' at the same time. Only ping still works. Hmm. > > > > > > More testing to do I guess > > > > > > > > > > Hmm, interesting. What happens if you just try the DD? Can you break into > > > > > the debugger when the machine locks up? > > > > > > > > I made a new kernel with the debugger in. I'll have it run overnight to see > > > > if it re-occurs. In the meantime there was also a spontaneous reboot. No > > > > panic as far as I can see. I'll try to reproduce.. Just the DD seems > > > > to work just fine. > > > > > > Hmm, sounds strange indeed. > > > > In the meantime I ran the test again. No machine lockup this time. But > > already twice a solid lockup of the drive.. It goes completely comatose, > > not even a SCSI reset from a FreeBSD reboot awakens it. The only thing > > what works is a whack over the head with the powerswitch. This definitely > > is a brilliant piece of firmware I have. I can reproduce a lockup now. But this one looks like a FreeBSD bug to me: - do a 'dd if=/dev/rcd0a of=/dev/null ibs=2k & - do a 'mount -r -t cd9660 /dev/cd2a /mnt' Result: bang! Console lockups, no network logins anymore. I can get into ddb fortunately and can force a dump. But I'm not an expert on gdb -k. A quick try produced: dump 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 0xc015cb43 in boot () (kgdb) bt #0 0xc015cb43 in boot () #1 0xc015cde1 in panic () #2 0xc012ab29 in db_panic () #3 0xc012aac9 in db_command () #4 0xc012ab8e in db_command_loop () #5 0xc012cf0f in db_trap () #6 0xc021e5ce in kdb_trap () #7 0xc022aee4 in trap () #8 0xc021e7f3 in Debugger () #9 0xc0219e60 in scgetc () #10 0xc0214be0 in sckbdevent () #11 0xc02115bb in atkbd_intr () #12 0xc022ee68 in atkbd_isa_intr () #13 0xc0127ad3 in cdrunchangerqueue () #14 0xc0127cbe in cdgetccb () #15 0xc01291f0 in cdprevent () #16 0xc0127633 in cdopen () #17 0xc018bbcb in spec_open () #18 0xc018b9b5 in spec_vnoperate () #19 0xc0201f8d in ufs_vnoperatespec () #20 0xc01860da in vn_open () #21 0xc0182b35 in open () #22 0xc022b71f in syscall () #23 0xc021ef1c in Xint0x80_syscall () #24 0x8048361 in ?? () #25 0x80480e9 in ?? () (kgdb) If you want the dump & kernel to go to an ftp area somewhere plse let me know. It is approx 6Mb in total (gzipped). If you want me to whisper magical words to gdb please tell me which words. ----- Seems I've also found why other people using DRM604X changers might be happier. This is from the xmcd docs: .... "Pioneer DRM-604X units with revisions of the firmware prior to 2403 must be configured to operate in the SCSI-1 mode (DRM-600 emulation, via back panel DIP switches), and xmcd/cda must be configured as if it's operating a DRM-600. Newer DRM-604X units (firmware version 2403 and later) can be set up to run in SCSI-2 mode, and xmcd/cda must be set up accordingly. " .... Guess what: I have firmware 2401. The hunt for something newer is on obviously. A quick look into xmcd's vu_pion.h learned: /* Pioneer vendor-unique commands */ #define OP_VP_EJECT 0xc0 /* Pioneer magazine eject */ #define OP_VP_RDTOC 0xc1 /* Pioneer read TOC */ If I replace the standard READ TOC (0x43) by 0xC1 I get a driver that seems to work just fine. No errors anymore with a mount. Obviously my 'normal' Toshiba CD now complains. So: it seems some type of quirk mechanism is needed. Looking at xmcd again I find a disturbing number of vendor-unique support files for non-SCSI2 drives: ! 0 SCSI-2 standard ! 1 Chinon vendor-unique ! 2 Hitachi vendor-unique ! 3 NEC vendor-unique ! 4 Pioneer vendor-unique ! 5 Sony vendor-unique ! 6 Toshiba vendor-unique ! 7 Panasonic/Matsushita vendor-unique I don't think it is wise to clutter the scsi_cd driver with all this junk. There is more vendor unique stuff around than just the READ TOC (like, surprise surprise, the play audio commands etc) Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ http://www.freebsd.org _____ 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?199904091954.VAA15091>