Bug 11049

Summary: Error message: ACPI: Resource is not an IRQ entry
Product: ACPI Reporter: Kurk (kurk)
Component: Config-InterruptsAssignee: ykzhao (yakui.zhao)
Status: CLOSED CODE_FIX    
Severity: low CC: acpi-bugzilla, bjorn.helgaas, kurk
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.25 Subsystem:
Regression: --- Bisected commit-id:
Attachments: Acpidump output
lspci -vxxx output
collect _PRS debug info
dmesg output after Bjorn patch
proposed patch for upstream
dmesg output after "proposed patch for upstream" by Bjorn

Description Kurk 2008-07-07 02:36:02 UTC
Latest working kernel version:   unknown
Earliest failing kernel version: unknown. 2.6.25 gives the error
Distribution:   Debian (but vanilla kernel)
Hardware Environment:  IBM xSeries 335
Software Environment:  kernel (at boot)
Problem Description: see below
Steps to reproduce: see below
-------
Detailed report:

Kernel 2.6.25 (but probably many other kernels before this one) compiled for x86, give an error message at boot telling:
ACPI: Resource is not an IRQ entry
on a IBM xSeries 335 machine.
After boot completes, it is possible to see this error and other suspicious strings using dmesg.
Apparently the machine works, so I am unsure of how serious is this bug, that's why I have put Severity=Low.

I am attaching the dmesg | grep -i acpi here, and then lspci -vvv below that one.

Here is the "dmesg | grep -i acpi":
-----------------------------------------------------------------
 BIOS-e820: 000000003fffc180 - 0000000040000000 (ACPI data)
ACPI: RSDP 000FDFC0, 0014 (r0 IBM   )
ACPI: RSDT 3FFFFF80, 0030 (r1 IBM    SERONYXP     1000 IBM  45444F43)
ACPI: FACP 3FFFFF00, 0074 (r1 IBM    SERONYXP     1000 IBM  45444F43)
ACPI: DSDT 3FFFC180, 3BB6 (r1 IBM    SERTURQU     1000 MSFT  100000B)
ACPI: FACS 3FFFFE40, 0040
ACPI: APIC 3FFFFE80, 0076 (r1 IBM    SERONYXP     1000 IBM  45444F43)
ACPI: ASF! 3FFFFDC0, 004B (r16 IBM    SERONYXP        1 IBM  45444F43)
ACPI: PM-Timer IO Port: 0x488
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x06] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x0e] address[0xfec00000] gsi_base[0])
ACPI: IOAPIC (id[0x0d] address[0xfec01000] gsi_base[16])
ACPI: IOAPIC (id[0x0c] address[0xfec02000] gsi_base[32])
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ3 used by override.
Using ACPI (MADT) for SMP configuration information
ACPI: Core revision 20070126
ACPI: bus type pci registered
ACPI: EC: Look up EC in DSDT
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Root Bridge [PCI1] (0000:01)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI1._PRT]
ACPI: PCI Root Bridge [PCI2] (0000:02)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI2._PRT]
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP00] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP01] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP02] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP03] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP04] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP05] (IRQs) *0, disabled.
ACPI: PCI Interrupt Link [LP06] (IRQs *9)
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP07] (IRQs) *0, disabled.
ACPI: PCI Interrupt Link [LP08] (IRQs *10)
ACPI: PCI Interrupt Link [LP09] (IRQs *11)
ACPI: PCI Interrupt Link [LP0A] (IRQs *10)
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP0B] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP0C] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP0D] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP0E] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP0F] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP10] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP11] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP12] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP13] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP14] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP15] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP16] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP17] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP18] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP19] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP1A] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP1B] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP1C] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP1D] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP1E] (IRQs) *0, disabled.
ACPI: Blank IRQ resource
ACPI: Resource is not an IRQ entry
ACPI: PCI Interrupt Link [LP1F] (IRQs) *0, disabled.
ACPI: PCI Interrupt Link [LPUS] (IRQs *11)
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 14 devices
ACPI: ACPI bus type pnp unregistered
PnPBIOS: Disabled by ACPI PNP
PCI: Using ACPI for IRQ routing
ACPI: ACPI0007:00 is registered as cooling_device0
ACPI: ACPI0007:01 is registered as cooling_device1
ACPI: PCI Interrupt Link [LPUS] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:0f.2[A] -> Link [LPUS] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt 0000:01:01.0[A] -> GSI 22 (level, low) -> IRQ 22
ACPI: PCI Interrupt 0000:02:01.0[A] -> GSI 24 (level, low) -> IRQ 24
ACPI: PCI Interrupt 0000:02:02.0[A] -> GSI 25 (level, low) -> IRQ 25
ACPI: Power Button (FF) [PWRF]
-----------------------------------------------------------------


