Re: 2.5.64-mm2->4 hangs on contest

[Con Kolivas]

On Mon, 10 Mar 2003 21:29, Mike Galbraith wrote:
> At 11:05 AM 3/10/2003 +0100, Mike Galbraith wrote:
> >At 08:12 PM 3/10/2003 +1100, Con Kolivas wrote:
> >>On Mon, 10 Mar 2003 18:05, Mike Galbraith wrote:
> >> > At 01:29 PM 3/10/2003 +1100, you wrote:
> >> > >Tried running contest on 2.5.64-mm2 and mm4 and had the same thing
> >>
> >> happen.
> >>
> >> > > It will hang reliably during process_load. I tried not running
> >> > > process_load but it would still get stuck in one of the other loads
> >> > > (either a tar load or list load). I can simply stop contest at that
> >>
> >> stage
> >>
> >> > > but then the machine wont work well hanging at the console after a
> >>
> >> minute
> >>
> >> > > or so. This started at mm2 (doesn't happen with mm1).
> >> > >
> >> > >Here is the sysrq-p and sysrq-t output during process_load (which
> >> > > hangs every time):
> >> >
> >> > hmm, the below looks interesting to me...
> >> >
> >> > >ksoftirqd/0   R C129A000     2      1             3       (L-TLB)
> >> > >Call Trace:
> >> > >  [<c0118f3e>] ksoftirqd+0x5e/0x9c
> >> > >  [<c0118ee0>] ksoftirqd+0x0/0x9c
> >> > >  [<c0106f1d>] kernel_thread_helper+0x5/0xc
> >> >
> >> > I see that too with irman.  You could try renicing the shell you start
> >> > contest from to >= +12.  With irman, what appears to be cpu starvation
> >> > ceases to be a problem at exactly +12.  I also see kapmd constantly
> >>
> >> wanting
> >>
> >> > to run but not being serviced.
> >>
> >>Contest uses a modified process load from irman so it exhibits similar
> >>behaviour. Not sure what +12 actually tells me though :-(
> >
> >Aha!  No wonder your symptoms look so similar.  +12 is just a magic number
> >that works... found by trusty old trial and error method.  What I wanted
> >to see was if your hang would also go away with the same magic number, or
> >if renicing with any value helped you at all.
> >
> >>My simplistic understanding is that the pipe task in process_load gets
> >>constantly elevated as "interactive" by the new scheduler, and nothing
> >> else ever happens.
> >
> >Appears so.  I can make it "work" by doing a dinky (butt ugly:) tweak in
> >activate_task().
>
> Oh, what the heck.  Even a butt ugly patch that works has informational
> value.  Can you try the attached please?  If it works for you too, maybe
> it'll tell Ingo something.

Sure. How about attaching it?

Con