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

[Jens Axboe]

On Fri, Nov 07 2003, Nick Piggin wrote:
> 
> 
> Jens Axboe wrote:
> 
> >On Thu, Nov 06 2003, Nick Piggin wrote:
> >
> >>
> >>Prakash K. Cheemplavam wrote:
> >>
> >>
> >>>>>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.
> >>>>
> >>>
> >>>
> >>>Ok, then it is Nick's turn, I guess. :-) Yeah most probably the iso is 
> >>>cached, as it was not the first time I burnt the iso when I did the 
> >>>vmstat, furthermore I have 1 GB of RAM... The other thing which 
> >>>doesn't speack for i/o problems, I guess: Just the first seconds when 
> >>>I start erasing the CD-RW the mouse hangs and heavily stutters, then 
> >>>it is OK until actual burning of image begins, then the mouse slightly 
> >>>stutters. All this was not with test9-mm1.
> >>>
> >>>
> >>I don't think the scheduler is the problem if you didn't have these 
> >>problems
> >>in mm1. The scheduler is quite good when nothing is reniced. Whats funny
> >>though is it looks like you're losing timer interrupts, this is a sign 
> >>that
> >>something is holding interrupts off for too long, and would also cause
> >>problems with your mouse.
> >>
> >
> >sys time is usually pretty high if that is the case, and it's hovering
> >around 5% here... Prakash, are you sure that dma is enabled on the
> >drive? When you see the problem, do a vmstat 1 for 10 seconds so you are
> >absolutely sure you are sending the info from when the problem occurs.
> >
> 
> Although have a look at the interrupts field in vmstat 1255, 725, 736 ...

Yeah that is pretty high for just doing a burn, maybe something else is
happening in the system? It would be more reliable to run Andrews
cyclesoak, sys time is usually not very well reported by linux (if the
interrupt handler runs for a long time).

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