Re: 2.6.14-rc4-rt7

[john stultz]

On Wed, 2005-10-26 at 19:57 -0400, Steven Rostedt wrote:
> On Wed, 2005-10-26 at 15:07 -0700, William Weston wrote:
> > On Wed, 26 Oct 2005, Rui Nuno Capela wrote:
> > 
> > > Just noticed a couple or more of this on dmesg. Maybe its old news and 
> > > being discussed already. Otherwise my P4@xxxxxxx/UP laptop boots and 
> > > runs without hicups on 2.6.14-rc5-rt7 (config.gz attached).
> > > 
> > > ... time warped from 13551912584 to 13551905960.
> > > ... system time:     13488892865 .. 13488892865.
> > > udevstart/1579[CPU#0]: BUG in get_monotonic_clock_ts at 
> > > kernel/time/timeofday.c:
> > > 262
> > >   [<c0116fcb>] __WARN_ON+0x4f/0x6c (8)
> > >   [<c012f8b0>] get_monotonic_clock_ts+0x27a/0x2f0 (40)
> > >   [<c0141c9d>] kmem_cache_alloc+0x51/0xac (76)
> > >   [<c0114826>] copy_process+0x2ff/0xeed (44)
> > >   [<c0139444>] unlock_page+0x17/0x4a (12)
> > >   [<c0147a8a>] do_wp_page+0x245/0x372 (20)
> > >   [<c01154f5>] do_fork+0x69/0x1b5 (56)
> > >   [<c02c120b>] do_page_fault+0x432/0x543 (32)
> > >   [<c01017aa>] sys_clone+0x32/0x36 (72)
> > >   [<c0102a9b>] sysenter_past_esp+0x54/0x75 (16)
> > 
> > I'm getting these with two different machines running 2.6.14-rc5-rt7 with
> > Steven's ktimer_interrupt() patch from yesterday.  Did not see these with
> > previous -rt kernels.  Shutting down NTP makes no difference.
> 
> Yeah, that ktimer_interrupt patch was for something completely
> different. Is this happening on boot up, or is this consistently
> happening?
> 
> Also, Rui, do they show up at different times or clustered together?
> (William, I see your output is clustered) The reason I asked, is that
> the test may produce more than one warning message for the same time
> warp. Since the time used to check for the time warp is not updated if
> time goes backwards, so if you call the this routine more than once
> before the time warp catches back up, it will warn again.


Ok, I've reproduced the issue. 

However, running a clock_gettime(CLOCK_MONOTONIC) inconsistency check
results in no failures, but triggers this code in the kernel.

Looking at the code, these may be false positives. The bit that is
complaining I believe Ingo added to get_monotonic_clock_ts() in
kernel/time/timeofday.c.  However I don't see any locking that
serializes the writes the prev in the same order as the
get_monotonic_clock_ts is called.

I'm still digging and will send out some mail when I figure out whats
wrong.

thanks
-john



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