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 -----------------------------------------------------------------
Will you please attach the output of acpidump , lspci -vxxx? Thanks.
Created attachment 16756 [details] Acpidump output
Created attachment 16757 [details] lspci -vxxx output
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.
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
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.
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.
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.
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?
Hi Bjorn, I have patched the kernel and I am going to upload the resulting dmesg in a minute. Thanks for your help.
Created attachment 16793 [details] dmesg output after Bjorn patch
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.
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.
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.
Created attachment 16810 [details] dmesg output after "proposed patch for upstream" by Bjorn
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."
Reopening as requested Thank you
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.
As the patch is already shipped in 2.6.27-rc1, the bug will be closed. Thanks.