> Hi,
>
> It seems that the kernel time is not monotonically increasing in recent
> (i386) kernels.
>
> 2.1.126 introduced a bug that is still present in 2.1.129. Code that
> records the time during the top half of an interrupt may get a timestamp
> that is exactly 10000 microseconds back in time from when it should be.
>
> An easy way to see this is to use tcpdump on a reasonably busy network
> (500 to 100 packets per second), and examine the usec portion of the
> packet timestamp. This is affected because the timestamp is recorded
> during interrupt time (netif_rx in linux/net/core/dev.c).
>
> See this URL for more details and graphs:
>
> http://atm.cs.waikato.ac.nz/~sfd/bug/
The page says you printk()'ed the time from both get_fast_time() and
do_gettimeofday() -- however, on a Pentium system with TSC enabled,
get_fast_time() also ends up in do_gettimeofday() [do_get_fast_time
gets overwritten at the bottom of arch/i386/kernel/time.c] so I don't
quite see how you can get different results.
What a machine do you have, and is CONFIG_CPU_IS_SLOW enabled?
Hmm. I was sure it's only a matter of time until someone finds a bug
in the new time.c code :)
-- michael krause [aka raw style / lego] - www.tu-harburg.de/~semk2104/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/