ACPI: AcpiInitializeTables fails on Acer Aspire One AOA110

[vegardw]

ACPI doesn't seem to work on my Acer Aspire One

I enabled it in /boot/home/config/settings/kernel/drivers/kernel, but after rebooting PowerStatus stil says No power interface found when I start it, and /dev/acpi doesn't exist

Grepping the syslog for ACPI gives the following:

2010-02-21 21:38:21 KERN: smp: using ACPI to detect MP configuration
2010-02-21 21:38:21 KERN: CPU 1: features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clfsh ds acpi mmx fxsr sse sse2 ss htt tm pbe sse3 monitor dscpl est tm2
2010-02-21 22:38:21 KERN: ACPI: RSDP 0x000fe020 00024 (v02 INTEL )
2010-02-21 22:38:21 KERN: ACPI:      0x3f4fe120 00000 (v00                 00000000      00000000)
2010-02-21 22:38:21 KERN: ACPI Error: Invalid length 0x0 in RSDT/XSDT (20100121/tbutils-656)
2010-02-21 22:38:21 KERN: acpi: AcpiInitializeTables failed (AE_INVALID_TABLE_LENGTH)
2010-02-21 22:38:21 KERN: ACPI: RSDP 0x000fe020 00024 (v02 INTEL )
2010-02-21 22:38:21 KERN: ACPI:      0x3f4fe120 00000 (v00                 00000000      00000000)
2010-02-21 22:38:21 KERN: ACPI Error: Invalid length 0x0 in RSDT/XSDT (20100121/tbutils-656)
2010-02-21 22:38:21 KERN: acpi: AcpiInitializeTables failed (AE_INVALID_TABLE_LENGTH)

[vegardw]

Full syslog

[vegardw]

Continuing, clicked create ticket instead of preview...

Tested on hrev35562. When I tried enabling ACPI a month or two ago I was thrown straight into KDL during boot, but that doesn't happen anymore.

[tqh]

What bios version is this?

[vegardw]

I think it is 3109, it says System BIOS Version: v0.3109 in the BIOS setup at least.

Looking at the Acer support pages it seems 3310 is the latest version, so I should probably try upgrading to that one.

[phoudoin]

2010-02-21 22:38:21 KERN: ACPI: RSDP 0x000fe020 00024 (v02 INTEL )
[...]
2010-02-21 22:38:21 KERN: ACPI:      0x3f4fe120 00000 (v00                 00000000      00000000)
[...]
2010-02-21 22:38:21 KERN: ACPI Error: Invalid length 0x0 in RSDT/XSDT (20100121/tbutils-656)
637	2010-02-21 22:38:21 KERN: acpi: AcpiInitializeTables failed (AE_INVALID_TABLE_LENGTH)

