On Wed, Apr 25, 2012 at 4:06 PM, Sedat Dilek <sedat.dilek@xxxxxxxxxxxxxx> wrote:
> On Wed, Apr 25, 2012 at 11:57 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
>> On Wed, Apr 25, 2012 at 3:39 PM, Moore, Robert <robert.moore@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
