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

[Jens Axboe]

On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> Jens Axboe wrote:
> >(cc me, just caught your message by luck)
> >
> >On Wed, Nov 05 2003, Prakash K. Cheemplavam wrote:
> >
> >>>>>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.
> 
> Well, I now used the -pad option, but now the image (naturally) gets 
> larger and thus k3b reports verify fail. I think the k3b people need to 
> ignore the last 00s and calc the md5sum according to the original iso 
> size...

Sounds right, yes.

> >>>Don't remember, sorry :)
> >>
> >>I probably will make a new topic regarding issues (I think) I found with 
> >>the new mm kernel.
> >
> >
> >Fine, check the SG_IO thing first though.
> 
> I am sorry, but could you explain how to find out? I dunno where to 
> look... But I made your vmstat output:

Your other mail showed the device argument being the actual device, so
unless cdrecord screws, it is using SG_IO.

> procs -----------memory---------- ---swap-- -----io---- --system-- 
> ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us 
> sy id wa
>  2  0      0 579472  13976 308572    0    0   425    85 1255   645  5 
> 3 84  9
>  2  0      0 579456  13976 308572    0    0     0     0  725   521  5 
> 5 91  0
>  1  0      0 579448  13976 308572    0    0     0     0  736   523  2 
> 5 94  0
>  0  0      0 579448  13976 308572    0    0     0    25  745   439  2 

[snip]

This looks good, from a system utilization point of view. I'm wondering
whether you have the iso image cached? There's no block io going on.

It does like more like a CPU scheduler problem at this point.

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