Hide Forgot
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