Bug 2375
Summary: | PM timer runs too fast | ||
---|---|---|---|
Product: | Timers | Reporter: | Björn Jacke (bjoern) |
Component: | Other | Assignee: | john stultz (john.stultz) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | acpi-bugzilla, john.stultz, linux |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.5-rc2 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
dmesg output
linux-2.6.6-rc3_acpi-pm-blacklist_A0test0.patch dmidecode data for Asus P5A with double speed PM-Timer linux-2.6.6-verify-pmtmr-rate.patch |
Description
Björn Jacke
2004-03-26 05:18:36 UTC
Could you please attach dmesg output for this system? Created attachment 2449 [details]
dmesg output
Bj if I omit acpi=force, ACPI won't be used because the BIOS is from '00. However though the BIOS is that old ACPI works fine there and I want to use some ACPI features like thottling etc. cause the system is running fanless and ACPI has other goodies. The ony thing which doesn't work with ACPI is the ACPI timer. BTW - If I omit acpi=force, also PM Timer is not being used. I can't say if that is a hardware problem that the ACPI timer runs at double speed or if it's a problem of the driver. If I change the 286 value to 143 in timer_pm.c the clock works correct. As far as I know the pm timer cannot be disabled via kernel option, so distribution kernels which have PM Timer enabled would be unusable if no workaround/fix will be implemented. If this probem occurs on other systems as well, maybe a 1 second comparison to TSC to see if 286 is the correct value could be implemented? <i>If this probem occurs on other systems as well, maybe a 1 second comparison to TSC to see if 286 is the correct value could be implemented?</i> Well, the problem is if we're on a laptop that changes cpufreq speed, we can't use the TSC as a stable timesource, and if we're on a system that's using IDE PIO mode, then we may lose ticks and thus we cannot use the PIT. Its one of those, try to make valid time from a collection of possibly incorrect clocks. :P I'm suspecting we will just need to blacklist your system and any other systems that have this problem. This is probably also part of the reason why your system is considered too old to use ACPI. As for a way to disable the ACPI PM time source in distro kernels, booting w/ "clock=tsc" should work around the issue for now. Re: why acpi blacklist date There is no magic in this -- just a way for us to spend our effort on newer systems and not get sidetracked trying to debug older systems which the OEMS will not fix and most of which have been running fine w/o ACPI on Linux for years. There are lots of systems older than the cutoff date that run ACPI just fine, and even bug #1307 for listing machines for a possible "whitelist" to exempt them from the cutoff so users will not need "acpi=force". (though only with many votes will i implement the list) Note that you can still run ACPI w/ CONFIG_X86_PM_TIMER=n thought that would be a workaround. Can you please verify that ACPI thermal management and ACPI or cpufreq performance management is disabled, i.e. echo 1 > /proc/acpi/processor/./throttling echo 0 > /proc/acpi/processor/./throttling [that's a double check which seems, unfortunately, to be necessary...] and not loading any cpufreq driver? Also, how do you detect that the PM timer runs too fast? the delay routine of the PM timer is TSC-based, after all... no throttling active and no cpufreq scaling used at all. I see that PM timer runs too fast because the system timer is passes 2 hours while the RTC and my clock on the wall pass just one hour ;-) But if it seems to be cerain that the hardware is the bad piece, then maybe setting clock=tsc is the only way to workaround this. Created attachment 2759 [details]
linux-2.6.6-rc3_acpi-pm-blacklist_A0test0.patch
Would you mind trying out this patch to see if I got the dmi blacklist entry
written properly? It should detect your system and disable the acpi pm time
source, removing the need to use "clock=tsc".
Is there a way to validate the PM timer on all systems at run-time? This would be preferable to maintaining a DMI blacklist for this issue. Note also that as we're running out of ACPI configuration bugs, the last bug to fix will be to delete the ACPI cutoff date;-) Created attachment 2982 [details]
dmidecode data for Asus P5A with double speed PM-Timer
Created attachment 2984 [details]
linux-2.6.6-verify-pmtmr-rate.patch
Calibrate PMTMR against PIT channel 2, then reject PMTMR if its rate is not
what we expect. Patch is against vanilla linux-2.6.6.
Heh, I was actually just finishing up my own very simliar patch for this. I assume you've tested it on your setup and it worked properly? If so, I'd say send it to Andrew (and CC Dominik and me). Just a status update: Joris' patch (validate-pm-timer-rate-at-boot-time.patch) has been included into Andrew's tree (2.6.7-rc2-mm1 and later)for testing. Joris' patch has been included into mainline, so I'm closing the bug. Should the issue reappear or the fix doesn't work for you, please reopen. |