Bug 12976
| Summary: | acpi=noirq required since 2.6.27 for Arima SDVIB board | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Anders Henke (anders.henke) |
| Component: | Config-Interrupts | Assignee: | acpi_config-interrupts |
| Status: | CLOSED DUPLICATE | ||
| Severity: | normal | CC: | lenb, rui.zhang, yakui.zhao |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.27 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
acpidump of affected box
serial console boot log dmidecode of the affected box lspci -vxxx dmesg of affected box debugging patch |
||
Created attachment 20732 [details]
serial console boot log
Serial console's log of booting 2.6.27 plain, 2.6.29 using "pci=routeirq"
(as one of the many debugging attempts) and 2.6.29 using "acpi=noirq".
Created attachment 20733 [details]
dmidecode of the affected box
Will you please attach the output of lspci -vxxx?
From the problem description it seems that the 2.6.26.8 kernel can work well without the option of "acpi=noirq". But the 2.6.27 kernel can't work well unless the boot option of "acpi=noirq" is added. Right?
If so, it seems that this is a regression. Will you please use the git-bisect to identify the commit which causes the regression?
Will you please attach the output of dmesg on the working kernel?
Thanks.
Will you please add the boot option of "acpi=noirq" on the broken kernel and attach the output of dmesg? Thanks. Created attachment 20734 [details]
lspci -vxxx
Created attachment 20735 [details]
dmesg of affected box
(In reply to comment #4) > Will you please add the boot option of "acpi=noirq" on the broken kernel and > attach the output of dmesg? > Thanks. Done. Sidenote: the console log contains booting two different kernels in three configurations, including 2.6.29 with "acpi=noirq" as the very last one. (In reply to comment #3) > Will you please attach the output of lspci -vxxx? Done. > From the problem description it seems that the 2.6.26.8 kernel can work well > without the option of "acpi=noirq". But the 2.6.27 kernel can't work well > unless the boot option of "acpi=noirq" is added. Right? Yes. 2.6.26.8 works without any special options, 2.6.27 (starting at -rc1) can't assign interrupts without the boot option acpi=noirq (or noapic and nosmp, who both do disable the apic). > If so, it seems that this is a regression. Will you please use the > git-bisect to identify the commit which causes the regression? Ouch. This'll take some time :) > Will you please attach the output of dmesg on the working kernel? The currently working kernel ist 2.6.29 with acpi=noirq. Would you like to have the dmesg output of 2.6.26 without special options? Okay, bisecting brought narrowed down to this commit: d0e184abc5983281ef189db2c759d65d56eb1b80 is first bad commit commit d0e184abc5983281ef189db2c759d65d56eb1b80 Author: Bob Moore <robert.moore@intel.com> Date: Tue Jun 10 14:16:47 2008 +0800 ACPICA: Workaround for reversed _PRT entries from BIOS Some BIOSs erroneously reverse the _PRT SourceName and the SourceIndex. Detect and repair this problem. MS ACPI also allows and repairs this problem, thus ACPICA must also. Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> :040000 040000 b72fed723e70aa57b55b0a2611819d633833dc25 3285387e94acb99fe7e50956a35db87e04dda550 M drivers After bisecting, I've manually commented out the suitable section in a clean 2.6.29's drivers/acpi/acpica/rscreate.c (see attached unpatch.diff), applied my .config and am running this kernel without any special boot parameters. Created attachment 20737 [details]
debugging patch
Just for debugging, not intended for production use ... manually reverting back to pre-d0e184abc5983281ef189db2c759d65d56eb1b80 behaviour.
this is a duplicate of bug #12270 and we already have a patch to fix it but need someone to test. so it would be great if you can try the patch at http://bugzilla.kernel.org/show_bug.cgi?id=12270#c35 *** This bug has been marked as a duplicate of bug 12270 *** |
Created attachment 20731 [details] acpidump of affected box One of my boxes is running on a Arima SDVIB board (Dual-Pentium III, built back in 2001) which works flawlessly using 2.6.26.8, but since 2.6.27-rc1, the kernel no longer assigns interrupts for e.g. networking adapter (intel e100) or the raid controller (3w-xxxx) via APCI, so the box completely fails booting and panics, as it can't find its root filesystem. Known-good kernels: 2.6.22 2.6.26 2.6.26.4 2.6.26.8 Known-broken kernels: 2.6.27-rc1 2.6.27-rc3 2.6.27-rc5 2.6.27 2.6.28.4 2.6.29 Workaround: booting the box with acpi=noirq makes the "known broken" kernels to work.