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

[Prakash K. Cheemplavam]

Jens Axboe wrote:
> On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
>
> > Jens Axboe wrote:
> >
> > > On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> > >
> > >
> > > > Jens Axboe wrote:
> > > >
> > > >
> > > > > On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> > > > >
> > > > >
> > > > >
> > > > > > Jens Axboe wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > Jens Axboe wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > On Mon, Nov 03 2003, Prakash K. Cheemplavam wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > well I am using k3b0.10.1 and either choosing cdrdao or cdrecord in 
> > > > > > > >
> > > > > > > > DAO mode to burn the cd ends up in non-bit identical copies, wheres 
> > > > > > > > ion TAO (atleast with my 10x CD-RW I tested) the copy succeded. I 
> > > > > > > > tried several times, and always got this issue.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > > bash-2.05b$ md5sum livecd-2.6_10-23-2003.iso
> > > > > > > > > > f73f3a74239dfe94b322b85fd14a306e livecd-2.6_10-23-2003.iso
> > > > > > > > > >
> > > > > > > > > > TAO:
> > > > > > > > > > bash-2.05b$ md5sum /dev/cdroms/cdrom1
> > > > > > > > > > f73f3a74239dfe94b322b85fd14a306e /dev/cdroms/cdrom1
> > > > > > > > > >
> > > > > > > > > > DAO:
> > > > > > > > > > bash-2.05b$ md5sum /dev/cdroms/cdrom1
> > > > > > > > > > 09e7e2a51af4c64685831513fbac18c2 /dev/cdroms/cdrom1
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Could you please try and cmp the two images, finding out how big the
> > > > > > > > > corrupted chunks are and what kind of data they contain?
> > > > > > > >
> > > > > > > >
> > > > > > > > After some further investigation I found out, that the data is NOT 
> > > > > > > > corrupted, but in a way truncated in DAO mode: When I read out the 
> > > > > > > > image 
> > > > > > >
> > > > > > > > from the CD-RW drive, about 5kbyte are missing at the end (and doing 
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > several burn, it is always the same amount). Strange enough if I read 
> > > > > > > > the DAO burnt disk out by my DVD-ROM, the image can be read out 
> > > > > > > > completely! Can you understand this behaviour? I don't think it is a 
> > > > > > > > problem of my burner, but rather of the atapi driver?
> > > > > > >
> > > > > > >
> > > > > > > Is actual data missing at the end? If yes, I'd say this looks a lot 
> > > > > > > more
> > > > > > > like a cdrecord problem.
> > > > > >
> > > > > > 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.
> > > > >
> > > > >
> > > > > You need to use the pad option to record.
> > > >
> > > > Uhm, could you be more specific? I just use the k3b frontend to burn, 
> > > > and in the cdrdao manual I couldn't find something useful to it.
> > >
> > >
> > > it's a cdrecord option, I've never used k3b so cannot comment on how to
> > > make it enable that.
> >
> > Hmm, I'll take a look, but I don't really think it is a problem of the 
> > recording programme, otherwise how could my reader read it out completely?
>
>
> It isn't a problem of the recorder program. But some drives wont read
> the very end of a disc unless there are some pad blocks at the end.
> Thus, you should always use the cdrecord pad option.

Uhm, ok, I just took a look at the source image and the last (missing) 
4096 bytes are just 00, so nothing critical missing anyway...so your pad 
parameter sounds sensible. :) Should drop a note to the k3b devs then, 
as well...


 > SG_IO or CDROM_SEND_PACKET? The latter should never have been merged in
> cdrecord, and you should never use it. If it is using SG_IO, I'm very
> interested in knowing more. vmstat 1 while doing the burn would be
> interesting, just for 10 seconds where you see the problem.

Uhh, I'll try to find out. I must go now, but I'll report back later.

> > probably is a new issue. Furthermore my hd reading (I once contacted you 
> > because of that) didn't improve with the new kernel, though some 
> > bugfixes in this directions are mentioned by Andrew Morton.
>
>
> Don't remember, sorry :)

I probably will make a new topic regarding issues (I think) I found with 
the new mm kernel.

cya,

Prakash

-
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/