Bug 4442
| Summary: | Double clock ticks -- IOAPIC - ATI chipset x86_64 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Christopher Allen Wing (wingc) |
| Component: | Config-Interrupts | Assignee: | acpi_config-interrupts |
| Status: | REJECTED DUPLICATE | ||
| Severity: | normal | CC: | john.stultz, ken, oakad |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.11.6 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
2.6.11.6 boot messages with ACPI enabled and APIC enabled (clock runs 2x speed)
/proc/interrupts on 2.6.11.6 with ACPI enabled and APIC enabled (clock runs at 2x speed) 2.6.11.6 boot messages with ACPI enabled and APIC disabled (clock runs normally) /proc/interrupts on 2.6.11.6 with ACPI enabled and APIC disabled (clock runs normally) 2.6.11.6 boot messages with ACPI disabled and APIC enabled (disk controller doesn't work) output of 'acpidmp' on the machine, with APIC enabled in the BIOS |
||
Created attachment 4848 [details]
2.6.11.6 boot messages with ACPI enabled and APIC enabled (clock runs 2x speed)
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.
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.
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
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.
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?
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).
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" 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.... 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. 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! :) 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. 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. 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. :) |
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)