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.