From owner-freebsd-scsi Sun Apr 11 22:43:21 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 55B0815014 for ; Sun, 11 Apr 1999 22:43:18 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id XAA02746; Sun, 11 Apr 1999 23:40:56 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904120540.XAA02746@panzer.plutotech.com> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904102034.WAA03553@yedi.iaf.nl> from Wilko Bulte at "Apr 10, 1999 10:34:41 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Sun, 11 Apr 1999 23:40:56 -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... > > > - 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