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

[Daniel Walker <dwalker@mvista.com>]

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