Bug 4442 - Double clock ticks -- IOAPIC - ATI chipset x86_64
Summary: Double clock ticks -- IOAPIC - ATI chipset x86_64
Status: REJECTED DUPLICATE of bug 3927
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Interrupts (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: acpi_config-interrupts
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-04 14:09 UTC by Christopher Allen Wing
Modified: 2005-08-16 15:15 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.11.6
Tree: Mainline
Regression: ---


Attachments
2.6.11.6 boot messages with ACPI enabled and APIC enabled (clock runs 2x speed) (13.17 KB, text/plain)
2005-04-04 14:10 UTC, Christopher Allen Wing
Details
/proc/interrupts on 2.6.11.6 with ACPI enabled and APIC enabled (clock runs at 2x speed) (510 bytes, text/plain)
2005-04-04 14:12 UTC, Christopher Allen Wing
Details
2.6.11.6 boot messages with ACPI enabled and APIC disabled (clock runs normally) (13.48 KB, text/plain)
2005-04-04 14:14 UTC, Christopher Allen Wing
Details
/proc/interrupts on 2.6.11.6 with ACPI enabled and APIC disabled (clock runs normally) (551 bytes, text/plain)
2005-04-04 14:15 UTC, Christopher Allen Wing
Details
2.6.11.6 boot messages with ACPI disabled and APIC enabled (disk controller doesn't work) (6.94 KB, text/plain)
2005-04-04 14:18 UTC, Christopher Allen Wing
Details
output of 'acpidmp' on the machine, with APIC enabled in the BIOS (60.29 KB, text/plain)
2005-04-04 14:25 UTC, Christopher Allen Wing
Details

Description Christopher Allen Wing 2005-04-04 14:09:31 UTC
Distribution: Red Hat Enterprise Linux 3/4
Hardware Environment: HP dx5150 (Athlon64, ATI Radeon Xpress 200 chipset)
Software Environment:
Problem Description:

When APIC mode is enabled on this machine, the timer interrupt seems to be
received twice as often as desired, causing the clock to run at double speed.
When APIC mode is disabled, the clock works properly (and everything is labeled
'XT-PIC' in /proc/interrupts). I can disable APIC mode in the BIOS or via
'noapic' on the kernel command line; either way, the clock works properly.

I cannot boot the machine with APIC mode enabled and ACPI IRQ routing disabled
('pci=noacpi'). The kernel starts up but hangs when probing SATA drives- I'm
guessing that with ACPI disabled the disk controller interrupts aren't getting
through.

Steps to reproduce:

The problem is seen on the latest kernel.org kernel (2.6.11.6) as well as
various Red Hat kernels (both 2.4 and 2.6).

This sounds similar to bug #4092; however, unlike #4092, I tried vanilla 2.6.9
from kernel.org and the clock still ran at double speed with APIC enabled.
(according to the reporter of #4092, 2.6.9 worked properly)
Comment 1 Christopher Allen Wing 2005-04-04 14:10:46 UTC
Created attachment 4848 [details]
2.6.11.6 boot messages with ACPI enabled and APIC enabled (clock runs 2x speed)
Comment 2 Christopher Allen Wing 2005-04-04 14:12:05 UTC
Created attachment 4849 [details]
/proc/interrupts on 2.6.11.6 with ACPI enabled and APIC enabled (clock runs at 2x speed)

Note that there are twice as many 'timer' interrupts as local APIC timer
interrupts. The clock runs at double normal speed for this reason.
Comment 3 Christopher Allen Wing 2005-04-04 14:14:03 UTC
Created attachment 4850 [details]
2.6.11.6 boot messages with ACPI enabled and APIC disabled (clock runs normally)

This is with 'noapic' on the kernel command line. (ACPI still enabled)
Interrupt routing uses the PIC and the clock works properly.
Comment 4 Christopher Allen Wing 2005-04-04 14:15:27 UTC
Created attachment 4851 [details]
/proc/interrupts on 2.6.11.6 with ACPI enabled and APIC disabled (clock runs normally)

This is with the APIC disabled via 'noapic' on the kernel command line. The
clock runs at normal speed. Note that 'timer' and 'LOC' show approximately the
same number of interrupts
Comment 5 Christopher Allen Wing 2005-04-04 14:18:48 UTC
Created attachment 4852 [details]
2.6.11.6 boot messages with ACPI disabled and APIC enabled (disk controller doesn't work)

This is with 'pci=noacpi' on the command line. The system doesn't come up all
the way; it hangs while probing SATA drives. I assume this is because with ACPI
interrupt routing disabled, the disk controller interrupt doesn't get routed
properly.
Comment 6 Christopher Allen Wing 2005-04-04 14:25:36 UTC
Created attachment 4853 [details]
output of 'acpidmp' on the machine, with APIC enabled in the BIOS

This is the output of acpidmp. I cannot disassemble this with 'iasl' (from
acpica-unix-20050309). I get a segfault every time I try:


% acpixtract DSDT acpidmp-apic >dsdt.out
% ./iasl -d dsdt.out
 
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20050309 [Apr  4 2005]
Copyright (C) 2000 - 2005 Intel Corporation
Supports ACPI Specification Revision 3.0
 
Loading Acpi table from file dsdt.out
Segmentation fault
%


I tried doing the same thing on the with the output of acpidmp from a different
machine (not x86_64) and iasl also crashed. The segfault is in AcpiTbChecksum()
trying to checksum past the end of a buffer. Does the latest version of iasl
work properly, or are the ACPI tables on my machines just corrupted?
Comment 7 Christopher Allen Wing 2005-04-04 14:29:48 UTC
Here's an example of what 'clock runs at double speed' means:


(on 2.6.11.6 with ACPI and APIC enabled)
% cat /proc/interrupts; sleep 10; cat /proc/interrupts
           CPU0
  0:    5908477    IO-APIC-edge  timer
LOC:    2953670

( and then 5 seconds go by, instead of 10 )

           CPU0
  0:    5918489    IO-APIC-edge  timer
LOC:    2958675


which you can see amounts to 2000 'timer' ints/second (which is wrong), but 1000
local APIC int/second (which is correct).
Comment 8 Robert Moore 2005-04-04 15:11:40 UTC
The windows version of iASL disassembles this ok, so maybe there is something 
wrong with the unix/linux generation.

Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20050329 [Apr  1 2005]
Copyright (C) 2000 - 2005 Intel Corporation
Supports ACPI Specification Revision 3.0

Loading Acpi table from file dsdt.dat
Acpi table [DSDT] successfully installed and loaded
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
...............................................................................
.........................................
...............................................................................
.........................................
....................
Parsing completed
Disassembly completed, written to "dsdt.dsl"
Comment 9 Per G 2005-05-08 15:18:56 UTC
btw, On my ATI based mobo (MSI) the trick with using noapic as an kernel 
parameter doesn't work (neither disabling APIC in bios). The system hangs when 
it's loading SATA. I have the system on one of the SATA drives, so I can't 
tell if it works with SATA removed.
I've tried on 2.6.11.6, 2.6.11.8 and,
using 2.6.12-rc4 didn't help either.

The clock have decided to run in 2x speed it seems....
Comment 10 Edwin Fine 2005-05-09 22:05:06 UTC
Distribution: Red Hat Fedora Core 3 2.6.9-1.667
Hardware Environment: HP a1017c (Athlon 64 mobo (MSI-7093), ATI Radeon Xpress
200 chipset)
No BIOS updates available from HP web site.

I am seeing the same fast clock problem, plus "hda: lost interrupt", "warning:
many lost ticks", and "Your time source seems to be instable or some driver is
hogging interupts." (sic).

Adding noapic seems to have eliminated the fast clock problem; noacpi did not.
So noapic may have solved this for now, although I still haven't got my xorg
driver working yet, and I am not sure if there are other hitherto-unseen problems.
Comment 11 Chip Daiger 2005-05-10 16:02:21 UTC
Seeing the same here on an Emachine T6212 (Athlon 64 3200+ ATI Radeon Xpress
200, I think the mobo is a modified MSI, Suse 9.3 stock 64-bit kernel).  Clock
acts normal if I disable APIC in the BIOS or passing to the kernel, but then my
NIC starts acting funky (pings that time like X ms, 4X ms, X ms, 4X ms, etc.).
I hope this can get fixed, as I love this machine for the price, and changing
the time is really a pain! :)
Comment 12 Edwin Fine 2005-05-10 19:38:52 UTC
I've been running for a day with the noapic option now, and I am no longer
getting APIC errors, the clock is accurate, and the "hda: lost interrupt
messages" are gone. 

This may or may not be germane, but I am having a hard time getting the X server
to work stably. I tried the VESA driver (only works up to 1024x768), but when I
use it, the mouse gets jerky and sometimes loses its position, especially during
disk access. Performance seems atrocious when there is a lot of disk activity. A
copy of Fedora I have running on top of VMWare WS5 for XP on an Athlon XP 2800+
seems to run better. That's sad. I see mouse positioning lost-type messages in
dmesg, too. The machine froze up twice when I switched between graphics and
console (Ctrl-Alt-F1), so I suspect the driver is not playing nice with the
on-board chipset. Or the board is flaky. Who knows? I can't get the ATI native
x86_64 graphics driver to install,  and I'm losing patience. I'm now running in
init 3 mode. If I can't get things to work nicely soon, I'll probably take the
machine back to the store and build one myself. Without anything made by "ATI"
in it.
Comment 13 JR Boyens 2005-07-21 21:48:15 UTC
I'm seeing this on a new Acer Ferrari 4000 laptop with a Turion 2.0Ghz
processor. noapic will make the clock stable, but will disable quite a few of
the internal devices on the laptop, so it's not much of an option. I've had to
fix the ACPI DSDT on the laptop because of a buggy compile with the MSFT
compiler, I'm not sure of the legal ramifications of posting the disassembled
code here, so until I'm specifically asked to do so, I won't.
Comment 14 JR Boyens 2005-07-26 23:35:29 UTC
I was able to fix this problem quite well by adding: no_timer_check to my
bootparams. Not sure what this does or how it works, but it does. :)
Comment 15 Len Brown 2005-08-16 15:15:25 UTC
submitter of bug 4092 was mistaken -- this was a problem in 2.6.9 also.


*** This bug has been marked as a duplicate of 3927 ***

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