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

[Andi Kleen]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/