A few days ago I compiled and tested 2.6.16-rt11 on a Pentium3 desktop box
with the high resolution timer feature enabled. It was set to a frequency
of 1000. Things appeared to work fine so I tried exactly the same thing
on a 2.0 GHz Centrino-based laptop last night.
Unfortunately the laptop had an issue: whenever the system scripts called
sleep the system would wait for *way* longer than it should have. Calling
sleep 1
would give rise to a wait of as much as 45 seconds before the command
prompt returned.
This was similar to an issue I had earlier (around 2.6.13) which was
associated with the new clock source infrastructure. However, this time
around the timekeeping (as in the time of day reported by "date") did not
appear to run slow as it did in this previous fault condition.
I tested the situation under the four clock sources reported to be available
in /sys/devices/system/clocksource/clocksource0/:
pit, jiffies, acpi_pm (the default), tsc
The actual amount of time waited by a "sleep 1" call from bash was tested
at least twice for each timer source:
pit: 12 seconds, 29 seconds, 28 seconds
tsc: 45 seconds, 45 seconds
acpi_pm: 45 seconds, 29 seconds
jiffies: 45 seconds, 32 seconds
I then rebuilt the 2.6.16-rt11 kernel without the HR-timers option selected.
After rebooting, running sleep worked exactly as expected.
I'm more than happy to run additional tests to try to narrow down the
problem.
Regards
jonathan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
