lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 17 Jul 2008 10:20:07 -0700
From:	"Moore, Robert" <robert.moore@...el.com>
To:	"Jan Beulich" <jbeulich@...ell.com>,
	"Andrew Paprocki" <andrew@...iboo.com>
Cc:	"Len Brown" <lenb@...nel.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Andi Kleen" <ak@...ux.intel.com>,
	"LKML" <linux-kernel@...r.kernel.org>
Subject: RE: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348acpi_tb_create_local_fadt+0x147/0x2f4()

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@...ell.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@...iboo.com> 17.07.08 16:32 >>>
>>On Thu, Jul 17, 2008 at 9:58 AM, Jan Beulich <jbeulich@...ell.com>
wrote:
>>>>>> "Andrew Paprocki" <andrew@...iboo.com> 17.07.08 15:03 >>>
>>>>On Thu, Jul 17, 2008 at 8:28 AM, Andi Kleen <ak@...ux.intel.com>
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