The PMTimer doesn't get detected in an Asus A8V Deluxe motherboard (VIA K8T800Pro) so the system uses TSC (even when you use the notsc kernel option). This results in problems (#174390 for example) with dual core cpus since TSC isn't stable there. $ dmesg ... time.c: Using 1.193182 MHz PIT timer. time.c: Using PIT/TSC based timekeeping. ... Under FC5 the PMTimer is detected fine in the same motherboard (with a single core cpu though) $ dmesg ... ACPI: PM-Timer IO Port: 0x808 time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer. ...
*** Bug 203236 has been marked as a duplicate of this bug. ***
What kernel version is this issue reproducable on (i.e. "uname -a")? What chipset does this motherboard use (i.e. "lspci -v")?
I tried kernel-smp-2.6.9-34.0.2.EL kernel-smp-2.6.9-42.EL (x86_64 of course). The chipset is K8T800Pro, I am attaching the output of lspci -v as well.
Created attachment 134704 [details] lspci -v output
Hmm not sure why the "I am providing the requested information for this bug." button doesn't work. Trying again.
It seems that the patch in bug #203374 solves the problems with using TSC so I am dropping the severity to low since the machine is usable now.
Can you attach your /var/log/dmesg? Also, do either of these boot paramaters make a difference? "acpi_skip_timer_override" or "acpi=off"
Created attachment 138958 [details] dmesg output
I'll test with acpi_skip_timer_override and acpi=off next week.
Sorry I forgot to reply, no acpi_skip_timer_override/acpi=off doesn't seem to help.
can you boot with "acpi_dbg_level=1 acpi_dbg_layer=1" boot args and attach the debugging output? Looks like x86_64 acpi parser breakage of some sort.
Created attachment 317655 [details] test patch This is a test patch that may resolve the issue. Is the reporter willing to test this patch, or willing to instead test a kernel? It would be optimal to get this issue fixed in the upcoming release, however we do not have this hardware in-house and must rely on outside testing for verification.
I can easilly test the patch or a kernel. I have one of the machines free I think so I can load rhel4 and run any tests that you need. I can also provide you root access to the machine if you prefer. Let me know if this will make it easier for you. Recently the powernow-k8.tscsync=1 kernel option that I was using to stop tsc from drifting stopped working so I was about to have a look again at the problem.
Just wanted to follow up on testing results. Can you provide more info about tscsync not working? Is this really broken? I am wondering if we should open a seperate bug for that.
Can we possibly test the proposed patch? I would like to see this make RHEL4.8 if possible. Also, did you resolve your tscsync issue? powernow-k8 was changed to a module for RHEL4.7 so now you have to "modprobe powernow-k8 tscsync=1" to set the tscsync option.
With the patch I get the following: +ACPI: PM-Timer IO Port: 0x808 -time.c: Using 1.193182 MHz PIT timer. -time.c: Detected 2002.647 MHz processor. +time.c: Using 3.579545 MHz PM timer. +time.c: Detected 2002.656 MHz processor. -time.c: Using PIT/TSC based timekeeping. +Disabling vsyscall due to use of PM timer +time.c: Using PM based timekeeping So the PMTimer is now detected and used by default. As for tscsync I can only say "D'oh!", I never noticed that it was switched to a module :(
Thanks for the testing assistance. Ill submit this patch for RHEL4.8.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Committed in 78.26.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Due to comment#17, the bug had been fixed. And the patch, linux-2.6.9-pmtimer-properly-detect-pmtimer-on-asus-a8v-motherb.patch has been included in 2.6.9-89.EL. Will change the status to VERIFIED, thanks.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-1024.html
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days