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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
