Bug 203235 - PMTimer doesn't get detected in an Asus A8V Deluxe motherboard [NEEDINFO]
PMTimer doesn't get detected in an Asus A8V Deluxe motherboard
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.4
x86_64 Linux
medium Severity low
: ---
: ---
Assigned To: Brian Maly
Red Hat Kernel QE team
:
: 203236 (view as bug list)
Depends On:
Blocks: RHEL4u8_relnotes
  Show dependency treegraph
 
Reported: 2006-08-19 13:39 EDT by Kostas Georgiou
Modified: 2009-05-18 15:27 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-18 15:27:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rlerch: needinfo? (bmaly)


Attachments (Terms of Use)
lspci -v output (6.38 KB, application/octet-stream)
2006-08-23 08:34 EDT, Kostas Georgiou
no flags Details
dmesg output (21.11 KB, text/plain)
2006-10-20 06:36 EDT, Kostas Georgiou
no flags Details
test patch (599 bytes, patch)
2008-09-25 01:51 EDT, Brian Maly
no flags Details | Diff

  None (edit)
Description Kostas Georgiou 2006-08-19 13:39:55 EDT
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.
...
Comment 1 Jason Baron 2006-08-22 14:02:25 EDT
*** Bug 203236 has been marked as a duplicate of this bug. ***
Comment 2 Brian Maly 2006-08-22 16:33:13 EDT
What kernel version is this issue reproducable on (i.e. "uname -a")?

What chipset does this motherboard use (i.e. "lspci -v")?
Comment 3 Kostas Georgiou 2006-08-23 08:32:54 EDT
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.
Comment 4 Kostas Georgiou 2006-08-23 08:34:40 EDT
Created attachment 134704 [details]
lspci -v output
Comment 5 Kostas Georgiou 2006-08-26 13:11:19 EDT
Hmm not sure why the "I am providing the requested information for this bug."
button doesn't work. Trying again. 
Comment 6 Kostas Georgiou 2006-08-26 13:21:55 EDT
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.
Comment 7 Brian Maly 2006-09-12 11:30:34 EDT
Can you attach your /var/log/dmesg?



Also, do either of these boot paramaters make a difference?

"acpi_skip_timer_override" or "acpi=off"


Comment 8 Kostas Georgiou 2006-10-20 06:36:28 EDT
Created attachment 138958 [details]
dmesg output
Comment 9 Kostas Georgiou 2006-10-20 07:17:35 EDT
I'll test with acpi_skip_timer_override and acpi=off next week.
Comment 11 Kostas Georgiou 2007-03-18 14:37:29 EDT
Sorry I forgot to reply, no acpi_skip_timer_override/acpi=off doesn't seem to help.
Comment 12 Brian Maly 2007-03-21 16:28:16 EDT
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.
Comment 13 Brian Maly 2008-09-25 01:51:45 EDT
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.
Comment 14 Kostas Georgiou 2008-10-03 07:37:05 EDT
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.
Comment 15 Brian Maly 2008-12-15 14:44:04 EST
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.
Comment 16 Brian Maly 2008-12-22 12:54:23 EST
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.
Comment 17 Kostas Georgiou 2008-12-23 14:30:34 EST
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 :(
Comment 18 Brian Maly 2008-12-23 15:05:44 EST
Thanks for the testing assistance. Ill submit this patch for RHEL4.8.
Comment 20 RHEL Product and Program Management 2008-12-23 15:22:32 EST
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.
Comment 22 Vivek Goyal 2009-01-09 08:54:44 EST
Committed in 78.26.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Comment 27 Han Pingtian 2009-05-05 01:50:14 EDT
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.
Comment 29 errata-xmlrpc 2009-05-18 15:27:42 EDT
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

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