Date: Thu, 8 Apr 1999 23:52:57 +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: <199904082152.XAA04131@yedi.iaf.nl> In-Reply-To: <199904082026.OAA11726@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 8, 1999 2:26:42 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
As Kenneth D. Merry wrote ...
> [ CCing this to -scsi since you seem to be sending things separately to me
> and then the -scsi list ]
Sorry, that was a mistake which I corrected with a seperate CC: copy to
-scsi
> 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.
> 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?
> > > 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.
> > > 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..
> > > > 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.
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?199904082152.XAA04131>