linux-kernel - Re: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348 acpi_tb_create_local

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 11:06:13 +0200
From:	Andi Kleen <ak@...ux.intel.com>
To:	Jan Beulich <jbeulich@...ell.com>
CC:	Andrew Paprocki <andrew@...iboo.com>, robert.moore@...el.com,
	Len Brown <lenb@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: ACPI WARNING: at drivers/acpi/tables/tbfadt.c:348	acpi_tb_create_local_fadt+0x147/0x2f4()

Jan Beulich wrote:

> So it's a firmware bug in the system you saw this on. The specification
> is clear about the width being at least 16 bits, and the warning was added
> to indicate the problem you now got: Dividing 8 by 16 yields zero for
> pm1_register_length, which results in acpi_gbl_xpm1a_enable aliasing
> the address of the respective status register. That won't work, hence
> the warning.

When there are systems around where this register is 8 bits then we have 
to handle it. Real systems beat the specification.

The question is just if the hardware is really 8 bits or if the table
is not just wrong. What does lspci say?

>> Also, I noticed that the patch changed the definition of
>> acpi_tb_init_generic_address to name the parameter byte_width instead
>> of bit_width. The declaration at the top of the file and the
>> documentation still refer to it as bit_width.
>>
>> I also added printk()s to the first call to
>> acpi_tb_init_generic_address ~ line 326 and the lengths passed to the
>> function at that point are:
>> [    0.000000] fadt_info_table[i].length=88
>> [    0.000000] fadt_info_table[i].length=89
>> [    0.000000] fadt_info_table[i].length=93
> 
> Hmm, indeed, I didn't notice the (pointless) earlier declaration, I realize
> I failed to update the function description. Bob, could you fix this in
> ACPICA without the need for me to send a patch against it (assuming
> the base patch went into ACPICA)?

No it went directly.

-Andi

--
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/