RSDP and XSDT addresses looks both valid, but it seems mapping 0x3f4fe120 physical address goes wrong as you get an zeroed block, not the actual XSDT content (which should have a 'XSDT' ascii signature at start and a length of 0x64 bytes.

Question now is who is the culprid for those zeros at 0x3f4fe120: Haiku's map_physical_memory() or Aspire BIOS?

[tqh]

Exactly the same issue has been dealt with in Linux, so there is probably an answer out there.

[bonefish]

Not that I think it makes a difference in this case, but is there a reason why the map_physical_memory() call in AcpiOsMapMemory() uses B_ANY_KERNEL_BLOCK_ADDRESS? The semantics of this address specification is to align the area base address to the size of the area, also requiring a power of 2 size. Since the documentation of AcpiOsMapMemory() doesn't mention any special mapping requirements or properties of the arguments, this doesn't seem right.

[tqh]

No there isn't. Will switch to B_ANY_KERNEL_ADDRESS unless someone does it before me.

[phoudoin]

Replying to bonefish:

Not that I think it makes a difference in this case, but is there a reason why the map_physical_memory() call in AcpiOsMapMemory() uses B_ANY_KERNEL_BLOCK_ADDRESS?

None that I know. This change was introduced in hrev33781. Does B_ANY_KERNEL_BLOCK_ADDRESS semantic means that byte 0 at the virtual address returned doesn't always map to the byte 0 at physical address? That will do a big difference!

[bonefish]

Replying to phoudoin:

Replying to bonefish:

Not that I think it makes a difference in this case, but is there a reason why the map_physical_memory() call in AcpiOsMapMemory() uses B_ANY_KERNEL_BLOCK_ADDRESS?

None that I know. This change was introduced in hrev33781. Does B_ANY_KERNEL_BLOCK_ADDRESS semantic means that byte 0 at the virtual address returned doesn't always map to the byte 0 at physical address? That will do a big difference!

No, B_ANY_KERNEL_BLOCK_ADDRESS only affects the placement of the area, not the mapping. It works like B_ANY_KERNEL_ADDRESS just with a stricter alignment for the (virtual) base address of the area.

[tqh]

We fail in here: ​http://haiku.it.su.se:8180/source/xref/src/add-ons/kernel/bus_managers/acpi/tables/tbutils.c#AcpiTbParseRootTable It's so early that the only thing we could have done wrong was pass in the wrong physical address for rsdp to the function. Maybe some helper function is faulty or that bios is.

[vegardw]

Replying to vegardw:

Looking at the Acer support pages it seems 3310 is the latest version, so I should probably try upgrading to that one.

Upgraded the BIOS to 3310, no difference. So BIOS version doesn't have anything to say.

[tqh]

Could you try after hrev35588. It might affect since the first thing done is:

/*
 * Map the entire RSDP and extract the address of the RSDT or XSDT
 */
 Rsdp = AcpiOsMapMemory (RsdpAddress, sizeof (ACPI_TABLE_RSDP));

[tqh]

Can this be a problem with a 64 bit physical address?

[bonefish]

Replying to tqh:

Can this be a problem with a 64 bit physical address?

Only if the physical address that should be mapped exceeds 32 bit. I doubt that this is the case for anything of interest, but feel free to check.

[tqh]

Added a check for that case in hrev35592. Check for a warning "64-bit Physical Address in XSDT is too large" in syslog.

[tqh]

Marked #5463 as a duplicate of this.

[vegardw]

Tested on hrev35593

Still same behaviour, same error messages in syslog. Did not get the "64-bit Physical Address in XSDT is too large" warning.

[phoudoin]

Replying to tqh:

It's so early that the only thing we could have done wrong was pass in the wrong physical address for rsdp to the function.

I don't think so because:

1. the first AcpiTbPrintTableHeader shows that at RSDP physical address there is actually a RSDP table header, with valid RSDP signature, correct table length value (0x24 for ACPI 2+, 0x14 for older)
2. the physical addresses of both RSDP and XSDT for an Aspire One are the same than reported under Linux. Sample apply for #5463 case.
3. which means that both RSDP revision and XsdtPhysicalAddress fields are read correctly, so the RSDP table mapping is working fine.

What goes wrong must start after, starting at tbutils.c line 630. The first step is to unmap RSDP. Maybe by commenting this line out one could investigate if things behave differently or not...

[tqh]

Yes, I wasn't suggesting it was wrong, I was just stating that there are very few areas that are OS-specific for Haiku up until this point.

Linux does a sanity check on xsdt btw, and if it fails it switches to rsdt. Also they do ioremap in the memory allocation which might mean something. My knowledge in that area is not good enough atm though.

[siarzhuk]

The same observed on Dell Studio 1747 Notebook with following log:

KERN: ACPI: RSDP 0x000f6c10 00024 (v02 DELL  )
KERN: remove_memory_type_range(120, 0xf6000, 0x1000, 0)
KERN: set MTRRs to:
KERN: add_memory_type_range(121, 0xbf7f5000, 0x1000, 0)
KERN: set MTRRs to:
KERN: ACPI:      0xbf7f5d17 00000 (v00                 00000000      00000000)
KERN: remove_memory_type_range(121, 0xbf7f5000, 0x1000, 0)
KERN: set MTRRs to:
KERN: ACPI Error: Invalid length 0x0 in RSDT/XSDT (20100121/tbutils-669)
KERN: acpi: AcpiInitializeTables failed (AE_INVALID_TABLE_LENGTH)

Any suggestions and test cases are welcome! :-) Do you need complete syslog or listdev info?

[tqh]

Luroh and I (not so much) have tracked it down to a hrev34932 to hrev34954 change using vmware. I guessed hrev34948, but our test suggested it's not. I still suspect it though. Also this may be the cause of #5064, it fails to initialize ACPI, so it can't shutdown thru ACPI.

[phoudoin]

Sounds more and more related to unmapping physical memmory.

vegardw, siarzhuk, could your try after commenting the RSDP table unmap in src/add-ons/kernel/bus_managers/acpi/tables/tbutils.c#AcpiTbParseRootTable, near line 649:

    /* It is not possible to map more than one entry in some environments,
     * so unmap the RSDP here before mapping other tables
     */
-   AcpiOsUnmapMemory (Rsdp, sizeof (ACPI_TABLE_RSDP));
+   /* AcpiOsUnmapMemory (Rsdp, sizeof (ACPI_TABLE_RSDP)); */

If this unmap do something wrong, without it you should at least see a different syslog line corresponding to the RSDT/XSDT, less clearly broken than the one you currently got: KERN: ACPI: 0xbf7f5d17 00000 (v00 00000000 00000000)

Could be related to MTRR while unmapping, too...

[tqh]

I think it's mtrr, or the early early handling here: ​http://dev.haiku-os.org/browser/haiku/trunk/src/system/boot/platform/bios_ia32/acpi.cpp?rev=34948

[bonefish]

Replying to tqh:

Luroh and I (not so much) have tracked it down to a hrev34932 to hrev34954 change using vmware.

Since that are only 24 revisions, 5 more bisection steps would narrow it down to one.

I guessed hrev34948, but our test suggested it's not. I still suspect it though. Also this may be the cause of #5064, it fails to initialize ACPI, so it can't shutdown thru ACPI.

I don't see how unmapping the unused mappings could have any effect, but I might miss something.

[tqh]

Replying to bonefish:

Since that are only 24 revisions, 5 more bisection steps would narrow it down to one.

If only they would build...

I guessed hrev34948, but our test suggested it's not. I still suspect it though. Also this may be the cause of #5064, it fails to initialize ACPI, so it can't shutdown thru ACPI.

I don't see how unmapping the unused mappings could have any effect, but I might miss something.

It's just a guess on my part at this point as it directly touches those areas.

[vegardw]

Replying to phoudoin:

vegardw, siarzhuk, could your try after commenting the RSDP table unmap in src/add-ons/kernel/bus_managers/acpi/tables/tbutils.c#AcpiTbParseRootTable, near line 649:

tested on hrev35702 with the table unmap commented out. No difference:

KERN: smp: using ACPI to detect MP configuration
KERN: CPU 1: features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clfsh ds acpi mmx fxsr sse sse2 ss htt tm pbe sse3 monitor dscpl est tm2 
KERN: ACPI: RSDP 0x000fe020 00024 (v02 ACRSYS)
KERN: ACPI:      0x3f4fe120 00000 (v00                 00000000      00000000)
KERN: ACPI Error: Invalid length 0x0 in RSDT/XSDT (20100121/tbutils-669)
KERN: acpi: AcpiInitializeTables failed (AE_INVALID_TABLE_LENGTH)
KERN: ACPI: RSDP 0x000fe020 00024 (v02 ACRSYS)
KERN: ACPI:      0x3f4fe120 00000 (v00                 00000000      00000000)
KERN: ACPI Error: Invalid length 0x0 in RSDT/XSDT (20100121/tbutils-669)
KERN: acpi: AcpiInitializeTables failed (AE_INVALID_TABLE_LENGTH)

[siarzhuk]

Replying to phoudoin:

Sounds more and more related to unmapping physical memmory.

vegardw, siarzhuk, could your try after commenting the RSDP table unmap in src/add-ons/kernel/bus_managers/acpi/tables/tbutils.c#AcpiTbParseRootTable, near line 649:

I have disabled unmapping on hrev35706 but from my point of view all goes the same way. :-\ This is the corresponding part of syslog.

KERN: ACPI: RSDP 0x000f6c10 00024 (v02 DELL  )
KERN: add_memory_type_range(121, 0xbf7f5000, 0x1000, 0)
KERN: set MTRRs to:
KERN: ACPI:      0xbf7f5d17 00000 (v00                 00000000      00000000)
KERN: remove_memory_type_range(121, 0xbf7f5000, 0x1000, 0)
KERN: set MTRRs to:
KERN: ACPI Error: Invalid length 0x0 in RSDT/XSDT (20100121/tbutils-669)
KERN: acpi: AcpiInitializeTables failed (AE_INVALID_TABLE_LENGTH)

[tqh]

I'll do a full rebuild to make sure but it seems hrev34933 is what breaks ACPI. This is the syslog from hrev34932 is VmWare:

KERN: ACPI: RSDP 0x000f6940 00024 (v02 PTLTD )
KERN: ACPI: XSDT 0x1fefa13b 0003C (v01 INTEL  440BX    06040000 VMW  01324272)
KERN: ACPI: FACP 0x1fefee98 000F4 (v04 INTEL  440BX    06040000 PTL  000F4240)
KERN: ACPI: DSDT 0x1fefa21f 04C79 (v01 PTLTD  Custom   06040000 MSFT 03000001)
KERN: ACPI: FACS 0x1fefffc0 00040
KERN: ACPI: BOOT 0x1fefa1f7 00028 (v01 PTLTD  $SBFTBL$ 06040000  LTP 00000001)
KERN: ACPI: APIC 0x1fefa1a7 00050 (v01 PTLTD  ? APIC   06040000  LTP 00000000)
KERN: publish device: node 0x80fbb0a0, path acpi/namespace, module bus_managers/acpi/namespace/device_v1

[tqh]

hrev34933:

KERN: ACPI: RSDP 0x000f6940 00024 (v02 PTLTD )
KERN: ACPI:      0x1fefa13b 00000 (v00                 00000000      00000000)
KERN: ACPI Error: Invalid length 0x0 in RSDT/XSDT (20090903/tbutils-656)
KERN: acpi: AcpiInitializeTables failed (AE_INVALID_TABLE_LENGTH)

[bonefish]

Analyzing #1925 I encountered a general problem in the boot loader. Physical address ranges between usable RAM ranges can later in the kernel erroneously become allocatable memory (at least if they aren't claimed during the VM setup). hrev34933 changes how physical pages are freed. Since that revision they are enqueued at the front, so they are reused as quickly as possible (thus being more cache friendly). For aforementioned non-RAM ranges, that means they are likely already allocated during the boot process, so that the negative effects can be observed earlier than before (where that would only happen after a full cycle through the free list).

I'm currently working on fixing the problem, but unexpectedly the actually rather easy fix seems to cause the boot process to hang later (double fault without entering KDL). Investigating...

[bonefish]

Fixed the mentioned issue in hrev35726. Would be interesting to see whether that improves that situation.

[tqh]

Works fine in VMware, can someone using real hardware confirm?

[vegardw]

Works on real HW too, result of grep -i ACPI /boot/common/var/log/syslog on my Aspire One with hrev35727 :

KERN: smp: using ACPI to detect MP configuration
KERN: CPU 1: features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clfsh ds acpi mmx fxsr sse sse2 ss htt tm pbe sse3 monitor dscpl est tm2 
KERN: ACPI: RSDP 0x000fe020 00024 (v02 ACRSYS)
KERN: ACPI: XSDT 0x3f4fe120 00064 (v01 ACRSYS ACRPRDCT 00000001      01000013)
KERN: ACPI: FACP 0x3f4fc000 000F4 (v04 ACRSYS ACRPRDCT 00000001 1025 01000013)
KERN: ACPI: DSDT 0x3f4f2000 05DE6 (v01 ACRSYS ACRPRDCT 00000001 1025 01000013)
KERN: ACPI: FACS 0x3f488000 00040
KERN: ACPI: SSDT 0x3f4fd000 004C4 (v02  PmRef    CpuPm 00003000 INTL 20051117)
KERN: ACPI: HPET 0x3f4fb000 00038 (v01 ACRSYS ACRPRDCT 00000001 1025 01000013)
KERN: ACPI: APIC 0x3f4fa000 00068 (v02 ACRSYS ACRPRDCT 00000001 1025 01000013)
KERN: ACPI: MCFG 0x3f4f9000 0003C (v01 ACRSYS ACRPRDCT 00000001 1025 01000013)
KERN: ACPI: ASF! 0x3f4f8000 000A5 (v32 ACRSYS ACRPRDCT 00000001 1025 01000013)
KERN: ACPI: SLIC 0x3f4f1000 00176 (v01 ACRSYS ACRPRDCT 00000001 1025 01000013)
KERN: ACPI: BOOT 0x3f4f0000 00028 (v01 ACRSYS ACRPRDCT 00000001 1025 01000013)
KERN: ACPI: Executed 1 blocks of module-level executable AML code
KERN: publish device: node 0xccd260a0, path acpi/namespace, module bus_managers/acpi/namespace/device_v1
KERN: publish device: node 0xccd62820, path power/embedded_controller/0, module drivers/power/acpi_embedded_controller/device_v1
KERN: publish device: node 0x828282d0, path power/acpi_battery/0, module drivers/power/acpi_battery/device_v1

[tqh]

Thanks for reporting bugs, and for verifying that they are fixed.

Ingo, nice work!