RE: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348acpi_tb_create_local_fadt+0x147/0x2f4()

[Moore, Robert]

So far, in the number of the cases like this that I've seen, it's the v2
fields that have problems. Perhaps the heuristic should be something
like "if there is an inconsistency between the v1 and v2 fields, fall
back to v1". 

Bob


>-----Original Message-----
>From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx]
>Sent: Thursday, July 17, 2008 8:30 AM
>To: Andrew Paprocki
>Cc: Moore, Robert; Len Brown; Andrew Morton; Andi Kleen; LKML
>Subject: Re: ACPI WARNING: at
>drivers/acpi/tables/tbfadt.c:348acpi_tb_create_local_fadt+0x147/0x2f4()
>
>>>> "Andrew Paprocki" <andrew@xxxxxxxxxxx> 17.07.08 16:32 >>>
>>On Thu, Jul 17, 2008 at 9:58 AM, Jan Beulich <jbeulich@xxxxxxxxxx>
wrote:
>>>>>> "Andrew Paprocki" <andrew@xxxxxxxxxxx> 17.07.08 15:03 >>>
>>>>On Thu, Jul 17, 2008 at 8:28 AM, Andi Kleen <ak@xxxxxxxxxxxxxxx>
wrote:
>>>>> Ok, but we can just get that from a table dump.
>>>>
>>>>Output from acpidump is attached.
>>>
>>> Just as I suspected - the v1 field says 4 bytes, but the v2 field
says 8
>bits.
>>
>>So does the BIOS owner need to fix the table? If you could give me the
>>exact text to pass along to the mobo mfr, I will forward it and I can
>>get them to release a new BIOS rev.
>
>I'm not sure how else to express what I already said above: They simply
>need to get (in ACPI spec terms) the FADT's X_PM1a_EVT_BLK in sync
>with PM1_EVT_LEN (and they should at once make sure other
>X_PM*_BLK and X_GPE?_BLK fields are in sync with their respective
>legacy fields, too - while looking at the dump, it seemed there were
more
>inconsistencies).
>
>Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/