Bug 1564
| Summary: | irq5: nobody cared, when card enabled in 2nd yenta slot | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Shaohua (shaohua.li) |
| Component: | Config-Hotplug | Assignee: | Len Brown (lenb) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | acpi-bugzilla, mmokrejs |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6-test9 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
all info with acpi=off, pci=noacpi and acpi
patch for the error updated patch updated patch debug patch proposed final patch dmesg output on 2.6.4 kernel with full debug acpidmp from 2.6.4 running system 2.6.5-rc2 dmesg 2.6.5-rc2 with the proposed patch 2004-03-20 19:24 applied |
||
|
Description
Shaohua
2003-11-19 22:47:39 UTC
Created attachment 1497 [details]
all info with acpi=off, pci=noacpi and acpi
please note:
pci = noacpi, pccard in 2 slots works
acpi = off, pccard in 2 slots works
full acpi: pccard in slot1 with irq=11, works
pccard in slot2 with irq=5, report a call trace
The strange is in the 3 conditions, lspci and /proc/interrupt are nearly the
same.
i'm having a heck of a time decoding that attachment, seems to be a tar.gz inside a tar.gz -- but I never did find the dmesg for the acpi case showing the failure. Can you replace the attachment(s) with one in a format I can decode? Also, please include the /proc/interrupts and acpidmp. Also, can you clarify -- the hot plug works, but the irq message comes only after you enable ifconfig the card? Can you give me exact directions so I can try to reproduce the failure? Does it also fail if you up the card when the system is booted with the card already present? thanks, -Len Created attachment 1603 [details]
patch for the error
in acpi_pci_irq_derive, calculating of pin is incorrect. this patch gives a
correct calculation.
Created attachment 1629 [details]
updated patch
Created attachment 1672 [details]
updated patch
Hotplug devices may get IRQs by scaning, see pirq_enable_irq, it's the
counterpart of acpi_pci_irq_enable.
*** Bug 2068 has been marked as a duplicate of this bug. *** Created attachment 2299 [details]
debug patch
since we propose to remove pci_irq_derive, add some debug info.
Just wanted to add my voice to this bug. Was experiencing the same problems on my T30 with a Netgear WG511 using the prism54 drivers. Using this patch (i added a cast (u8 *)&pin to the one line) i was able to get rid of the IRQ issues. Now works with ACPI enabled. Created attachment 2380 [details]
proposed final patch
Please verify that this sub-set of David's patch is necessary and sufficient.
thanks,
-Len
Hi, sorry for the delay. I've tested 2.6.4 and the bug is still in (expected). But, it is also present in 2.6.5-rc2 (it seemed to me it was already commited to the tree). I'll attach stack traces from both kernels. acpidmp from 2.6.4 run. Created attachment 2450 [details]
dmesg output on 2.6.4 kernel with full debug
Created attachment 2451 [details]
acpidmp from 2.6.4 running system
Created attachment 2452 [details]
2.6.5-rc2 dmesg
Hmm, I had a look manually into the pci_irq.h in 2.6.5-rc2 and I see the patch is not yet in mainstream. So, I've applied you patch "proposed final patch" and it has fixed the "nobody cared!" message. Thanks. Created attachment 2453 [details]
2.6.5-rc2 with the proposed patch 2004-03-20 19:24 applied
2.6.5-rc2 with the proposed patch 2004-03-20 19:24 applied. Has solved the
problem.
when this patch was added, it broke other systems. The newer patch in bug 2409 replaced this one. If 2.6.5 or 2.4.26 don't work for you, please re-open bug 2409. This bug doesn't show with 2.4.26 for me. Thanks. |