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

From: Jens Axboe
Date: Thu Nov 06 2003 - 08:08:43 EST


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/