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
quoted text >-----Original Message-----
>From: Jan Beulich [mailto:jbeulich@novell.com]
>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@ishiboo.com> 17.07.08 16:32 >>>
>>On Thu, Jul 17, 2008 at 9:58 AM, Jan Beulich <jbeulich@novell.com>
wrote:
quoted text >>>>>> "Andrew Paprocki" <andrew@ishiboo.com> 17.07.08 15:03 >>>
>>>>On Thu, Jul 17, 2008 at 8:28 AM, Andi Kleen <ak@linux.intel.com>
wrote:
quoted text >>>>> 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
quoted text >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
quoted text >inconsistencies).
>
>Jan
--
unsubscribe notice 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/
Messages in current thread:
RE: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348acpi_ ... , Moore, Robert , (Thu Jul 17, 10:20 am)