Here is the lspci -vvv:
-----------------------------------------------------------------
00:00.0 Host bridge: Broadcom CMIC-WS Host Bridge (GC-LE chipset) (rev 13)
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Kernel modules: sworks-agp

00:00.1 Host bridge: Broadcom CMIC-WS Host Bridge (GC-LE chipset)
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Kernel modules: sworks-agp

00:00.2 Host bridge: Broadcom CMIC-LE
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Kernel modules: sworks-agp

00:01.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) (prog-if 00 [VGA controller])
	Subsystem: IBM Unknown device 0240
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (2000ns min), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: I/O ports at 2200 [size=256]
	Region 2: Memory at febff000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [5c] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0f.0 Host bridge: Broadcom CSB5 South Bridge (rev 93)
	Subsystem: Broadcom CSB5 South Bridge
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 64
	Kernel driver in use: piix4_smbus
	Kernel modules: sworks-agp, i2c-piix4

00:0f.1 IDE interface: Broadcom CSB5 IDE Controller (rev 93) (prog-if 8a [Master SecP PriP])
	Subsystem: Broadcom CSB5 IDE Controller
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64, Cache Line Size: 32 bytes
	Region 0: I/O ports at 01f0 [size=8]
	Region 1: I/O ports at 03f4 [size=1]
	Region 2: I/O ports at 0170 [size=8]
	Region 3: I/O ports at 0374 [size=1]
	Region 4: I/O ports at 0700 [size=16]
	Kernel driver in use: Serverworks_IDE
	Kernel modules: serverworks

00:0f.2 USB Controller: Broadcom OSB4/CSB5 OHCI USB Controller (rev 05) (prog-if 10 [OHCI])
	Subsystem: Broadcom OSB4/CSB5 OHCI USB Controller
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (20000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at febfe000 (32-bit, non-prefetchable) [size=4K]
	Kernel driver in use: ohci_hcd
	Kernel modules: ohci-hcd

00:0f.3 ISA bridge: Broadcom CSB5 LPC bridge
	Subsystem: Broadcom Unknown device 0230
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0

00:11.0 Host bridge: Broadcom CIOB-X2 PCI-X I/O Bridge (rev 03)
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Capabilities: [60] PCI-X non-bridge device
		Command: DPERE- ERO- RBC=512 OST=8
		Status: Dev=00:00.0 64bit+ 133MHz+ SCD+ USC+ DC=bridge DMMRBC=512 DMOST=8 DMCRS=8 RSCEM- 266MHz- 533MHz-
	Kernel modules: sworks-agp

00:11.2 Host bridge: Broadcom CIOB-X2 PCI-X I/O Bridge (rev 03)
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Capabilities: [60] PCI-X non-bridge device
		Command: DPERE- ERO- RBC=512 OST=8
		Status: Dev=00:00.0 64bit+ 133MHz+ SCD- USC- DC=bridge DMMRBC=512 DMOST=8 DMCRS=8 RSCEM- 266MHz- 533MHz-
	Kernel modules: sworks-agp

01:01.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07)
	Subsystem: IBM Unknown device 026d
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 72 (4250ns min, 4500ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 22
	Region 0: I/O ports at 2300 [size=256]
	Region 1: Memory at fbff0000 (64-bit, non-prefetchable) [size=64K]
	Region 3: Memory at fbfe0000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [68] PCI-X non-bridge device
		Command: DPERE- ERO- RBC=512 OST=1
		Status: Dev=01:01.0 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=2048 DMOST=8 DMCRS=16 RSCEM- 266MHz- 533MHz-
	Kernel driver in use: mptspi
	Kernel modules: mptspi

02:01.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02)
	Subsystem: IBM Unknown device 026f
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (16000ns min), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 24
	Region 0: Memory at f9ff0000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [40] PCI-X non-bridge device
		Command: DPERE- ERO- RBC=2048 OST=1
		Status: Dev=02:01.1 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=2048 DMOST=1 DMCRS=16 RSCEM- 266MHz- 533MHz-
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [50] Vital Product Data <?>
	Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 Enable-
		Address: 0000000100000000  Data: e6d7
	Kernel driver in use: tg3
	Kernel modules: tg3

02:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02)
	Subsystem: IBM Unknown device 026f
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (16000ns min), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 25
	Region 0: Memory at f9fe0000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [40] PCI-X non-bridge device
		Command: DPERE- ERO- RBC=2048 OST=1
		Status: Dev=02:02.1 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=2048 DMOST=1 DMCRS=16 RSCEM- 266MHz- 533MHz-
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [50] Vital Product Data <?>
	Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 Enable-
		Address: efcd4ed75dbfbfbc  Data: bfe3
	Kernel driver in use: tg3
	Kernel modules: tg3
-----------------------------------------------------------------
Comment 1 ykzhao 2008-07-07 02:48:38 UTC
Will you please attach the output of acpidump , lspci -vxxx?
Thanks.
Comment 2 Kurk 2008-07-07 03:10:19 UTC
Created attachment 16756 [details]
Acpidump output
Comment 3 Kurk 2008-07-07 03:11:03 UTC
Created attachment 16757 [details]
lspci -vxxx output
Comment 4 ykzhao 2008-07-07 23:24:33 UTC
Hi, Kurb
   Thanks for the info. 
   From the attached info it seems that the warning message is caused by the broken BIOS. The _CRS/_PRS object of the LINK device(LP01/02...) returns the incorrect IRQ list. So OS complains the following warning message.
    >ACPI: Resource is not an IRQ entry
    >ACPI: PCI Interrupt Link [LP00] (IRQs) *0, disabled.
    >ACPI: Blank IRQ resource
    >ACPI: Resource is not an IRQ entry
    >ACPI: PCI Interrupt Link [LP01] (IRQs) *0, disabled.
   As the laptop works in IOAPIC mode, the LINK device won't be used. The above warning message is harmless although confusing.
    
   Can you confirm whether the system can work well besides the above warning message?
   thanks.
Comment 5 Kurk 2008-07-08 00:59:47 UTC
It is not a laptop, it is a 1U rack server: IBM xSeries 335, dual Pentium IV Xeon 2.40 GHz.
Yes the system appears to work well; if you are thinking about a specific test to run please tell.
Thank you
Comment 6 Bjorn Helgaas 2008-07-09 13:21:38 UTC
Created attachment 16776 [details]
collect _PRS debug info

Kurk, can you try this patch and attach the dmesg log, please?  It should apply to 2.6.25 or to a current kernel, so just use whatever's most convenient for you.

