Date: Thu, 8 Apr 1999 17:11:54 -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: <199904082311.RAA12752@panzer.plutotech.com> In-Reply-To: <199904082152.XAA04131@yedi.iaf.nl> from Wilko Bulte at "Apr 8, 1999 11:52:57 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Wilko Bulte wrote...
> As Kenneth D. Merry wrote ...
> > Wilko Bulte wrote...
> > > As Kenneth D. Merry wrote ...
> > > > Wilko Bulte wrote...
> > > > > As Kenneth D. Merry wrote ...
> > > > > > Wilko Bulte wrote...
> > > > > > > As Kenneth D. Merry wrote ...
> > > > > > > > Wilko Bulte wrote...
> > > > FWIW, Justin and I have been talking about making the CD and DA drivers
> > > > attach to devices "no matter what", for the most part. (unless they say
> > > > something like "logical unit not supported")
> > >
> > > To be honest I never saw the point in doing a READ CAPACITY etc on a CD
> > > drive. If it responds to an inquiry OK, does not produce sense codes
> > > like hardware error I'd conclude we have a working drive on our hands.
> > > But that might be too simplistic.
> >
> > We have to do a read capacity if we're going to mount the CD at all. The
> > read capacity provides two critical pieces of information: the
> > sector/block size of the device, and the size of the device. Both are
> > needed for the disklabel and for mounting filesystems.
>
> OK, sounds like I need another beer ;-) I confused the READ CAPACITY with
> the READ TOC (see below)
>
> The only thing that could go I think is the warning/error that occurs
> when no CD is loaded in the drive during probe.
I think it's useful to have a message that tells you that there's no CD
present, and why the driver thinks that that's the case.
> > Now the read capacity may not be necessary on attach, but it must be done
> > before we can open the CD. I think it's generally worthwhile to do on
> > attach as well.
>
> It should not hurt. Maybe a 'silent' one in case of an empty drive?
See above. In any case, it's already a stripped-down, one-line
informational message.
> > > > That means that the probing should happen sequentially, not in parallel.
> > > > So your timeout should be the time it takes for one LUN to probe, not all
> > > > of them.
> > >
> > > OK. I just went back to the driver. I put the original driver in the tree
> > > again and just added the 0xb0 ASC the drive reports during probe when no
> > > magazine/cds are loaded. I left all the timeouts alone for now.
> > >
> > > Will test this later tonight when it has completed a complete magazine
> > > test cycle.
>
> In the meantime it has proven to work OK with the default timeouts, and
> only the 0xb0 line in.
Good!
> > > > You can put a quirk entry in the CD driver to make sure the CD driver sees
> > > > even LUN 0 as part of a changer, but I don't think it'll have any noticable
> > > > effect on the way things work.
> > >
> > > It has no problems detecting the 6 LUNs.
> >
> > The CD driver will detect all 6 LUNs with or without a quirk. The only
> > reason for a quirk entry is that the various LUNs of the changer will not
> > be seen/grouped as a changer until the CD driver sees a LUN greater than 1.
> >
> > Once a group of CD devices is recognized as a changer, I/O to any of those
> > devices goes through the changer scheduler in the CD driver. The changer
> > scheduler schedules I/O to each LUN in a changer, makes sure one LUN can't
> > hog the changer if there is outstanding I/O to another LUN, etc.
> >
> > I don't think it's really necessary to have a quirk entry, though, since
> > all the LUNs will be put in the changer scheduler before any I/O goes to
> > LUN 1 of the device.
>
> That is what I meant. It works with or without the quirk entry. I tried
> both. Interestingly enough there is a quirk entry for Pioneer already, but
> my drive has a slightly different inquiry string:
>
> {
> { T_CDROM, SIP_MEDIA_REMOVABLE, "PIONEER", "CD-ROM
> DRM-604X",
> "*"}, /* quirks */ CD_Q_CHANGER
> },
> {
> { T_CDROM, SIP_MEDIA_REMOVABLE, "PIONEER", "CD-ROM DRM-600",
> "*"}, /* quirks */ CD_Q_CHANGER
> },
>
> I'm not sure if it is worthwhile to put a quirk in the driver for this
> drive. Maybe if I can get info on why READ TOCs etc fail.. Just sent
> mail to Pioneer in Belgium to ask for a SCSI implementation manual for this
> drive. Lets be optimistic..
Hmm, well, my guess is that the 604 is just a newer version of the drive
you have. I haven't heard any complaints from any 604 owners about read
toc problems, so my guess is that it's a SCSI-2 drive.
> > > > > A mount of a plain iso9660 cd produced a new interesting message:
> > > > >
> > > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): READ TOC/PMA/ATIP {MMC
> > > > > Proposed}. CDB: 43 60 0 0 0 0 0 0 4 0
> > > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): ILLEGAL REQUEST asc:20,0
> > > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): ILLEGAL REQUEST asc:20,0
> > > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): Invalid command operation
> > > > > code
> > > > >
> > > > > Makes me wonder, especially because the Pioneer firmware claims to be CCS
> > > > > only. There is a little dipswitch claiming to select SCSI-2 mode but it
> > > > > does not have any obvious effect. I guess this is a pre-SCSI-2 firmware rev
> > > > > and it does not have the standard SCSI cmds for optical devices. They were
> > > > > introduced in SCSI-2 IIRC. Really a funky piece of hardware ;-)
> > > >
> > > > Yeah, definitely makes me wonder. I wonder how you get the table of
> > > > contents off the thing, since that is the standard CDROM TOC command that
> > > > should work on most any CDROM..
> > >
> > > 'Most any' appears to be the right term for it ;) I'll experiment a bit
> > > more. Just go a solid system lockup by running a 'dd if=/dev/rcd0a' and
> > > a 'mount /dev/cd1a ...' at the same time. Only ping still works. Hmm.
> > > More testing to do I guess
> >
> > Hmm, interesting. What happens if you just try the DD? Can you break into
> > the debugger when the machine locks up?
>
> I made a new kernel with the debugger in. I'll have it run overnight to see
> if it re-occurs. In the meantime there was also a spontaneous reboot. No
> panic as far as I can see. I'll try to reproduce.. Just the DD seems
> to work just fine.
Hmm, sounds strange indeed.
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?199904082311.RAA12752>