I've been trying to write the 6th CD in an 8 CD full backup set.
cdrecord kept failing, on 3 different CD-RW discs (at a different point
for each one). Each CD contains just two files. One is empty and is
the name of the backup set, and the other is a cpio archive of the
backup data that will fit on one CD. The CD filesystem is a plain
ISO9660 type.
I seemed to eventually succeed, with a 4th CD-RW. Then I mounted it,
and looked at the two files on it, and it seemed fine. But when I ran
cpio on the backup file from the CD, to verify it, the system panicked.
I've had about 10 panics tonight. (After the 1st one, I booted into
single user mode and unmounted all but the small root system, to
minimise fsck times.) From a text console, the panic message was
something like: "Aiee. Can't return from interrupt handler. Panic."
At first I suspected that a dodgy filesystem had been created on the
CD, but I get pretty much the same result even accessing ordinary CDs
(e.g. a CD from a Linux magazine). But sometimes it works.
Sometimes the system panics when mounting the CD; sometimes it panics
when copying large files from it; sometimes the CD can in fact be read.
I'm running RH 7.1 with a 2.4.17 kernel. Though I get the same panics
from the original RH 7.1 kernel.
The CD is a pretty new Sony CD-RW CRX175E, running via generic scsi
emulation. It's on a shared bus with a DVDROM drive, that's also
managed as a generic scsi. I got the same kind of crash from the
DVDROM drive, which is original equipment with the computer. So I
suspect the problem is in the scsi emulation system.
The new element is the CD-RW drive. I may not have actually tried to
use it to read bulk data from CD before today...
Until today, I've had no trouble writing with it.
How robust is Linux with regard to device errors on scsi devices?
Certainly, the previous HP CD writer that started playing up, was
handled very badly by Linux when it did play up. The scsi module went
into a tight loop re-sending the scsi command that failed, and filling
/var/log/messages with error messages as fast as it could. (The only
way that I could find to stop it was to reboot.)
There is also this discouraging comment in the man page for cdrecord:
The Philips CDD 521 CD-Recorder (even in the upgraded ver�
sion) has several firmware bugs. Some of them will force
you to power cycle the device or to reboot the machine.
When using cdrecord with the broken Linux SCSI generic
driver. You should note that cdrecord uses a hack, that
tries to emulate the functionality of the scg driver.
Unfortunately, the sg driver on Linux has several severe
bugs:
� It cannot see if a SCSI command could not be sent
at all.
� It cannot get the SCSI status byte. Cdrecord for
that reason cannot report failing SCSI commands in
some situations.
� It cannot get real DMA count of transfer. Cdrecord
cannot tell you if there is an DMA residual count.
� It cannot get number of bytes valid in auto sense
data. Cdrecord cannot tell you if device transfers
no sense data at all.
� It fetches to few data in auto request sense
(CCS/SCSI-2/SCSI-3 needs >= 18).
I'm a little puzzled that I can write CDs reliably (e.g. music CDs),
but not read them. Does anyone have any advice? Should I report this
problem to someone? If so, which group? For the generic scsi device
to be described as it is in cdrecord's man page, it sounds like this
problem has been around for a while.
Anyway, I thought I'd send this before trying any more experiments, to
see if anyone had any advice.
luke
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug
