Bug 9444

Summary:	AE_NO_ACPI_TABLES - Acer Travelmate C104TCi
Product:	ACPI	Reporter:	Len Brown (lenb)
Component:	Config-Tables	Assignee:	Len Brown (lenb)
Status:	CLOSED CODE_FIX
Severity:	normal	CC:	acpi-bugzilla, linux, rui.zhang, yakui.zhao
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.23	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	patch vs 2.6.24-rc3 to use ACPICA RSDP scanning code Scan whether multiple RSDP exists Add the boot option to select which rsdp instance to use verify the checksum of RSDP to avoid bogus RSDP

Description Len Brown 2007-11-23 16:59:17 UTC

From: TJ

I've been debugging an ACPI-disabled-at-boot failure on an Acer
Travelmate C104TCi (C100) with a Wistron BIOS.

[ 0.000000] DMI 2.3 present.
[ 0.000000] ACPI: RSDP 000EC2D0, 0014 (r0 Acer )
[ 0.000000] ACPI:   00000000, F000FF5A (r195 Zÿ F000FF57 Zÿ F000FEA5)
[ 27.751333] ACPI: Core revision 20070126
[ 27.751501] ACPI Exception (tbxface-0618): AE_NO_ACPI_TABLES, While
loading namespace from ACPI tables [20070126]
[ 27.751654] ACPI: Unable to load the System Description Tables
[ 27.783596] ACPI: Interpreter disabled.

There are several references to this problem around the net and a couple
of invasive kernel patches that don't address the cause.

I wrote a user-space application that scans memory using the method
described in the ACPI specifications. It reports:

$ sudo ./find-RSDP

find-RSDP version 0.1 © 2007 TJ
Licensed on the terms of GPL version 3

Finds ACPI Root System Descriptor Pointer (for supported BIOS's only).

0x00000000FFFFFFFF Memory size
0x00000000000EC2D0 "RSD PTR "
0x00000000000FE030 "RSD PTR " RSDT @ 0FFE0000 OEM: "Acer " sum: 0
0x0000000005FBFE10 "RSD PTR "

Unfortunately the kernel function

arch/i386/kernel/acpi/boot.c::acpi_scan_rsdp()

doesn't fully implement the ACPI specification - it simply looks for the
first "RSD PTR " signature but doesn't check it has found a valid table
by calculating the checksum.

Because this series of BIOSs happen to have multiple instances of "RSD
PTR " and an invalid instance appears first in memory, the kernel tries
to use an invalid pointer to the RSDT, leading to the problems.

Comment 1 Len Brown 2007-11-23 17:04:16 UTC

Created attachment 13724 [details]
patch vs 2.6.24-rc3 to use ACPICA RSDP scanning code

TJ, Please verify that this patch works on the failing system.

Comment 2 Zhang Rui 2007-11-25 18:27:32 UTC

Yes, this patch returns rsdp with the correct checksum.
Do you want to get this patch upstream?
But some laptops may use the un-tested rsdp once this patch is applied.
I mean they always use the first rsdp so they never know whether other rsdps  can work for them even or not if they have the correct checksum.
Yakui and me are looking at this issue and Yakui already has a fix for this issue.
The first patch parse the whole memory and list all the rsdps found, with the debug messages as well if more than one rsdps exist, but the first rsdp is always returned by default.
The second patch add a kernel parameter acpi_rsdp_instance so that users can choose which rsdp to use just like what we do for multiple MADTs.

Len, what do you think about the latter fix?
IMO, the best way is to verify which dsdt does windows choose so that we can use the same one...

Comment 3 ykzhao 2007-11-26 22:22:44 UTC

I agree with what Rui said. And the following two patches are attached.

Comment 4 ykzhao 2007-11-26 22:23:35 UTC

Created attachment 13767 [details]
Scan whether multiple RSDP exists

Comment 5 ykzhao 2007-11-26 22:24:36 UTC

Created attachment 13768 [details]
Add the boot option to select which rsdp instance to use

Comment 6 Len Brown 2007-11-26 22:41:46 UTC

The bug at hand is that Linux fails to boot into ACPI mode
if it finds an RSDP with an invalid checksum.
I belive that bug is fixed by the patch in comment #1,
which is in acpi-test, queued for 2.6.25.

If there are systems which have multiple valid RSDP's...
In the past Linux used the first on it found,
and after patch #1 is applied, we will continue to
use the first one found -- no change in behaviour there.

Using the common ACPICA code is the proper way to address
this issue.  If the common ACPICA code is not correct,
then it must be fixed.  Patching the old Linux routines
for this is not the right way to go.

RE: system with multiple _valid_ RSDP's...
Has such a system been found, or are you proposing that
we go fish for some?  If we do go fishing, the patch
must apply on top of the patch in comment #1, also
it shouldn't add dmesg noise if it happens to find
redundant RSDPs that have the same (poingter) contents.

Comment 7 ykzhao 2007-11-26 23:50:52 UTC

The patch in comment #1 has no problem for x86_64. But there is some problem for x86_32 if the system supports the NUMA architecture.
In NUMA architecture the 32-bit OS will search SRAT table before initializing bootmem memory allocator and SRAT table is gotten by calling get_memcfg_from_srat, in which the function of acpi_find_rsdp. Because the function of acpi_os_map_memory is used in the ACPICA code and paging_init should be called before using acpi_os_map_memory, the patch in comment #1 will have some problems.

If the checksum should be verified for RSDP , we can modify the patch #4 for getting the rsdp with valid checksum.

Comment 8 ykzhao 2007-11-27 01:29:06 UTC

The patch in comment #1 has no problem for x86_64. But there is some problem
for x86_32 if the system supports the NUMA architecture.
In NUMA architecture the 32-bit OS will search SRAT table before initializing
bootmem memory allocator and SRAT table is gotten by calling
get_memcfg_from_srat, in which the function of acpi_find_rsdp is called. Because the function of acpi_os_map_memory is used in the ACPICA code and paging_init
should be called before using acpi_os_map_memory, the patch in comment #1 will
have some problems.

If the checksum should be verified for RSDP , we can modify the patch in comment #4 for getting the rsdp with valid checksum.

Comment 9 ykzhao 2007-11-27 01:31:53 UTC

Created attachment 13769 [details]
verify the checksum of RSDP to avoid bogus RSDP

Comment 10 TJ 2007-11-30 14:59:48 UTC

Len, sorry it has taken me a while to respond on this.

Unfortunately I'm unable to verify your patch since I no longer have access to the laptop that I developed the Ubuntu 2.6.22 kernel patch for.

That said, provided the patch is simply ensuring it checks for a valid checksum then I can't see a problem.

Comment 11 ykzhao 2007-12-06 01:50:57 UTC

The patch in comment #1 can also be applied on the x86_32 system . Now it is tested in the acpi-test tree. Please ignore the patch in comment #4,5,10.
Thanks.

Comment 12 Len Brown 2008-02-10 14:41:09 UTC

patch in comment #1 shipped in Linux-2.6.24-rc22
closed.

Comment 13 Len Brown 2008-02-10 16:48:19 UTC

Linux-2.6.24-git22, that is.