Zhao, can you elaborate on what is broken in the BIOS?  We get the warnings for LP00-LP05, LP07, and LP0B-LP1F, but not for LP06, LP08-LP0A, and LPUS.  The AML for all those _CRS methods is essentially the same and looks like this (for LP00):

            Method (_CRS, 0, NotSerialized)
            {
                Store (0x83, IOPT)
                Name (RRET, ResourceTemplate ()
                {
                    IRQ (Level, ActiveLow, Shared)
                        {0}
                })
                CreateWordField (RRET, 0x01, RINT)
                Store (PX00, Local0)
                If (LEqual (Local0, 0x00))
                {
                    Store (0x00, RINT)
                }
                Else
                {
                    ShiftLeft (One, Local0, RINT)
                }

                Return (RRET)
            }

I don't see what's broken.

You mention that in IOAPIC mode, the link devices won't be used.  Is that actually a requirement in the spec somewhere?

If it's true that they're never used, I wonder if we can avoid evaluating their _PRS methods completely.
Comment 7 ykzhao 2008-07-10 00:24:12 UTC
Thanks for caring this problem. 
From the AML it seems that all the LINK devices have the similar _PRS/_CRS object. The _CRS object is listed in the following:
            Method (_CRS, 0, NotSerialized)
            {
                Store (0x83, IOPT)
                Name (RRET, ResourceTemplate ()
                {
                    IRQ (Level, ActiveLow, Shared)
                        {0}
                })
                CreateWordField (RRET, 0x01, RINT)
                Store (PX00, Local0)
                If (LEqual (Local0, 0x00))
                {
                    Store (0x00, RINT)
                }
                Else
                {
                    ShiftLeft (One, Local0, RINT)
                }

                Return (RRET)
            }
     
    The _CRS/_PRS object should return the buffer object(PRET). Linux ACPICA will parse the corresponding IRQ list from the buffer object. For example: 
    Name (RRET, ResourceTemplate ()
                {
                    IRQ (Level, ActiveLow, Shared)
                        {0}
                })
     The IRQ list should be 0 and interrupt count should be 1. In such case the RINT is 1.(Bit 0 means  IRQ0, Bit 1 means IRQ1...)
    But if the PX00 is zero in the above AML code, the 0x00 will be stored into the RINT. In such case the Linux ACPICA can't get the correct IRQ list from the buffer object and the interrupt count is zero.  So OS will complain the following warning message.
  > ACPI: Blank IRQ resource
  > ACPI: Resource is not an IRQ entry
  > ACPI: PCI Interrupt Link [LP1F] (IRQs) *0, disabled

  In most cases when the system works in IO_APIC mode, the Link devices won't be used again. But for some machines the link devices are still used when it works in IO_APIC mode. So we can't avoid evaluating the _PRS object completely.
   Thanks.
Comment 8 ykzhao 2008-07-10 00:51:07 UTC
Hi, Kurk
   The warning message is related with the BIOS. And os complains that there is an  error about the _CRS/_PRS object of some Link devices. 
   As when the system works in IO_APIC mode, most link devices aren't used.(LPUS is an exception) and the error won't break anyting. So the bug will be rejected.
   Thanks.
Comment 9 Bjorn Helgaas 2008-07-10 09:42:06 UTC
Hold on.  We can't just reject this.  Either there's a BIOS bug, and we should make Linux work around it, or there's no BIOS bug, and we should make Linux quit complaining.

If PX00==0 means the link can only be configured for IRQ0, I agree this looks like a BIOS bug.  But I think it's unlikely the BIOS is trying to tell us that IRQ0 is the only possible configuration for all these links.  That just doesn't seem sensible.

I think it's more likely that PX00=0 means the link can't be configured at all.  I don't see anything in the spec that *requires* a bit to be set in the small IRQ mask.  In fact, the comment in acpi_pci_link_check_current() says _CRS may return a mask with no bits set.  In this case, we're looking at a similar situation with _PRS.  I think the ASL code looks fine, and Linux is just deficient because it doesn't expect the case where a _PRS IRQ descriptor specifies no interrupts at all.

I'm also curious about the "Resource is not an IRQ entry" message.  That means we found a descriptor type we didn't recognize, so we need to understand that.  If Kurk could try the patch I attached, we should learn something about this.

