[lkml]   [2006]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BUG -rt] -rt16 hang w/ realtime thread test
On Sat, 2006-02-11 at 10:34 -0500, Steven Rostedt wrote:
> On Fri, 10 Feb 2006, john stultz wrote:
> > Hey Ingo,
> > I've been hunting a report that lower priority realtime threads are not
> > preempting higher priority realtime threads. However, in generating test
> > cases, I found I was locking the system quite frequently.
> >
> > The attached test runs to completion on 2.6.15, but with 2.6.15-rt16, it
> > hangs the box. It could very well be a test issue, but I'm not sure I
> > see where the problem is.
> >
> Hi John,
> Have you turned on nmi_watchdog and softlockup detect? Just so we can see
> where it is hung.

Ugh. Ok, I think I've found the issue.

The systems I'm testing w/ all use the ACPI PM timer for the
clocksource. On a whim I forced the TSC to be used and the hang went

It appears the issue is that the ACPI PM wraps every ~5 seconds. Since
the test takes longer the 5 seconds to run, the
timeofday_periodic_hook() function gets starved and we never accumulate
time. Then as the counter wraps, time starts wrapping thus timers do not
expire and the test never completes, effectively hanging the box.

I believe this issue was hit before back when cycle_t was 32bits long,
thus causing the TSC to wrap every ~4seconds on a 1Ghz box.

So whats the solution here? Do we need to do something to
timeofday_periodic_hook is guaranteed to run with some frequency? Or is
the test just bunk because realtime threads must give up the cpu in
order for the kernel to function?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-02-14 02:56    [W:0.045 / U:2.096 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site