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
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.