Re: linux kernel error reading end of cd/dvd
Thanks for all your thoughts. I'll combine the reply.
> Why are you mailing cdwrite? If it's a kernel bug, you should send a
> bug report to linux-kernel I'd say.
I am not sure where the bug is, but it affects CDs. This is a CD writing
list?
> (a) get the size of the ISO filesystem with cdrecord or isoinfo, and
> then use dd to read only what's valid, or complain to the creator of the
> CD. There's an option which fixes this, from memory -dao.
(a) I am always doing that.
(b) If you mean the person, that's me. If you mean the software, I don't
think Jörg is going to be to sympathetic ;)
> Actually, that doesn't work. I took a random pressed CD, used
> isoinfo to find that there were 160525 blocks on it, and then used
> dd to read the blocks, with bs=2k count=160525. It stops at 160484
> blocks with an IO error every time. Turning off readahead with
Thanks very much for that! I was beginning to think nobody takes me
serious. Eaxactly what I am seeing quite often.
> Could be media, hardware/firmware, or as you say, something we don't
> understand.
I am undecided, but would say the kernel is involved. If
hardware/firmware is involved, I'd say it affects roughly over 50% of
it.
> I tried mounting the CD that did not work, and copy all files off of
> it. No problems there.
Note this is not necessarily an indicator that the filesystem is not
affected, it only means none of the files are directly affected. There
are more blocks in a filesystem than just the files' data.
With several trouble CDs, I could read all the files correctly, but the
read error was 2 blocks before the end of the iso9660 filesystem (as
indicated by isoinfo -d, I never had reason to suspect it has ever
given bogus numbers). When I did manage to find out what those 2 last
blocks contained (can't remember how, in some cases by looking at the
iso image file I just burnt) those 2 blocks only contained nulls.
Meaning those 2 blocks are not relevant, but they're nevertheless part
of the filesystem and part of its md5 sum.
> Perhaps it's some sort of odd copy
> protection? (it's a Nero install CD that came with my burner, I
I don't think these CDs contain copy protections. The software is
crippleware, only of use if you have the hardware, and everyone who has
the hardware has paid the Nero tax as well (don't get me started).
> There is no need to use -pad!
My experience clearly shows otherwise. If you mean "*should* be no need
for -pad, by all means yes. It's a right PITA.
> If you use unapropriate software like "dd" and don't even send a problem
> report, it is impossible to help you :-(
As for dd: a cdrom is a block device and I can expect to use it as such.
Are you wishing to argue about that? Apart from the problem I have been
describing, it works fine (with the obvious restrictions of spead and
read-only).
As for problem report: well dunno where the problem is, and it looks to
me as if everyone on this list knows that you're not very, what's the
word, responsive to reports which have nothing to do with cdrecord.
> mkisofs now adds paddinf for a long time ....
Sure, but remembering that option is the same as remembering to bang a
bunch of nulls at the end of the iso file. ;)
> He unfortunately not even send a error message.
Not true. I gave a detailed description of the situations in which the
error occurs, and that the error is "read error". If you want more than
that, no problem but you should ask properly. Actually, not sure I can
tell you more than that.
> Using dd is a bad idea and only "readcd" will give helpful messages
> in case the medium is not readable.
Good point, haven't used readcd before (sorry but simply didn't see a
need), but for gettng better error info it has a place.
Hardware: PIII-450 with Intel 440BX chipset, Asus E616 16x dvdrom drive
/dev/hdb:
HDIO_GET_MULTCOUNT failed: Invalid argument
IO_support = 0 (default 16-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 1 (on)
readahead = 8 (on)
HDIO_GETGEO failed: Invalid argument
Software: SuSE 8.2, mkisofs + cdrecord 2 final
isoinfo -d: Volume size is: 349552
readcd -v dev=ATAPI:1,1,0 f=somedisk.raw
========================================================================
scsidev: 'ATAPI:1,1,0'
devname: 'ATAPI'
scsibus: 1 target: 1 lun: 0
Warning: Using ATA Packet interface.
Warning: The related libscg interface code is in pre alpha.
Warning: There may be fatal problems.
Read speed: 8448 kB/s (CD 48x, DVD 6x).
Write speed: 0 kB/s (CD 0x, DVD 0x).
Capacity: 349569 Blocks = 699138 kBytes = 682 MBytes = 715 prMB
Sectorsize: 2048 Bytes
Copy from SCSI (1,1,0) disk to file 'somedisk.raw'
end: 349569
...
addr: 349209 cnt: 63
addr: 349272 cnt: 63
addr: 349335 cnt: 63
addr: 349398 cnt: 63
addr: 349461 cnt: 63
addr: 349524 cnt: 45
readcd: Input/output error. read_g1: scsi sendcmd: no error
CDB: 28 00 00 05 55 54 00 00 2D 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 64 00 00 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x64 Qual 0x00 (illegal mode for this track) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 2.967s timeout 40s
readcd: Input/output error. Cannot read source disk
readcd: Retrying from sector 349524.
.............................................~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~+~~~-~~~
readcd: Input/output error. Error on sector 349568 not corrected. Total of 1 errors.
readcd: Input/output error. read_g1: scsi sendcmd: no error
CDB: 28 00 00 05 55 80 00 00 01 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 64 00 00 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x64 Qual 0x00 (illegal mode for this track) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 1.440s timeout 40s
Time total: 520.137sec
Read 699048.00 kB at 1344.0 kB/sec.
------------------------------------------------------------------------
Elapsed time (wallclock): 0:08:40 (if shell supports $SECONDS)
readcd has produced a file which is 349524 blocks long, 28 blocks
short of 349552. It says "end: 349569", which is 2 blocks more than the
additional 15 blocks of cdrecord -pad. When I limited speed to 16x it
died at the same block 349524.
readcd finishes with "Error on sector 349568", well no surprise there,
it's past the end of 349552+15. It fails to write out the data of block
349524 to 349567 before exiting, this is a bug.
I ejected the CD, re-inserted it and tried dd:
dd bs=2k count=349552 if=/dev/cdrom of=somedisk-dd.iso
========================================================================
349552+0 records in
349552+0 records out
------------------------------------------------------------------------
Elapsed time (wallclock): 0:04:29 (if shell supports $SECONDS)
Well that much for readcd being better suited than dd! The output file
created by dd is correct (verified by md5 sum).
Of course, the very same dd operation failed no matter how often I tried
a week ago after I burnt the disk. I hate this...
> dd, just for fun I gave readcd a go with the "broken" CD. It sees
> 169825 blocks (where isoinfo saw 160525) and could read 160512 of
> them before giving an IO error.
Interesting also that the disk is only half full, so the "errors at
edge" doesn't apply. Of course there might still be a real disk error
there.
When I see these funnies, they mostly are within a few blocks of the end
of the filesystem, and always within a few hundred blocks of it. I have
never observed any of this nonsense on any disk which I've appended
generously with zeroes. I can't accept that media errors are the root
cause of this.
Volker
--
Volker Kuhlmann is possibly list0570 with the domain in header
http://volker.dnsalias.net/ Please do not CC list postings to me.
Reply to: