ive hit this a few times, but never been able to reproduce it when i actually try so that i could hook a debugger up ... this isnt a recent development, but i remembered when i hit it again this week. i'm using xorg-server-1.3.0.0 at the moment. i seem to recall hitting this on x86 and ppc, but most recently it cropped up on my amd64. sometimes i get a little clock drift where time runs faster ... so i run a standard ntp client to fix the time and sometimes when i do, the X process chews up the CPU until the clock has caught up to where it was before i fixed the time consider: - clock is set to 15:09:03 - real time is 15:07:50 - run ntp to set clock to real time - X is no longer responsive beyond moving the mouse - ssh into the box and see that "X" is now chewing the cpu - X continues using 100% of the CPU until real time catches up to ~15:09:03 my system is obviously Gentoo ;), but not sure what else my systems have had in common since this has spanned GCC/glibc/X/etc... versions
Should be fixed by: commit d285833290316cb5dd1e7f1e52c96be3e9cf21cd Author: Daniel Stone <daniel@fooishbar.org> Date: Wed Oct 25 23:57:00 2006 +0300 GetTimeInMillis: spuport monotonic clock Add support for CLOCK_MONOTONIC from clock_gettime, and use that in GetTimeInMillis() if available, falling back to the old gettimeofday() implementation. This is _slightly_ faster on some 64-bit architectures, and _slightly_ slower on others (though barely measurable).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.