Bug 7595
Summary: | irq 3: nobody cared - PIC-mode - sis900 - Acer Aspire 3003LCi | ||
---|---|---|---|
Product: | ACPI | Reporter: | Piter PUNK (piterpk) |
Component: | Config-Interrupts | Assignee: | ykzhao (yakui.zhao) |
Status: | REJECTED INVALID | ||
Severity: | high | CC: | acpi-bugzilla, bunk, venza |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.19-rc6 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
dmesg with acpi=off
dmesg with acpi and without irqpoll dmesg with acpi and with irqpoll /proc/interrupts without acpi /proc/interrupts with acpi activated Include Acer Aspire 3000 in acpi blacklist |
Description
Piter PUNK
2006-11-29 05:26:13 UTC
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. |