|09-02-09, 04:24 PM||#1|
Join Date: Sep 2009
190.25 triggers a fault detection/condition in Linux hrtimer code; patch/workaround
with recent mainline Linux kernels, including 2.6.31-rc7, and the NVidia binary driver installed, the system sporadicly
(approx. once every five or so system starts) boots into a state with limited
system responsiveness (e.g. second-long latency to console keyboard input, gaps
in video playback under X).
Everytime (and only) when this occurs, dmesg displays the following line:
"hrtimer: interrupt too slow, forcing clock min delta to [...] ns"
This has happened for me in the past, but with NVIDIA-Linux-x86_64-185.18.36 and NVIDIA-Linux-x86_64-190.25, it happens very often (approx. every third boot).
Going further into detail, this is caused by a check in the linux hrtimer code which is supposed to detect a "hanging" timer interrupt condition on slow systems. This is in the file "kernel/hrtimer.c" of the Linux kernel sources (line 1237 ff. as of 2.6.31-rc), and was introduced by the following patch:
I don't know about the internals, but it seems likely to be the result of some kind of delay during initialization of the nvidia driver module.
If that is the case, then one would have to decide if this is the
intended behaviour of the kernel code, and in this case, the NVidia driver has a bug or needs a workaround itself.
The attached patch against linux-2.6.31-rc is a workaround for the /Linux kernel/ that reliably works for me, but without further investigation and the exact cause and reason for applying, it is not likely to be acceptable for the official kernel sources. If someone else is having the problem, the patch should be safe to use, though.
Coming to my hardware setup, this is described in an entry for the Linux kernel bugtracker:
- patch against Linux-2.6.31-rc7
- nvidia-bug-report.log.gz System with the error and the X server started with loglevel 6