Most recent kernel where this bug did *NOT* occur: 2.6.17.13 (not tested in newer ones before 2.6.19-rc6). Distribution: Slackware 11.0 Hardware Environment: Acer Aspire 3003LCi with an embedded sis900 chipset and PCI1410 CardBus controller Software Environment: kernel 2.6.19-rc6 Problem Description: In 2.6.17.13, when i use the eth0 (sis900) for the first time, it hangs the machine for a while, give one error message about "nobody cares" and them works (with irqpoll option on). In 2.6.19-rc6 i got the machine hang, the error message but the card doesn't communicate with or without irqpoll. The only way it works is with acpi=off. My CardBus controller only got one IRQ in acpi=off. (and sis900 and yenta shares the same IRQ 3). Steps to reproduce: 1) Turn on the machine with acpi activated (with or without irqpoll) 2) ifconfig eth0 some.ip or dhcpcd eth0 3) Not works To make sis900 work: 1) Turn on the machine with acpi=off 2) ifconfig eth0 some.ip or dhcpcd eth0 3) Use the network.
Created attachment 9656 [details] dmesg with acpi=off This is the dmesg when i use 2.6.19-rc6 with acpi=off
Created attachment 9657 [details] dmesg with acpi and without irqpoll This is the dmesg when i use 2.6.19-rc6 with acpi activated. Look the error message in the end of dmesg telling about "disableing" IRQ 3 and suggesting to use irqpoll option at boot.
Created attachment 9658 [details] dmesg with acpi and with irqpoll Now with irqpoll. We can see nothing different. The same lines telling to try "irqpoll" option and disalibling IRQ#3
Created attachment 9659 [details] /proc/interrupts without acpi Look at irq 3, shared by yenta and eth0 (sis900)
Created attachment 9660 [details] /proc/interrupts with acpi activated Now, the /proc/interrupts with acpi activated. Nobody in irq 3.
Can you test whether it works with kernel 2.6.18?
Yes, i test with 2.6.18 now and the behavior is the same of 2.6.17.13. 1) kernel 2.6.18 + acpi (without irqpoll): Not work 2) kernel 2.6.18 + acpi (with irqpoll): Work 3) kernel 2.6.18 (without acpi): Work In 1, irq 3 isn't in /proc/interrupts In 2, the eth0 is in irq 3 in /proc/interrupts. In 3, the eth0 and yenta is sharing irq 3 in /proc/interrupts Do you want the dmesg and /proc/interrupts of all cases?
Created attachment 9764 [details] Include Acer Aspire 3000 in acpi blacklist I saw using acpi=noirq solve my problem in 2.6.19-rc6 (and probably does the same in 2.6.19). Now i got IRQ shared like in acpi=off, no error messages and a system working. I made this small patch to blacklist Acer Aspire 3000. I saw many other systems blacklisted and i don't think is a bad idea made a system that works -;)
The message above seem to all be in PIC-mode. But the dmesg shows this system has an MADT. Please build a kernel with IOAPIC support and re-test. Attach the resulting dmesg and paste the resulting /proc/interrupts. Yes, it is true that PIC mode should work properly, but that becomes somewhat less interesting if IOAPIC mode works. If we are to persue the PIC-mode issue, we'll also need the output from acpidump and lspci -vv.
It works with IO-APIC enabled. This is the solution? (test with 2.6.18.8) Even the irqpoll option isn't needed anymore.
Hi, Peter Please retest this problem using the latest stable kernel. It is noted that local APIC and IO APIC should be enabled in the kernel configuration. Will you please upload the following files after the system is booted successfully ? 1.acpidump 2. .config 3. dmesg Thanks.
(In reply to comment #11) > Please retest this problem using the latest stable kernel. It is noted that > local APIC and IO APIC should be enabled in the kernel configuration. > Will you please upload the following files after the system is booted > successfully ? I will do the tests ASAP and post here what happens. Do you want tests against 2.6.23 or 2.6.22.10?
Piter, plesae test the latest upstream kernel you can get. thanks. And also the acpidump .config and dmesg requested in comment# 11.
Piter, any response?
Machine working fine. Using 2.6.23.9 with APIC and IO-APIC on. Sorry the delay to answer. I only got my hands in problematic machine last week. Thank you! dmesg and .config will be uploaded tomorrow.
As this is not a linux/ACPI bug, and it can work well in IOAPIC mode. Reject this bug and mark it as INVALID. Pleas reopen it if you still have any questions.