Bug 2090

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.