Date: Mon, 12 Apr 1999 12:58:15 -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: <199904121858.MAA06429@panzer.plutotech.com> In-Reply-To: <199904121737.TAA00622@yedi.iaf.nl> from Wilko Bulte at "Apr 12, 1999 7:37:56 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Wilko Bulte wrote...
> 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.
Good. The minimum timeout is the guaranteed minimum amount of time that
the changer code will spend on a given LUN. The time is calculated
starting from the first command *returned* from the given LUN, so the
driver doesn't include switch time in the amount of time spent on a LUN.
The maximum timeout is the maximum amount of time that will be spent on a
given LUN, iff there is I/O pending for another LUN. Otherwise the CD
driver will stay on the only LUN that has I/O.
> > > 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)
Hmm, there are a couple of things that could cause this. One could be that
you're actually just beyond the stack frame that contained those variables.
If you go back up into the stack frame with cdprevent(), can you take a
look at:
print /x softc->flags
print /x softc->changer->flags
print /x softc->pinfo.index
That might help things somewhat, or maybe not, since the flags will get
changed in the routines below that.
> > 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.
Do you think you might be able to get remote GDB working? You might be
able to get better information that way.
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?199904121858.MAA06429>