Messages in this thread | | | From | Jonathan Woithe <> | Subject | 2.6.16-rt11: Hires timer makes sleep wait far too long | Date | Tue, 4 Apr 2006 13:10:58 +0930 (CST) |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |