Date: Sun, 11 Apr 1999 23:40:56 -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: <199904120540.XAA02746@panzer.plutotech.com> In-Reply-To: <199904102034.WAA03553@yedi.iaf.nl> from Wilko Bulte at "Apr 10, 1999 10:34:41 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Wilko Bulte wrote...
> > > - 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.
Well, it shouldn't swap for long. Once the mount finishes, it'll just keep
reading off of cd0.
> I sort of expected that the mount would lock the cd into the drive,
> changer or not.
No, it won't. The idea of the LUN-based changer code in the CD driver is
to allow you to do I/O to *all* CDs in the changer, but not all at the same
time.
The changer will switch the CD that corresponds to the LUN that is getting
I/O at the time. One problem that some of these changers have is that if
you switch too rapidly back and forth between LUNs, they get confused and
kinda lock up. By enforcing a minimum amount of time on each LUN, the CD
driver not only avoids lockups, but also increases performance somewhat.
> > > 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
Looks like you're missing a stack frame here, but from your earlier stack
trace and from the code I know that the only way to get to
cdrunchangerqueue() from cdprevent() is via cdgetccb().
> #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)
Okay, good. Looks like you probably broke into the debugger while it was
going out of the scheduling function. Now, can you print out some values
for me:
print /x softc->flags
print /x changer->flags
print /x softc->pinfo.index
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.
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?199904120540.XAA02746>