Well, it could be a bad CD ;-) I just tried using dd on my old burner (real SCSI), my recent burner (ATAPI+ide-scsi), and the 52x reader only (ATAPI+ide-cd) and a Redhat 2.4.18-24.8.0 kernel, and no error on any of them. I can't try a 2.6 kernel without rebooting, but I'll try that at work.On Wed 8 October 2003 05:09, Rob Bogus wrote:Volker Kuhlmann wrote:Esteemed gurus,if anyone is able to shed some more light on this kernel problem I'd appreciate it. It's been going on for years. When reading the whole of an iso9660 filesystem from a cd or dvd, I often get I/O errors within the last blocks of the filesystem. Using<snip>This is caused by reading past the end of written data. You can either (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.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 hdparm doesn't make any difference. The interesting thing is, 160484 = 2 * 2 * 53 * 757. If this is indeed a block readahead problem, then the readahead block size is 8k max. (unless it's 106k, but that seems unlikely to me). However, if it's 8k, then it should read at least up to the last 4 blocks, and not stop 41 blocks before the end. So, it's either not a block readahead problem, or I'm missing something.
Could be media, hardware/firmware, or as you say, something we don't understand.
Another thought, with some older cdrecord versions I convinced myself that using -pad making the ISO image was more successful than using the option in cdrecord. Don't know if that was/is true or just based on too few trials. Also seem to remember that readcd works differently with the ide-cd driver.
Too many possibilities, and Joerg is not motivated to do anything with Linux except whine that the kernel people doing the work won't take orders and do it his way.
-- E. Robert Bogusta It seemed like a good idea at the time
