Bug 11049
| Summary: | Error message: ACPI: Resource is not an IRQ entry | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Kurk (kurk) |
| Component: | Config-Interrupts | Assignee: | 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
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. |