Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Warning: pnp 00:0b: can't evaluate _CRS: 12311

2,333 views
Skip to first unread message

Sedat Dilek

unread,
Apr 23, 2012, 5:50:03 AM4/23/12
to
[ Please CC me I am not subscribed to this ML ]

Hi,

with a self-compiled linux-3.4-rc4 I am seeing this bugs/failures/warnings:

[ 0.241572] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored

[ 0.279385] pci0000:00: ACPI _OSC request failed (AE_ERROR),
returned control mask: 0x1d

[ 0.293699] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.294032] ACPI Error: Invalid/unsupported resource descriptor:
Type 0x00 (20120320/utresrc-650)
[ 0.294037] pnp 00:0b: can't evaluate _CRS: 12311

The same outputs I have seen also with an unsupported drm-intel-next
kernel from Ubuntu/PPA archives [1].

What does ist mean? Is it harmless? Buggy firmware/bios?

Do you need more background infos (dmesg, kernel-config, etc.)?

Regards,
- Sedat -

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Sedat Dilek

unread,
Apr 23, 2012, 8:10:01 AM4/23/12
to
On Mon, Apr 23, 2012 at 11:48 AM, Sedat Dilek
<sedat...@googlemail.com> wrote:
> [ Please CC me I am not subscribed to this ML ]
>
> Hi,
>
> with a self-compiled linux-3.4-rc4 I am seeing this bugs/failures/warnings:
>
> [    0.241572] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
>
> [    0.279385]  pci0000:00: ACPI _OSC request failed (AE_ERROR),
> returned control mask: 0x1d
>
> [    0.293699] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    0.294032] ACPI Error: Invalid/unsupported resource descriptor:
> Type 0x00 (20120320/utresrc-650)
> [    0.294037] pnp 00:0b: can't evaluate _CRS: 12311
>
> The same outputs I have seen also with an unsupported drm-intel-next
> kernel from Ubuntu/PPA archives [1].
>
> What does ist mean? Is it harmless? Buggy firmware/bios?
>
> Do you need more background infos (dmesg, kernel-config, etc.)?
>
> Regards,
> - Sedat -
>
> [1] http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/

I have upgraded this Samsung series-5 notebook from BIOS version 05XK
to 06XK, but the pnp/_CRS warning still remains.

- Sedat -

Bjorn Helgaas

unread,
Apr 23, 2012, 6:10:02 PM4/23/12
to
On Mon, Apr 23, 2012 at 6:03 AM, Sedat Dilek <sedat...@googlemail.com> wrote:
> On Mon, Apr 23, 2012 at 11:48 AM, Sedat Dilek
> <sedat...@googlemail.com> wrote:
>> [ Please CC me I am not subscribed to this ML ]
>>
>> Hi,
>>
>> with a self-compiled linux-3.4-rc4 I am seeing this bugs/failures/warnings:
>>
>> [    0.241572] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
>>
>> [    0.279385]  pci0000:00: ACPI _OSC request failed (AE_ERROR),
>> returned control mask: 0x1d
>>
>> [    0.293699] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
>> [    0.294032] ACPI Error: Invalid/unsupported resource descriptor:
>> Type 0x00 (20120320/utresrc-650)
>> [    0.294037] pnp 00:0b: can't evaluate _CRS: 12311
>>
>> The same outputs I have seen also with an unsupported drm-intel-next
>> kernel from Ubuntu/PPA archives [1].
>>
>> What does ist mean? Is it harmless? Buggy firmware/bios?
>>
>> Do you need more background infos (dmesg, kernel-config, etc.)?
>>
>> Regards,
>> - Sedat -
>>
>> [1] http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/
>
> I have upgraded this Samsung series-5 notebook from BIOS version 05XK
> to 06XK, but the pnp/_CRS warning still remains.

Resource type 0 is "reserved" per the ACPI spec, so this is likely a
BIOS defect. However, we might be able to handle it better than we
currently do.

