Distribution: Debian Sid Hardware Environment: Arima W720-K8/eMachines M6807 AMD64 Laptop Software Environment: Problem Description: I am unable to use acpi, ioapic, and my nic while under just acpi even. I don't think much of anything works when ioapic is enabled currently. Current kernels got around the ioapic part of the problem by just forcing it off. It would be nice if it is possible for me to fix the madt easily to just replace that like can be done with dsdt tables. Also the ioapic fix still doesn't allow the nic to work with acpi enabled. I am currently reading the ACPI docs so I can learn more about it so I will be less of a burden on the acpi developers. I have only finished reading the first 130 pages so far though. I have included the logs from acpidmp, biosdecode, dmidecode, and mptable. If you need anything else just let me know. BTW there is no way to reenable apic if its forced off "apic" at boot seems to be ignored afaict. Steps to reproduce: Buy a eMachines M6805/M6807. Install linux with acpi/ioapic/lapic enabled. ;)
Created attachment 2109 [details] M6807 acpidmp output
Created attachment 2110 [details] M6807 biosdecode output
Created attachment 2111 [details] M6807 dmesg output with apic
Created attachment 2112 [details] M6807 dmesg output with acpi=off noapic nolapic
Created attachment 2113 [details] M6807 dmidecode output
Created attachment 2114 [details] M6807 /proc/interrupts output with apic
Created attachment 2115 [details] M6807 /proc/interrupts output with acpi=off noapic nolapic
Created attachment 2116 [details] M6807 mptable output
ACPI complains a lot, but what actually fails to work when you boot with ACPI and IOAPIC? Also, I'm not clear on what or why your APIC is disabled automatically on this box -- can you show the dmesg that shows it being disabled? When you boot the same APIC-enabled kernel with "acpi=off", then MPS will configure your APIC -- what do /proc/interrupts look like then? It would be good to verify that your USB ports are working if you can plug in a USB mouse or something. Also when in ACPI mode, please verify that a button press gives you an acpi interrupt seen in /proc/interrupts. (if acpid is enabled, it will receive this event and shut down the machine). please attach the output from lspci -v so I can corrolate the pci device numbers with devices. > 10: 0 IO-APIC-edge acpi, via82cxxx This doesn't look right -- edge triggered APIC interrupts should not be shared. thanks, -Len
Created attachment 2128 [details] M6807 2.6.3-rc3 dmesg output with acpi apic
Created attachment 2129 [details] M6807 2.6.3-rc3 dmesg output with acpi noapic
Created attachment 2130 [details] M6807 2.6.3-rc3 dmesg output with acpi=off apic
Created attachment 2131 [details] M6807 2.6.3-rc3 dmesg output with acpi=off noapic
Created attachment 2132 [details] M6807 2.6.3-rc3 /proc/interrupts output with acpi apic
Created attachment 2133 [details] M6807 2.6.3-rc3 /proc/interrupts output with acpi noapic
Created attachment 2134 [details] M6807 2.6.3-rc3 /proc/interrupts output with acpi=off apic
Created attachment 2135 [details] M6807 2.6.3-rc3 /proc/interrupts output with acpi=off noapic
Created attachment 2136 [details] M6807 2.6.3-rc3 lspci -v output with acpi apic
Created attachment 2137 [details] M6807 2.6.3-rc3 lspci -v output with acpi noapic
Created attachment 2138 [details] M6807 2.6.3-rc3 lspci -v output with acpi=off apic
Created attachment 2139 [details] M6807 2.6.3-rc3 lspci -v output with acpi=off noapic
About the apic message I got before, I didn't see it this time so I am not 100% sure if I didn't happen to somehow imagine it. Or else maybe its only seen when in x86-64 mode, I was using regular x86 kernel for the tests tonight. My via rhine II and usb keyboard will not work with anything other than acpi=off noapic, I didn't try any of the other hardware at the time. I tried hitting the power/sleep button and it appeared to turn off the system immediately, but when I hit the power button again it lit up (the button has a blue led surrounding it) but the system otherwise did not show any signs of waking back up. To get it to turn back on normally again I had to first remove all power (AC/BATT).
For reference Windows XP Pro shows the following IRQ distribution: 0 - System Timer 1 - Keyboard 8 - RTC 10 - ACPI 12 - Mouse 13 - FPU 14 - IDE Primary 15 - IDE Secondary 16 - Radeon 9600 17 - Cardbus 18 - Broadcom Wireless 19 - VIA 1394 21 - EHCI USB 21 - UHCI USB 21 - UHCI USB 21 - UHCI USB 22 - Realtek AC97 Audio 22 - SmartLink Modem 23 - Via Rhine II
When the system is in ACPI mode, the power button should not immediately power off the system, but should send an event to the OS which will be seen in /proc/interrupts and will send a message to acpid (if configured) which would do a graceful shutdown. This should be the case no matter if interrupts are from PIC or APIC -- as long as ACPI is enabled. Are you sure that you tested the power button when in ACPI mode?
Ok I am seeing different results tonight, or maybe i used apci=off by accident before. With ACPI and APIC both enabled it does not seem to do anything no interrupt increase, etc. With ACPI enabled but noapic set then I get a bunch of errors messages (if i don't time it right or something it turns completely off, eg no resume). The errors appear to be the following (note I have no serial port on this machine). Error acpi_ev_dispatch: No handler or method for GPE[ 0], disabling event. It seems to go from 0-F for the event and it never stops scrolling. I am not sure if that is the only error it prints since I have no way to stop the scrolling afaict.
Created attachment 2403 [details] m6805 dmesg with ioapic on Here's the dmesg from my m6805 after applying my ioapic patch mentioned in ACPI bug 1581. Battery status works, but power button turns off the machine immediately.
Created attachment 2679 [details] 2.6.5 test patch please try this 2.6.5 test patch in ACPI + IOAPIC mode and let me know if you see a difference in dmesg and /proc/interrupts.
What is the status of this patch? It looks good to me. Should I merge it?
I'm confident that the "2.6.5 test patch" is correct -- as this is what we do on i386. It should help systems such as this where the SCI is shared with another device. I expect is is necessary, but not sufficient, to fix the various problems on this box. But think the real fix is to delete x86_64/kernel/mpparse.c and use the i386 version for both architectures.
Merging i386 and x86-64 mpparse is not feasible right now. It will require syncing the i386 and x86-64 APIC code first, which is a much bigger project.
I merged the gsi fix patch now
with that patch, is this machine working the same in x86_64 mode as it does in i386 mode? What problems remain on this box?
no reply on the patch of a month ago... As Andi merged it and it is now in 2.6.7-rc1, I'm closing this bug. If there are new/additional problems, please open a new one.