That would be me. (I am the guy listed in the Maintainers file and, not
coincidentally, I am also listed in the file drivers/block/ide-cd.c)
I am listed in both 2.0.x and 2.1.x as the guy to contact. I am surprised
your were unable to find and reference to me. I will try to make th fact
that I am maintaining it more apparent for the future.
> I have an ALPS 4x4 cd rom changer. Nice drive actually, but it
> has a problem with the cd-changer code (in drives/block/ide-cd.c in
> 2.1.56). It seems that when select disc is called and sent to the
> drive, the drive doesn't actually change the disc, until it is
> accessed (i.e. mount or start attempt). This wrecks havoc with the
> table of contents for the CD, since it (correctly) invalidates the TOC
> for the CD when it does the select disc. Unfortunately, it
> immediately re-reads the TOC - since the disc hasn't physically
> changed, the wrong TOC is read in.
Yes. Well, ATAPI version 2.6 states:
9.4 Delayed Disc load operation
CD Changer Devices may either move a disc into playing position
immediatle upon receipt of a LOAD command, or delay the loading
of the disc until a media access command is received.
...
If the device supports delayed loading and the selected disc is
not in the play position, then the following commands SHALL move
the selected disc into the play position when data that has not
been cached has been requested by the host:
<Table 29 which includes READ TOC snipped>
-ATAPI ver. 2.6 page 83
It also states:
If delayed loading of a disc into the playing position is
supported, the device SHALL have previously cached the TOC
data from that disc. If the device has not read the TOC for
a disc that is being loaded into the playing position, then
delayed loading SHALL not be performed and the disc SHALL be
loaded into the playing position immediatly. If caching of
the TOC data has been performed and the loading of the disc
into the playing position is delayed, then the drive SHALL
report that the disc is ready, even though the disc is not
spinning and installed in the playing position. In all cases
the behavior seen by the host (other then a longer subsequent
media access latency) shall not be different between delayed
and immediate loading of a disc.
-ATAPI ver. 2.6 page 98
So it sounds like your changer incorrectly sends the old TOC data
on a CDROMREADTOCENTRY or CDROMREADTOCHDR ioctl even after receiving
a CDROM_SELECT_DISC ioctl to change the current disc. After a changer
receives a LOAD/UNLOAD command (like what happins with a CDROM_SELECT_DISC
ioctl) all future Media Access Commands (stuff like READ TOC) operate on
the newly selected slot for all ATAPI compliant cd changers. If your
ALPS changer is doing what you report it is doing, then the ALPS 4x4 is
_not_ ATAPI compliant.
>
> I've made a change to ide-cd.c that basically kicks the changer,
> forcing it to change when select disc is called.
>
My NEC 4x4 cd changer doesn't have the problem that your ALPS changer
does. I feel a bit uncomfortable with this patch. This does ensure that
the disc is loaded immediatly, but completely bypasses the (very nice IMHO)
features of drives (like my ATAPI compliant NEC 4x4) that correctly cache
data, allowing them to return a cached TOC _without_ having to load the
disc. I suppose I could put some defines aroung your patch like:
#ifdef BROKEN_ALPS_CHANGER
force_the_drive(......)
#endif
[------------your patch snipped--------------]
>
> Is there a better way to do this?
Yes, ATAPI compliance will do this. In the case of your drive though,
the only commands that ATAPI guarantees WILL load the disc (and remember that
your drive appears to follow the standard very loosly) regardless of caching
are START/STOP (which your patch uses) and SEEK (which your really don't
want to use here).
> And if not, who do I send this to
> as maintainer of the cd code? (last email comment in there was from
> mid-96 if i recall correctly).
>
I need to update the 2.1.x version. I have a HUGE set of patches
in my private development tree that are waiting for me to finish just
a few more features before I send them to Linus. (updates to the Uniform
CD-ROM driver, ports of several of the proprietary CD-ROM drivers to
Uniform, and several other currently too unstable for unstable things
as always available at http://www.inconnect.com/~andersen/files. The 2.0.x
version has the more up-to-date email address (but an email to my old address
will instantly let you know my current one).
> Cheers,
>
> --Dg
Have a good one,
-Erik
--
Erik B. Andersen Web: http://www.inconnect.com/~andersen/
email: andersee@debian.org
--This message was written using 73% post-consumer electrons--