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.
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)
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
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]
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]
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
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,
has been included in 2.6.9-89.EL. Will change the status to VERIFIED,
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.