I would expect all versions of Linux would report this error -- can
you confirm that or identify a version that didn't complain? Also,
can you collect an acpidump (see
http://www.lesswatts.org/projects/acpi/utilities.php)?

In acpi_ut_validate_resource(), we return AE_AML_INVALID_RESOURCE_TYPE
(0x3017 == 12311), which explains the messages you see. The comments
in acpi_ut_walk_aml_resources() suggest that we can't continue because
the length may be bogus if the type is invalid. But I suspect that if
we just treat it as a zero-length descriptor and ignore it, things
will probably work, and that's likely what Windows does.

Bjorn

Moore, Robert

unread,
Apr 25, 2012, 4:40:02 PM4/25/12
to
> >>> [ 0.294037] pnp 00:0b: can't evaluate _CRS: 12311

It sure would be nice if this error message would include the full pathname to the _CRS method. As it stands, it is rather difficult to determine just what caused this.


> -----Original Message-----
> From: Sedat Dilek [mailto:sedat...@googlemail.com]
> Sent: Monday, April 23, 2012 3:27 PM
> To: Bjorn Helgaas
> Cc: linux...@vger.kernel.org; Len Brown; linux-
> ker...@vger.kernel.org; Moore, Robert; Lin, Ming M
> Subject: Re: Warning: pnp 00:0b: can't evaluate _CRS: 12311
>
> On Tue, Apr 24, 2012 at 12:04 AM, Bjorn Helgaas <bhel...@google.com>
> [ Removed Adam Belay <abe...@mit.edu> (email-address does not exist
> anymore) ]
>
> Yeah, I asked today on #ubuntu-kernel and people there were very
> helpful and gave some good explanations (AE_AML_INVALID_RESOURCE_TYPE
> etc.).
>
> The acpidump.log I pastebin-ed today, so here it is :-).
>
> The kernel shipped with Ubuntu/precise does not show the pnp/_CSR
> issue, this is linux-image-3.2.0-23-generic (3.2.0-23.36).
>
> Hope this helps.
>
> - Sedat -

Bjorn Helgaas

unread,
Apr 25, 2012, 5:00:03 PM4/25/12
to
On Wed, Apr 25, 2012 at 2:36 PM, Moore, Robert <robert...@intel.com> wrote:
>> >>> [    0.294037] pnp 00:0b: can't evaluate _CRS: 12311
>
> It sure would be nice if this error message would include the full pathname to the _CRS method. As it stands, it is rather difficult to determine just what caused this.

Agreed.

I extracted and disassembled the acpidump. There were five
occurrences of PNP0C02:

