Date: Sat, 10 Apr 1999 22:34:41 +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: <199904102034.WAA03553@yedi.iaf.nl> In-Reply-To: <199904100145.TAA19784@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 9, 1999 7:45:32 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > - do a 'dd if=/dev/rcd0a of=/dev/null ibs=2k &
> > - do a 'mount -r -t cd9660 /dev/cd2a /mnt'
The above sequence of commands will reproduce the lockup.
Doing:
- do a 'mount -r -t cd9660 /dev/cd2a /mnt'
- do a 'dd if=/dev/rcd0a of=/dev/null ibs=2k &
will work and will just drive the changer nuts with swapping discs.
I sort of expected that the mount would lock the cd into the drive,
changer or not.
> > 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
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xc0147ad9 in panic (fmt=0xc02182fc "from debugger")
at ../../kern/kern_shutdown.c:448
#2 0xc0128b45 in db_panic (addr=-1071661537, have_addr=0, count=-1,
modif=0xc36048ac "") at ../../ddb/db_command.c:432
#3 0xc0128ae5 in db_command (last_cmdp=0xc024eac4, cmd_table=0xc024e924,
aux_cmd_tablep=0xc0260988) at ../../ddb/db_command.c:332
#4 0xc0128baa in db_command_loop () at ../../ddb/db_command.c:454
#5 0xc012af2b in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6 0xc01fbbfa in kdb_trap (type=3, code=0, regs=0xc360499c)
at ../../i386/i386/db_interface.c:157
#7 0xc02088f8 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1071714996,
tf_esi = 134, tf_ebp = -1017099808, tf_isp = -1017099836, tf_ebx = 0,
tf_edx = -1071355968, tf_ecx = -1072984320, tf_eax = 38, tf_trapno =
3,
tf_err = 0, tf_eip = -1071661537, tf_cs = 8, tf_eflags = 582,
tf_esp = -1071355984, tf_ss = -1071367167}) at
../../i386/i386/trap.c:549
#8 0xc01fbe1f in Debugger (msg=0xc0243c01 "manual escape to debugger")
at ../../i386/i386/db_interface.c:317
#9 0xc01f74bc in scgetc (kbd=0xc0271ee4, flags=2)
at ../../dev/syscons/syscons.c:3714
#10 0xc01f223c in sckbdevent (thiskbd=0xc0271ee4, event=0, arg=0x0)
at ../../dev/syscons/syscons.c:816
#11 0xc01eec17 in atkbd_intr (kbd=0xc0271ee4, arg=0x0)
at ../../dev/kbd/atkbd.c:561
#12 0xc020a4f0 in atkbd_isa_intr (unit=0) at ../../i386/isa/atkbd_isa.c:84
#13 0xc0125b17 in cdrunchangerqueue (arg=0xc0780c00)
at ../../cam/scsi/scsi_cd.c:1225
#14 0xc012720c in cdprevent (periph=0xc0780c00, action=1)
at ../../cam/scsi/scsi_cd.c:2517
#15 0xc01256a7 in cdopen (dev=1568, flags=1, fmt=24576, p=0xc336b5a0)
at ../../cam/scsi/scsi_cd.c:915
#16 0xc0175e07 in spec_open (ap=0xc3604e2c)
at ../../miscfs/specfs/spec_vnops.c:235
#17 0xc0175bf1 in spec_vnoperate (ap=0xc3604e2c)
at ../../miscfs/specfs/spec_vnops.c:129
#18 0xc01df5b9 in ufs_vnoperatespec (ap=0xc3604e2c)
at ../../ufs/ufs/ufs_vnops.c:2327
#19 0xc017030e in vn_open (ndp=0xc3604f00, fmode=1, cmode=3300)
at vnode_if.h:163
#20 0xc016cd69 in open (p=0xc336b5a0, uap=0xc3604f94)
at ../../kern/vfs_syscalls.c:972
#21 0xc0209133 in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 0,
tf_esi = -1077944881, tf_ebp = -1077945340, tf_isp = -1017098268,
tf_ebx = -1077945100, tf_edx = -1077944891, tf_ecx = 3, tf_eax = 5,
tf_trapno = 12, tf_err = 2, tf_eip = 134517904, tf_cs = 31,
tf_eflags = 662, tf_esp = -1077946172, tf_ss = 47})
at ../../i386/i386/trap.c:1101
#22 0xc01fc54c in Xint0x80_syscall ()
#23 0x8048361 in ?? ()
#24 0x80480e9 in ?? ()
> - 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())
Like this?
(kgdb) frame 13
#13 0xc0125b17 in cdrunchangerqueue (arg=0xc0780c00)
at ../../cam/scsi/scsi_cd.c:1225
1225 }
(kgdb) list
1220 * switch time.
1221 */
1222 changer->flags |= CHANGER_NEED_TIMEOUT;
1223
1224 splx(s);
1225 }
1226
1227 static void
1228 cdchangerschedule(struct cd_softc *softc)
1229 {
(kgdb)
> 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.
OK.
> > ! 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.
xmcd took the approach of different VU support files for the non-standard
commands.
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?199904102034.WAA03553>