Re: 2.9test9-mm1 and DAO ATAPI cd-burning corrupt

[Jens Axboe]

On Thu, Nov 06 2003, Prakash K. Cheemplavam wrote:
> Prakash K. Cheemplavam wrote:
> >bill davidsen wrote:
> >
> >>In article <3FA8CA87.2070201@xxxxxx>,
> >>Prakash K. Cheemplavam <prakashkc@xxxxxx> wrote:
> >>
> >>| Sorry, I wasn't precise: The data is on the disc, as my DVD-ROM 
> >>restores | the full image (md5sum matches), but the CD-RW does not.
> >>
> >>There is a problem with ide-scsi in 2.6, and rather than fix it someone
> >>came up with a patch to cdrecord to allow that application to work
> 
> >b) The writing or reading issue mentioned above. It is a bit hard to 
> >find out, whether cdrecord actually *writes* an incomplete image 
> >(without using -pad), ie. throwing away the last 4096 bytes, which 
> >*only* happens in non-TAO mode. The programme CDRDAO shows the same 
> >behaviour. Strange enough reading this DAO written image out with my 
> >DVD-ROM makes this (missing?) 4096 bytes reappear... Well, maybe I 
> >should patch the image and put some other bytes instead of the 00s at 
> >the end to see, whether it is a write issue, a read issue of the writer 
> >or a read issue of the reader. Anyway, it doesn't sound right to me, 
> >what is happening at the moment...
> 
> So tested further: I patched the very last byts of the image and these 
> are my findings:
> 
> In DAO mode, the complete image is actually written, but the writer is 
> not able to read it out! The last 4096 bytes are not read. I put the 
> CD-RW into my DVD-ROM, and it reads it out completely.
> 
> So: Is cdrecord/cdrdao making something wrong (yes, I know I can use 
> -pad, but I want an *identical copy*) or has the kernel ATAPI reading 
> routine a bug? (Or has my drive a bug???? Well, I need to read the disc 
> out in windows I guess...)

See one of my mails from a few days ago. It's a hardware issue, some
drives need a bit of pad at the end.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/