Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01

[Steven Rostedt]

On Mon, 2005-08-01 at 14:20 -0700, Daniel Walker wrote:
> On Mon, 2005-08-01 at 14:22 -0400, Steven Rostedt wrote:
> > Ingo,
> > 
> > What's with the "BUG: possible soft lockup detected on CPU..."? I'm
> > getting a bunch of them from the IDE interrupt.  It's not locking up,
> > but it does things that probably do take some time.  Is this really
> > necessary? Here's an example dump:
> > 
> > -- Steve
> > 
> > Note: I added the curr=%s:%d,current->comm,current->pid just to see who
> > was at fault. 
> 
> It means that IRQ 14 is running for a long time as an RT task .. btw,
> the curr=%s:%d information duplicates some in the "show all held locks"
> section .

yeah I know that was redundant (after putting it in), but I wanted to
make sure what current was. The locks held wasn't as straight forward as
to what was current (I wasn't looking at what produced that, I just
noticed the output).

> 
> I could base it off current_sched_time() to only trigger if the task has
> actually been running for 10 seconds, instead of just assuming that it
> has..

I thought about changing that too. But I'm assuming that you are looking
for bugs (like the kjournald as RT) where a task may be in a loop, but
higher priority tasks can still preempt it.  Putting the check elsewhere
will still be screwed up by preempting higher prio tasks.

In my custom kernel, I have a wchan field of the task that records where
the task calls something that might schedule. This way I can see where
things locked up if I don't have a back trace of the task.  This field
is always zero when it switches to usermode.  Something like this can
also be used to check how long the process is in kernel mode.  If a task
is in the kernel for more than 10 seconds without sleeping, that would
definitely be a good indication of something wrong.  I probably could
write something to check for this if people are interested.  I wont
waste my time if nobody would want it.

-- Steve


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