Bug 2375 - PM timer runs too fast
Summary: PM timer runs too fast
Status: CLOSED CODE_FIX
Alias: None
Product: Timers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: john stultz
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-26 05:18 UTC by Björn Jacke
Modified: 2006-12-04 11:48 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.5-rc2
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
dmesg output (7.56 KB, text/plain)
2004-03-29 08:39 UTC, Björn Jacke
Details
linux-2.6.6-rc3_acpi-pm-blacklist_A0test0.patch (2.29 KB, patch)
2004-04-29 19:32 UTC, john stultz
Details | Diff
dmidecode data for Asus P5A with double speed PM-Timer (8.37 KB, text/plain)
2004-05-26 14:51 UTC, Joris van Rantwijk
Details
linux-2.6.6-verify-pmtmr-rate.patch (1.78 KB, patch)
2004-05-26 15:19 UTC, Joris van Rantwijk
Details | Diff

Description Björn Jacke 2004-03-26 05:18:36 UTC
the ACPI PM timer runs exactly twice as fast as it should. I append the 
dmidecode output. This is a Gigabyte Board with ALADDIN5 chipset. ACPI runs very 
nice on that system with acpi=force, just the new PM timer is *a bit* too fast.
If you need more information, let me know.


Steps to reproduce:
SMBIOS 2.2 present.
DMI 2.2 present.
32 structures occupying 795 bytes.
DMI table at 0x000F0800.
Handle 0x0000
	DMI type 0, 19 bytes.
	BIOS Information Block
		Vendor: Award Software International, Inc.
		Version: 4.51 PG
		Release: 09/19/00
		BIOS base: 0xE0000
		ROM size: 64K
		Capabilities:
			Flags: 0x000000007FCBDE90
Handle 0x0001
	DMI type 1, 25 bytes.
	System Information Block
		Vendor:  
		Product:  
		Version:  
		Serial Number:  
Handle 0x0002
	DMI type 2, 8 bytes.
	Board Information Block
		Vendor:  
		Product: ALADDIN5
		Version:  
		Serial Number:  
Handle 0x0003
	DMI type 3, 13 bytes.
	Chassis Information Block
		Vendor:  
		Chassis Type: Unknown
		Version:  
		Serial Number:  
		Asset Tag:  
Handle 0x0004
	DMI type 4, 32 bytes.
	Processor
		Socket Designation: Socket 7
		Processor Type: Central Processor
		Processor Family: K5 Family
		Processor Manufacturer: AMD
		Processor Version: AMD-K6
Handle 0x0005
	DMI type 5, 28 bytes.
	Memory Controller
Handle 0x0006
	DMI type 6, 12 bytes.
	Memory Bank
		Socket: A0
		Banks: 0 1
		Speed: 60nS
		Type: PARITY ECC DIMM SDRAM 
		Installed Size: 128Mbyte
		Enabled Size: 128Mbyte
Handle 0x0007
	DMI type 6, 12 bytes.
	Memory Bank
		Socket: A1
		Banks: 0 1
		Speed: 60nS
		Type: PARITY ECC DIMM SDRAM 
		Installed Size: 128Mbyte
		Enabled Size: 128Mbyte
Handle 0x0008
	DMI type 6, 12 bytes.
	Memory Bank
		Socket: A2
		Banks: 2 3
		Speed: 60nS
		Type: PARITY ECC DIMM SDRAM 
		Installed Size: 128Mbyte
		Enabled Size: 128Mbyte
Handle 0x0009
	DMI type 6, 12 bytes.
	Memory Bank
		Socket: A3
		Banks: 2 3
		Speed: 60nS
		Type: FPM PARITY ECC 
		Installed Size: 128Mbyte
		Enabled Size: 128Mbyte
Handle 0x000A
	DMI type 6, 12 bytes.
	Memory Bank
		Socket: A4
		Banks: 4 5
		Speed: 60nS
		Type: UNKNOWN 
		Installed Size: 64Mbyte
		Enabled Size: 64Mbyte
Handle 0x000B
	DMI type 6, 12 bytes.
	Memory Bank
		Socket: A5
		Banks: 4 5
		Speed: 60nS
		Type: UNKNOWN 
		Installed Size: 64Mbyte
		Enabled Size: 64Mbyte
Handle 0x000C
	DMI type 7, 19 bytes.
	Cache
		Socket: Internal Cache
		L1 Internal Cache: write-back
		L1 Cache Size: 64K
		L1 Cache Maximum: 64K
		L1 Cache Type: Synchronous 
Handle 0x000D
	DMI type 7, 19 bytes.
	Cache
		Socket: External Cache
		L2 External Cache: write-back
		L2 Cache Size: 1024K
		L2 Cache Maximum: 512K
		L2 Cache Type: Synchronous 
Handle 0x000E
	DMI type 8, 9 bytes.
	Port Connector
		Internal Designator: PRIMARY IDE
		Internal Connector Type: On Board IDE
		External Designator:  
		External Connector Type: None
		Port Type: Other
Handle 0x000F
	DMI type 8, 9 bytes.
	Port Connector
		Internal Designator: SECONDARY IDE
		Internal Connector Type: On Board IDE
		External Designator:  
		External Connector Type: None
		Port Type: Other
Handle 0x0010
	DMI type 8, 9 bytes.
	Port Connector
		Internal Designator: FDD
		Internal Connector Type: On Board Floppy
		External Designator:  
		External Connector Type: None
		Port Type: U1
Comment 1 john stultz 2004-03-26 13:19:00 UTC
Could you please attach dmesg output for this system? 
Comment 2 Björn Jacke 2004-03-29 08:39:26 UTC
Created attachment 2449 [details]
dmesg output
Comment 3 john stultz 2004-03-29 10:46:56 UTC
Bj
Comment 4 Björn Jacke 2004-03-30 04:08:09 UTC
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?
Comment 5 john stultz 2004-03-30 07:14:42 UTC
<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. 
Comment 6 Len Brown 2004-03-30 11:19:29 UTC
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. 
 
Comment 7 Dominik Brodowski 2004-04-06 14:43:11 UTC
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...
Comment 8 Björn Jacke 2004-04-07 13:39:41 UTC
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.
Comment 9 john stultz 2004-04-29 19:32:56 UTC
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".
Comment 10 Len Brown 2004-05-26 00:43:45 UTC
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;-) 
 
Comment 11 Joris van Rantwijk 2004-05-26 14:51:00 UTC
Created attachment 2982 [details]
dmidecode data for Asus P5A with double speed PM-Timer
Comment 12 Joris van Rantwijk 2004-05-26 15:19:10 UTC
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.
Comment 13 john stultz 2004-05-26 15:46:43 UTC
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). 
 
Comment 14 john stultz 2004-06-14 15:38:35 UTC
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. 
Comment 15 john stultz 2004-06-21 16:23:20 UTC
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. 

Note You need to log in before you can comment on or make changes to this bug.