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 09:59:53 +0100
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Andrew Paprocki" <andrew@...iboo.com>
Cc:	<robert.moore@...el.com>, "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:348
	acpi_tb_create_local_fadt+0x147/0x2f4()

>I added printk()s and this is what is reported here:
>
>        printk(KERN_INFO
>               "xpm1a_event_block bit_width=%d pm1_register_length=%d\n",
>               acpi_gbl_FADT.xpm1a_event_block.bit_width, pm1_register_length);
>        acpi_tb_init_generic_address(&acpi_gbl_xpm1a_enable,
>                                     pm1_register_length,
>                                     (acpi_gbl_FADT.xpm1a_event_block.address +
>                                      pm1_register_length));
>
>[    0.000000] xpm1a_event_block bit_width=8 pm1_register_length=0
>
>The bit width is not % 16, so the following patch addition a few lines
>earlier fails:
>
>        WARN_ON(ACPI_MOD_16(acpi_gbl_FADT.xpm1a_event_block.bit_width));

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.

I'd be hesitant to fix this (as I think we should be allowed to expect
ACPI tables to not be that fundamentally flawed these days), but of
course Len (or others) might be of a different opinion.

>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)?

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/