Under Linux kernel 1.3.94 and 1.3.100 it appeared that the isofs module
was trying to continually read from the CD and the process that requested
to read the file would not respond to a kill -9 thus requiring a reboot
to stop the continual reading of the CD.
Under Linux kernel 1.2.13 or M$-DOS 6.22 the files would copy over as
having zero length, the flawed CDs would only crash the computer (leave it
continually scanning the CDROM drive) with the developmental series
kernel.
--- flame mode on ---
To add to my problems was what occured when I informed InfoMagic. When I
notified InfoMagic they told me they where aware of the problems with
Disc #3, Disc #4, Disc #5 and would replace them but couldn't test Disc
#6 since the majority of the matterial is for a DEC Alpha. I then made
them aware of the fact that a DEC Alpha can be purchased without a
monitor for less than $2000 (most Pentium based systems cost more than
that!) and that there are flaws on Disc #6 that effect files aren't
related to the DEC Alpha at all! (Do you really need a DEC Alpha to test
if material related to a DEC Alpha is simiply *readable* from a CDROM?)
In responce to my complaint about Disc #6, I was told that the problems of
not being able to read files was a "trival" problem since most Linux
users do not need to read the files that are effected. He claimed that
only files in the other/ directory on Disc #6 where effected (hello!
updates/SRPMS/XFree86-3.1.2-5.src.rpm isn't in the other directory!)
and if someone does need one of the effected files then they are
available at InfoMagic's FTP site (kinda defeats the purpose of
getting CDs, doesn't it? Why not send letters out instead of CDs saying
that it is ok they didn't send you CDs because the files you want are on
their FTP site!) The InfoMagic technician went on to explain that the
flaws on Disc #6 should not effect the developmental series kernel since
the source code for the developmental series kernels are stored on
Disc #4 which they where more than happy to replace. (The source code
for DOS doesn't exist on Disc #6, that doesn't mean DOS automagically
isn't effect by the flaw and can read the content of the files)
Anyways... after arguing for a while he finally stated, "CDROM 6 is being
redone so you can look at even if you don't need anything on it. THE
END." (Again, why don't they just mail a letter saying that they don't
need to send you any CDs at all because if you really need anything from
them you can get it from their ftp site). Better yet would be for them to
say that if you really wanted CDs you could read the files from you would
have purchased from somebody like Yggdrasil instead of InfoMagic.
--- flame mode off ---
In short, this problem effects much more than just CD's made on CD-Rs.
Considering that a "professional" CD distributor that is "Linux aware"
does not seem to mind considering leaving their customers stuck with
flawed CDs, we may want to look at making the CDROM support as robust as
it was in Linux 1.2.13 before releasing Linux 2.0. I will gladly test
expiermental drivers to see if the flawed CDs causes any critical
problems.
Thanks,
Ben Galliart (bgallia@luc.edu)
---------- Forwarded message ----------
Date: Sun, 19 May 1996 20:39:28 +0000 (GMT)
From: Alberto Vignani <alberto.vignani@torino.alpcom.it>
To: linux-kernel@vger.rutgers.edu
Subject: bad CDs and eternal retries - what to do? (long)
Hello.
Since I bought a CR recorder I started having troubles with the IDE CD
driver under Linux.
Many CD-Rs I write have errors - sometimes a manufacturing defect, some-
times a glitch in the recorder, probably 99% of the times nasty bugs
in Windows 95 programs (why CDs written under DOS are always good?).
I cannot write CDs under Linux because my Sony 920S is not supported
by cdwrite (someone has to solve this too).
When I switch to Linux to verify the CD on the 6x IDE drive and the CD
has an error, the drive just goes on retrying forever (well, I didn't
wait more than 3-4 minutes, hope it's enough).
These errors have always code 0x30 and status 0x51 (seek errors). The
CD is clearly bad, even DOS and Win are unable to read over the damaged/
missing/skipped(?) sectors.
There is no way of stopping the messages on the screen, nor to kill the
process (usually cat or cmp); the VC seems frozen and the only way to
stop the driver from retrying is to (warm) reboot the machine. Sometimes
the drive door get locked after that, but eject solves the problem.
My current setup: kernel pre-2.0.5, pentium gcc 960426, ATAPI CD Philips
665A (hope it's not a gcc bug ...)
Here is a sample trace. I enabled DEBUG in ide.c, added some messages to
ide-cd.c, then I mounted the CD and tried to cat the bad file to /dev/null: