Date: Fri, 9 Apr 1999 19:45:32 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: wilko@yedi.iaf.nl (Wilko Bulte) Cc: freebsd-scsi@freebsd.org Subject: Re: Getting Pioneer CD changer to work Message-ID: <199904100145.TAA19784@panzer.plutotech.com> In-Reply-To: <199904091954.VAA15091@yedi.iaf.nl> from Wilko Bulte at "Apr 9, 1999 9:54:43 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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... > > > > > > > > > > > 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' Okay, so you're doing I/O to two devices at once. I would still like to see what happens if you increase the minimum timeout. > 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. It would be nice if you could give me: - a stack trace using a kernel with debugging symbols - a listing of the location in cdrunchangerqueue() where you broke into the debugger. (just type 'list' in gdb while you're at the stack frame that's in cdrunchangerqueue()) In a way, this smells like some sort of infinite loop in the changer scheduling code. I thought I fixed the infinite loop problem a long time ago, although I suppose I may have missed a case or two. If I can figure out where the loop is happening, I may be able to fix the problem. Once you show me where the thing is looping, I may ask as well for the values of some variables that control the loop. [ ... ] > 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) Well, I think it may be possible to put some quirk entries in for various commands, but perhaps we can just restrict it to devices we can test on. Things will be somewhat easier if the CDB format is the same, but the opcodes are different. That's rarely the case, though. The solution to the problem will depend on the scope of the device's vendor-uniqueness. If it's just the READ TOC call that's different, and only the opcode is different from SCSI-2, a quirk entry and an if statement in cdreadtoc() will be sufficient. If this drive has a large number of vendor-unique commands, I'll probably create a scsi_cd_pioneer.c with the vendor-specific commands in it, and then have a table of functions in the softc or something. The function table would be loaded in cdregister() based on a quirk entry. 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?199904100145.TAA19784>