On Wed, 2005-08-03 at 06:30 -0400, Steven Rostedt wrote: > On Tue, 2005-08-02 at 19:58 -0700, Daniel Walker wrote: > > The stack trace should show where the problem is . If it's in the kernel > > we will see kernel functions before do_IRQ() , if it's just a whacked > > out task then do_IRQ() would be first in the stack trace . > > The problem is not differentiating tho output as kernel or user, I just > don't want too many false positives.
I was just testing RT tasks, which are few enough currently. > > > > I can't speak for everyone else, but I would want to catch both. That > > way we'll know if it's just a whacked out task, or a kernel problem. > > The thing is, it may be OK for a RT process to run in userspace for 10 > seconds without sleeping. If this is the case, you will constantly get > this output saying you may mave a bug. But if the kernel is running for > 10 seconds without scheduling, I strongly believe that is a bug. Unless True, it's just really odd .. If someone complained to the list about a crash, but they had a "possible softlockup" we might be able to conclude that the task hung the system. You said that your IRQ 14 would trigger this, but I think it wasn't running for 10 seconds straight, it was just running frequent enough that it was often running during the timer interrupt. I think that would be solved if we just checked the running time. > someone has some special driver thread, I don't know of any kernel path > that runs for 10 seconds without going back to userspace or sleeping. Right, and if someone did make a path like that, they wouldn't run the softlockup code.. > I still wish there was a nice arch-independent way to tell if the task > is running in user space from do_IRQ. Maybe there is? I'll post > another thread and ask the question. There should be a way to tell which protection level a task on when it was interrupted . I doubt it arch independent though. Daniel - 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/
