Kernel Bug Tracker – Bug 7595
irq 3: nobody cared - PIC-mode - sis900 - Acer Aspire 3003LCi
Last modified: 2007-12-18 23:18:17 UTC
Most recent kernel where this bug did *NOT* occur: 188.8.131.52 (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 184.108.40.206, 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 220.127.116.11.
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
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 18.104.22.168)
Even the irqpoll option isn't needed anymore.
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 ?
(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 22.214.171.124?
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 126.96.36.199 with APIC and IO-APIC on.
Sorry the delay to answer. I only got my hands in problematic
machine last week.
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.