DSDT.dsl \_SB.PCI0.LPCB.LDRC (has a constant _CRS)
DSDT.dsl \_SB.PCI0.LPCB.CWDT (has _HID INT3F0D and _CID PNP0C02, so
doesn't match message)
DSDT.dsl \_SB.PCI0.PDRC
SSDT1.dsl \_SB.PTID (has no _CRS and has _HID INT340E and _CID
PNP0C02, so doesn't match message)
SSDT4.dsl \_SB.IFFS (has no _CRS)

So I think PDRC must be the one causing the trouble. Its _CRS runs
some AML, but I'm not AML-savvy enough to figure it out:

Scope (_SB.PCI0)
{
Device (PDRC)
{
Name (_HID, EisaId ("PNP0C02"))
Name (_UID, One)
Name (BUF0, ResourceTemplate ()
{
Memory32Fixed (ReadWrite,
0x00000000, // Address Base
0x00004000, // Address Length
)
Memory32Fixed (ReadWrite,
0x00000000, // Address Base
0x00008000, // Address Length
)
Memory32Fixed (ReadWrite,
0x00000000, // Address Base
0x00001000, // Address Length
)
Memory32Fixed (ReadWrite,
0x00000000, // Address Base
0x00001000, // Address Length
)
Memory32Fixed (ReadWrite,
0x00000000, // Address Base
0x00000000, // Address Length
)
Memory32Fixed (ReadWrite,
0xFED20000, // Address Base
0x00020000, // Address Length
)
Memory32Fixed (ReadOnly,
0xFED90000, // Address Base
0x00004000, // Address Length
)
Memory32Fixed (ReadWrite,
0xFED45000, // Address Base
0x0004B000, // Address Length
)
Memory32Fixed (ReadOnly,
0xFF000000, // Address Base
0x01000000, // Address Length
)
Memory32Fixed (ReadOnly,
0xFEE00000, // Address Base
0x00100000, // Address Length
)
Memory32Fixed (ReadWrite,
0x00000000, // Address Base
0x00001000, // Address Length
)
})
Method (_CRS, 0, Serialized)
{
CreateDWordField (BUF0, 0x04, RBR0)
ShiftLeft (^^LPCB.RCBA, 0x0E, RBR0)
CreateDWordField (BUF0, 0x7C, TBR0)
Store (TBAB, TBR0)
CreateDWordField (BUF0, 0x80, TBLN)
If (LEqual (TBAB, Zero))
{
Store (Zero, TBLN)
}

CreateDWordField (BUF0, 0x10, MBR0)
ShiftLeft (MHBR, 0x0F, MBR0)
CreateDWordField (BUF0, 0x1C, DBR0)
ShiftLeft (DIBR, 0x0C, DBR0)
CreateDWordField (BUF0, 0x28, EBR0)
ShiftLeft (EPBR, 0x0C, EBR0)
CreateDWordField (BUF0, 0x34, XBR0)
ShiftLeft (PXBR, 0x1A, XBR0)
CreateDWordField (BUF0, 0x38, XSZ0)
ShiftRight (0x10000000, PXSZ, XSZ0)
Return (BUF0)

Moore, Robert

unread,
Apr 25, 2012, 5:50:01 PM4/25/12
to
This disassembly might make more sense. From the looks of the ASL, several of the address base and length fields are being updated dynamically. I don't see anything that would corrupt a resource descriptor, however.


Are we certain that the ACPI Error and pnp messages are directly related to the PNP0C02 device ID?

[ 0.293699] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.294032] ACPI Error: Invalid/unsupported resource descriptor: Type 0x00 (20120320/utresrc-650)
[ 0.294037] pnp 00:0b: can't evaluate _CRS: 12311


Also, I was able to execute all of the _CRS methods in the DSDT here with no errors, except for the last one, under the MEM2 device. IGDS returned zero, so the method did not return a valid resource descriptor, just nothing:

Device: \_SB_.MEM2
Evaluating _CRS
ACPI Warning: For \_SB_.MEM2._CRS: Missing expected return value (20120420/nspredef-283)
ACPI Error: No object was returned from [\_SB_.MEM2._CRS] (Node 004B62A8), AE_NOT_EXIST (20120420/uteval-198)
AcpiWalkResources failed: AE_NOT_EXIST

Device (^^MEM2)
{
Name (_HID, EisaId ("PNP0C01"))
Name (_UID, 0x02)
Name (CRS, ResourceTemplate ()
{
Memory32Fixed (ReadWrite,
0x20000000, // Address Base
0x00200000, // Address Length
)
Memory32Fixed (ReadWrite,
0x40000000, // Address Base
0x00200000, // Address Length
)
})
Method (_CRS, 0, NotSerialized)
{
If (IGDS)
{
Return (CRS)
}
}



/*
* Intel ACPI Component Architecture
* AML Disassembler version 20120420-32 [Apr 20 2012]
* Copyright (c) 2000 - 2012 Intel Corporation
*
* Disassembly of dsdt.dat, Wed Apr 25 11:49:16 2012
*/

Name (BUF0, ResourceTemplate ()
{
Memory32Fixed (ReadWrite,
0x00000000, // Address Base
0x00004000, // Address Length
_Y10)
Memory32Fixed (ReadWrite,
0x00000000, // Address Base
0x00008000, // Address Length
_Y12)
Memory32Fixed (ReadWrite,
0x00000000, // Address Base
0x00001000, // Address Length
_Y13)
Memory32Fixed (ReadWrite,
0x00000000, // Address Base
0x00001000, // Address Length
_Y14)
Memory32Fixed (ReadWrite,
0x00000000, // Address Base
0x00000000, // Address Length
_Y15)
Memory32Fixed (ReadWrite,
0xFED20000, // Address Base
0x00020000, // Address Length
)
Memory32Fixed (ReadOnly,
0xFED90000, // Address Base
0x00004000, // Address Length
)
Memory32Fixed (ReadWrite,
0xFED45000, // Address Base
0x0004B000, // Address Length
)
Memory32Fixed (ReadOnly,
0xFF000000, // Address Base
0x01000000, // Address Length
)
Memory32Fixed (ReadOnly,
0xFEE00000, // Address Base
0x00100000, // Address Length
)
Memory32Fixed (ReadWrite,
0x00000000, // Address Base
0x00001000, // Address Length
_Y11)
})
Method (_CRS, 0, Serialized)
{
CreateDWordField (BUF0, \_SB.PCI0.PDRC._Y10._BAS, RBR0)
ShiftLeft (^^LPCB.RCBA, 0x0E, RBR0)
CreateDWordField (BUF0, \_SB.PCI0.PDRC._Y11._BAS, TBR0)
Store (TBAB, TBR0)
CreateDWordField (BUF0, \_SB.PCI0.PDRC._Y11._LEN, TBLN)
If (LEqual (TBAB, Zero))
{
Store (Zero, TBLN)
}

CreateDWordField (BUF0, \_SB.PCI0.PDRC._Y12._BAS, MBR0)
ShiftLeft (MHBR, 0x0F, MBR0)
CreateDWordField (BUF0, \_SB.PCI0.PDRC._Y13._BAS, DBR0)
ShiftLeft (DIBR, 0x0C, DBR0)
CreateDWordField (BUF0, \_SB.PCI0.PDRC._Y14._BAS, EBR0)
ShiftLeft (EPBR, 0x0C, EBR0)
CreateDWordField (BUF0, \_SB.PCI0.PDRC._Y15._BAS, XBR0)
ShiftLeft (PXBR, 0x1A, XBR0)
CreateDWordField (BUF0, \_SB.PCI0.PDRC._Y15._LEN, XSZ0)

Bjorn Helgaas

unread,
Apr 25, 2012, 6:00:01 PM4/25/12
to
On Wed, Apr 25, 2012 at 3:39 PM, Moore, Robert <robert...@intel.com> wrote:
> This disassembly might make more sense. From the looks of the ASL, several of the address base and length fields are being updated dynamically.  I don't see anything that would corrupt a resource descriptor, however.
>
>
> Are we certain that the ACPI Error and pnp messages are directly related to the PNP0C02 device ID?
>
> [    0.293699] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    0.294032] ACPI Error: Invalid/unsupported resource descriptor: Type 0x00 (20120320/utresrc-650)
> [    0.294037] pnp 00:0b: can't evaluate _CRS: 12311

Oh, I'm sorry, I just wasted your time. I didn't notice the 0a/0b
mismatch. You're right, the _CRS error is on 00:0b, and we don't know
what the path is or the PNP ID for 00:0b.

Sedat, can you run "grep . /sys/bus/pnp/devices/*/id" please? That
will at least show us the PNP ID of device 00:0b.

Bjorn

Sedat Dilek

unread,
Apr 25, 2012, 6:10:02 PM4/25/12
to
On Wed, Apr 25, 2012 at 11:57 PM, Bjorn Helgaas <bhel...@google.com> wrote:
> On Wed, Apr 25, 2012 at 3:39 PM, Moore, Robert <robert...@intel.com> wrote:
>> This disassembly might make more sense. From the looks of the ASL, several of the address base and length fields are being updated dynamically.  I don't see anything that would corrupt a resource descriptor, however.
>>
>>
>> Are we certain that the ACPI Error and pnp messages are directly related to the PNP0C02 device ID?
>>
>> [    0.293699] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
>> [    0.294032] ACPI Error: Invalid/unsupported resource descriptor: Type 0x00 (20120320/utresrc-650)
>> [    0.294037] pnp 00:0b: can't evaluate _CRS: 12311
>
> Oh, I'm sorry, I just wasted your time.  I didn't notice the 0a/0b
> mismatch.  You're right, the _CRS error is on 00:0b, and we don't know
> what the path is or the PNP ID for 00:0b.
>
> Sedat, can you run "grep . /sys/bus/pnp/devices/*/id" please?  That
> will at least show us the PNP ID of device 00:0b.
>
> Bjorn

Here we go:

$ sudo grep . /sys/bus/pnp/devices/*/id
/sys/bus/pnp/devices/00:00/id:PNP0a08
/sys/bus/pnp/devices/00:00/id:PNP0a03
/sys/bus/pnp/devices/00:01/id:PNP0200
/sys/bus/pnp/devices/00:02/id:INT0800
/sys/bus/pnp/devices/00:03/id:PNP0103
/sys/bus/pnp/devices/00:04/id:PNP0c04
/sys/bus/pnp/devices/00:05/id:PNP0c02
/sys/bus/pnp/devices/00:06/id:PNP0b00
/sys/bus/pnp/devices/00:07/id:INT3f0d
/sys/bus/pnp/devices/00:07/id:PNP0c02
/sys/bus/pnp/devices/00:08/id:PNP0303
/sys/bus/pnp/devices/00:09/id:ETD0b00
/sys/bus/pnp/devices/00:09/id:SYN0002
/sys/bus/pnp/devices/00:09/id:PNP0f13
/sys/bus/pnp/devices/00:0a/id:PNP0c02
/sys/bus/pnp/devices/00:0b/id:PNP0c01

- Sedat -

Bjorn Helgaas

unread,
Apr 25, 2012, 6:50:02 PM4/25/12
to
On Wed, Apr 25, 2012 at 4:06 PM, Sedat Dilek <sedat...@googlemail.com> wrote:
> On Wed, Apr 25, 2012 at 11:57 PM, Bjorn Helgaas <bhel...@google.com> wrote:
>> On Wed, Apr 25, 2012 at 3:39 PM, Moore, Robert <robert...@intel.com> wrote:
>>> This disassembly might make more sense. From the looks of the ASL, several of the address base and length fields are being updated dynamically.  I don't see anything that would corrupt a resource descriptor, however.
>>>
>>>
>>> Are we certain that the ACPI Error and pnp messages are directly related to the PNP0C02 device ID?
>>>
>>> [    0.293699] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
>>> [    0.294032] ACPI Error: Invalid/unsupported resource descriptor: Type 0x00 (20120320/utresrc-650)
>>> [    0.294037] pnp 00:0b: can't evaluate _CRS: 12311
>>
>> Oh, I'm sorry, I just wasted your time.  I didn't notice the 0a/0b
>> mismatch.  You're right, the _CRS error is on 00:0b, and we don't know
>> what the path is or the PNP ID for 00:0b.
>>
>> Sedat, can you run "grep . /sys/bus/pnp/devices/*/id" please?  That
>> will at least show us the PNP ID of device 00:0b.
>>
>> Bjorn
>
> Here we go:
> ...
> /sys/bus/pnp/devices/00:0b/id:PNP0c01

There's only one PNP0C01 device:

Device (^^MEM2)
{
Name (_HID, EisaId ("PNP0C01"))
Name (_UID, 0x02)
Name (CRS, ResourceTemplate ()
{
Memory32Fixed (ReadWrite,
0x20000000, // Address Base
0x00200000, // Address Length
)
Memory32Fixed (ReadWrite,
0x40000000, // Address Base
0x00200000, // Address Length
)
})
Method (_CRS, 0, NotSerialized)
{
If (IGDS)
{
Return (CRS)
}
}
}

I don't know whether this is legal or not. If "(!IGDS)", _CRS
apparently don't return anything at all, and I don't know what happens
then.

Moore, Robert

unread,
Apr 25, 2012, 8:20:01 PM4/25/12
to
> Method (_CRS, 0, NotSerialized)
> {
> If (IGDS)
> {
> Return (CRS)
> }
> }
> }
>
>I don't know whether this is legal or not. If "(!IGDS)", _CRS
>apparently don't return anything at all, and I don't know what happens
>then.


Yes, it is illegal to return nothing from _CRS.

Newer versions of ACPICA (and iASL) will squawk at this, but we currently do not attempt to actually perform a runtime "repair".

The driver is probably getting an Integer object of value zero, which might explain the behavior seen.

Bob
>To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
0 new messages