From: Dan A. <da...@gm...> - 2004-02-22 22:02:08
|
On Sun, Feb 22, 2004 at 02:40:31PM +0200, Nir Perry wrote: > Hello, > > I too saw nanosleep() hangs - trying to run "top" (according to "strace" and > "gdb", the kernel function call never returns). > > /bin/sleep hangs too. > /usr/bin/date keeps reporting the SAME frozen time... > > Guess the time just froze... > > It doesn't always freeze. Usually, everything work just fine. However, > sometimes, some event causes the time to stop running (I think), and from > that moment on - nothing time related works. Note that the scheduler keeps > scheduling, and the kernel works fine - all but the time. The cause for the nanosleep problems you have been experiencing has something to do with the Windows user space timer granularity. I use the daemon's idle loop in order to send a timer beat every 1/HZ seconds. It is possible that two timer beats are sent together. I am not sure that this by itself is the only cause of the problem, other part of this story is that Linux's kernel space gettimeofday() is not yet implemented, so Linux can't differentiate between time resolutions that are less than HZ. I'll try to reproduce and fix it here after I'm done with implementing the %gs/%fs workaround fix that I talked about in IRC (which should solve the reboots problem that is caused by the Gentoo i686 image, more specifically, the problem where libpthreads uses modify_ldt() and triggers the LDT-%gs inconsistency, causing coLinux's context switch code to go GPF). -- Dan Aloni da...@gm... |