Hi there,
It's nice to see that work was done on ACPI, thanks for that! I hope later
on the problems will be fixed.. :-)
Keeping my custom build with the fix here to keep my laptop working OK for
now..
Bye!
Rudolf.
On Sat, Jan 2, 2016 at 3:02 AM, Jessica Hamilton <
jessica.l.hamilton@xxxxxxxxx> wrote:
On 2 January 2016 at 15:01, Jessica Hamilton
<jessica.l.hamilton@xxxxxxxxx> wrote:
Some follow up for https://dev.haiku-os.org/ticket/12549 :-)
So, with a little bit of tracing, it appears the kernel is overwriting
ACPI tables if I'm interpreting the output correctly...
From BusManager.cpp:get_next_entry(), we eventually end up in ACPI's
AcpiNsBuildNormalizedPath, where it all falls down.
Dumping of memory of a valid ACPI entry:
kdebug> dw 0x82a36ef0
[0x82a36ef0] x^......WAK_.... 82a35e78 0100080f 5f4b4157 81aabc00
kdebug> dw 0x81aabc00
[0x81aabc00] X.......\___.... 82a0e258 0010060f 5f5f5f5c 00000000
And the corrupted entry:
kdebug> dw 0x82a36ce0
[0x82a36ce0] .1......_S3_.1.. 82a26cb0 0100040f 5f33535f 82a36cf8
kdebug> dw 0x82a36cf8
[0x82a36cf8] acpi_physical_me 69706361 7968705f 61636973 656d5f6c
kdebug> dw 0x82a36d
The last 4 bytes are the Parent field of an ACPI_NAMESPACE_NODE, see
acpica/include/aclocal.h:257
In AcpiNsBuildNormalizedPath:
NextNode = NextNode->Parent;
NextNode ends up pointing to the string constant
"acpi_physical_mem_area", leading to the kernel panic.
And the "acpi_physical_mem_area" string constant is
found in AcpiOsMapMemory():
area_id area = map_physical_memory("acpi_physical_mem_area", ...);
So it seems like the bootloader hasn't reserved all of the ACPI tables
early on, such that the creation of an area for ACPI ironically clobbers
ACPI... at least that's how it looks thus far. At this point, I'm not
really sure how to proceed further. And I don't have a machine that's
capable of serial debugging anymore :(
Oops, I forgot to add, a patch for the debug output I used to help
trace things: https://gist.github.com/jessicah/8557c9f87f317050e86a