My thought about avoiding _PRS evaluation was more along the lines of deferring evaluation until we need to use the link objects.  Why can't we just completely ignore the link (or possibly just disable it) until we discover and enable a PCI device that is connected to the link?
Comment 10 Kurk 2008-07-10 09:49:54 UTC
Hi Bjorn, I have patched the kernel and I am going to upload the resulting dmesg in a minute. Thanks for your help.
Comment 11 Kurk 2008-07-10 09:51:06 UTC
Created attachment 16793 [details]
dmesg output after Bjorn patch
Comment 12 Bjorn Helgaas 2008-07-10 14:45:50 UTC
Created attachment 16794 [details]
proposed patch for upstream

Thanks very much, Kurk.

Here's the output for LP00:

  _PRS AML buffer:
    23 00 00 18 79 00 
  ACPI: No IRQs in resource
  ACPI: Resource type 0x7 is not an IRQ entry

The "23 00 00 18" part is a small IRQ resource, three bytes long, no bits set in the IRQ mask ("00 00"), and level-triggered, active low, shareable ("18").

The "79 00" is an End Tag (type 0x7).  It is really superfluous since there is Start Dependent Function tag, and there are no resources after it, but it is harmless.

The _CRS data is identical, and we don't complain about that.  I think we should use something like the attached patch to make Linux stop complaining about this.  If you could test this before I post it upstream, that would be great.

As far as deferring _PRS evaluation until we actually use the link, I still think that's an interesting idea, but it looks like we actually *do* use the _PRS data before enabling a connected PCI device.  acpi_irq_penalty_init() uses _PRS to do some IRQ balancing.  So there are definitely issues to consider here.
Comment 13 ykzhao 2008-07-10 20:57:48 UTC
Hi, Bjorn
   Thanks for your work and understand what you said.
   When the _PRS of LP00 device returns the following buffer object:
   Here's the output for LP00:
   >    23 00 00 18 79 00 
   The "23 00 00 18" is a small IRQ resource. As OS can't get the Interrupt IRQ list from it. So OS will complain that there is No IRQs in resource.
   
   I disagree with what you said in comment #12. It is aggressive. If the _PRS evaluation is deferred until the Link device is used, does it mean that it is unnecessary to evaluate the _PRS/_CRS object in loading pci_link device driver? If so, we will add more flag for the Link device to indicate whether the _PRS object is already evaluated. 
  
   Of course I agree with the patch in comment #12. Although it can't resolve the problem caused by the bios, OS won't complain the warning message again.
   
Comment 14 Kurk 2008-07-14 05:46:56 UTC
Hi Bjorn,
I have removed your previous patch ("collect _PRS debug info") and installed your latest one ("proposed patch for upstream"). I am going to upload the new dmesg in a minute.
Comment 15 Kurk 2008-07-14 05:48:51 UTC
Created attachment 16810 [details]
dmesg output after "proposed patch for upstream" by Bjorn
Comment 16 Bjorn Helgaas 2008-09-12 12:57:17 UTC
Kurk, the patch I proposed is now upstream:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4a5e3638b11978262ab76bbb2062e57fefaaedba

If you want to re-open this bug, we can close it properly as "fixed" instead of "rejected."
Comment 17 Kurk 2008-09-16 02:20:59 UTC
Reopening as requested
Thank you
Comment 18 Bjorn Helgaas 2008-09-16 23:11:35 UTC
This is fixed by commit 4a5e3638b11978262ab76bbb2062e57fefaaedba,
which appeared in 2.6.27-rc1.

Kurk, can you close this?  Bugzilla only lets the reporter or assignee close it, so I can't do it.
Comment 19 ykzhao 2008-09-17 00:04:56 UTC
As the patch is already shipped in 2.6.27-rc1, the bug will be closed.
Thanks.