Date: Mon, 12 Apr 1999 19:37:56 +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: <199904121737.TAA00622@yedi.iaf.nl> In-Reply-To: <199904120540.XAA02746@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 11, 1999 11:40:56 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
As Kenneth D. Merry wrote ...
> 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.
OK, I have not really tried a whole lot of this.
> > 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.
Ah! This clarifies this neatly. Thanks.
> > > It would be nice if you could give me:
> > >
> > > - a stack trace using a kernel with debugging symbols
[snip]
> 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().
This is all what gdb gives me.
> > 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
Gives:
(kgdb) frame 13
#13 0xc0125b17 in cdrunchangerqueue (arg=0xc0780c00)
at ../../cam/scsi/scsi_cd.c:1225
1225 }
(kgdb) print /x softc->flags
Cannot access memory at address 0x80000010.
(kgdb) print /x changer->flags
$1 = 0x0
(kgdb) print /x softc->pinfo.index
Cannot access memory at address 0x80000008.
(kgdb)
> 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.
I'm not sure, the 'cannot access memory' might not be very helpful.
I can try to get a couple of other dumps if needed.
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?199904121737.TAA00622>