The Uniform CDROM driver is fine. I have tested _IT_ quite carefully
(at least as well as all the different (but limited) hardware I own
can allow). If the uniform CDROM driver was at fault, the you would
see the exact same problem for ide-cd, scsi-cd, cdu31a, mcd, mcdx,
and cm206. The problem you are seeing is in the low-level driver
(i.e sbpcd). The difference you are seeing is that before 2.1.70,
sbpcd did not use the uniform CDROM driver, and now it does. As
part of my major CDROM update that went into 2.1.70, amoung other
things sbpcd was ported to the uniform CDROM driver (with most of
the port being done by Heiko Eissfeldt <heiko@colossus.escape.de>
and the rest of the changes being done by myself. For a detailed
description as to why doing this is the Right Thing(tm), please see
linux/Documentation/cdrom/cdrom-standard.tex. If we can get the
bugs ironed out of sbpcd, the improvement will be worth it. Getting
consistent behavior across all the low-level cdrom drivers is a Good
Thing(tm).
I make no claims that the sbpcd port is perfect. I had a Creative cdrom
drive that I was using during porting that ran with sbpcd, but it was
on loan from my work, and I had to return it after just two weeks (busy
weeks at work, unfortunatly). So for the moment, further work on sbpcd
will need to be done by somebody else. Heiko recently submitted patches
to me that went into 2.1.78 to fix a problem with the drive not spinning
up (I didn't know that they didn't spin up automatically. Oops...) and a
few other things.
Anyway, if playing a music CD leaves sbpcd in such a state, I invite you
to look into fixing it, since you seem to have the hardware. I truly
_hate_ tracking bugs when I have no hardware to cause them, and in this
case absolutly no docs on what the hardware does.
-Erik
--
Erik B. Andersen Web: http://www.inconnect.com/~andersen/
email: andersee@debian.org
--This message was written using 73% post-consumer electrons--