Bug 12976 - acpi=noirq required since 2.6.27 for Arima SDVIB board
Summary: acpi=noirq required since 2.6.27 for Arima SDVIB board
Status: CLOSED DUPLICATE of bug 12270
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Interrupts (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: acpi_config-interrupts
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-30 08:07 UTC by Anders Henke
Modified: 2009-04-01 05:55 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.27
Subsystem:
Regression: No
Bisected commit-id:


Attachments
acpidump of affected box (50.36 KB, text/plain)
2009-03-30 08:07 UTC, Anders Henke
Details
serial console boot log (43.42 KB, text/plain)
2009-03-30 08:09 UTC, Anders Henke
Details
dmidecode of the affected box (12.45 KB, text/plain)
2009-03-30 08:10 UTC, Anders Henke
Details
lspci -vxxx (12.83 KB, text/plain)
2009-03-30 10:06 UTC, Anders Henke
Details
dmesg of affected box (20.74 KB, text/plain)
2009-03-30 10:06 UTC, Anders Henke
Details
debugging patch (736 bytes, patch)
2009-03-30 15:51 UTC, Anders Henke
Details | Diff

Description Anders Henke 2009-03-30 08:07:19 UTC
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.
Comment 1 Anders Henke 2009-03-30 08:09:35 UTC
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".
Comment 2 Anders Henke 2009-03-30 08:10:04 UTC
Created attachment 20733 [details]
dmidecode of the affected box
Comment 3 ykzhao 2009-03-30 09:47:55 UTC
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.
Comment 4 ykzhao 2009-03-30 09:50:00 UTC
Will you please add the boot option of "acpi=noirq" on the broken kernel and attach the output of dmesg?
   Thanks.
Comment 5 Anders Henke 2009-03-30 10:06:09 UTC
Created attachment 20734 [details]
lspci -vxxx
Comment 6 Anders Henke 2009-03-30 10:06:45 UTC
Created attachment 20735 [details]
dmesg of affected box
Comment 7 Anders Henke 2009-03-30 10:08:35 UTC
(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.
Comment 8 Anders Henke 2009-03-30 10:12:26 UTC
(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?
Comment 9 Anders Henke 2009-03-30 15:50:05 UTC
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.
Comment 10 Anders Henke 2009-03-30 15:51:52 UTC
Created attachment 20737 [details]
debugging patch

Just for debugging, not intended for production use ... manually reverting back to pre-d0e184abc5983281ef189db2c759d65d56eb1b80 behaviour.
Comment 11 Zhang Rui 2009-03-31 01:40:10 UTC
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 ***

Note You need to log in before you can comment on or make changes to this bug.