Date: Mon, 12 Apr 1999 21:28:10 +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: <199904121928.VAA02161@yedi.iaf.nl> In-Reply-To: <199904121858.MAA06429@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 12, 1999 12:58:15 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
As Kenneth D. Merry wrote ...
> > > 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.
[...]
> 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.
A bit more luck now:
(kgdb) frame 14
#14 0xc012720c in cdprevent (periph=0xc0780c00, action=1)
at ../../cam/scsi/scsi_cd.c:2517
2517
(kgdb) print /x softc->flags
$4 = 0xe8
(kgdb) print /x softc->changer->flags
$5 = 0x8
(kgdb) print /x softc->pinfo.index
$6 = 0xffffffff
(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.
>
> Do you think you might be able to get remote GDB working? You might be
> able to get better information that way.
I'll give it a try. Soldering iron is heating up to create a cable..
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?199904121928.VAA02161>