lkml.org 
[lkml]   [2012]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Warning: pnp 00:0b: can't evaluate _CRS: 12311
Date
>                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







>-----Original Message-----
>From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
>owner@vger.kernel.org] On Behalf Of Bjorn Helgaas
>Sent: Wednesday, April 25, 2012 3:49 PM
>To: sedat.dilek@gmail.com
>Cc: Moore, Robert; linux-acpi@vger.kernel.org; Len Brown; linux-
>kernel@vger.kernel.org; Lin, Ming M
>Subject: Re: Warning: pnp 00:0b: can't evaluate _CRS: 12311
>
>On Wed, Apr 25, 2012 at 4:06 PM, Sedat Dilek <sedat.dilek@googlemail.com>
>wrote:
>> On Wed, Apr 25, 2012 at 11:57 PM, Bjorn Helgaas <bhelgaas@google.com>
>wrote:
>>> On Wed, Apr 25, 2012 at 3:39 PM, Moore, Robert <robert.moore@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.
>--
>To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2012-04-26 02:17    [W:0.048 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site