lkml.org 
[lkml]   [2008]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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



\
 
 \ /
  Last update: 2008-07-17 11:09    [W:0.052 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site