Thanks for the suggestion. I tried this to no avail.
So I've built and run a slightly modified build. Here's a basic overview of my changes:
- I removed the comment before each preprocessor define of
TRACE_BATTERY (or similar) in the
acpi_*.cpp driver sources
- I changed
ACPICAHaiku.cpp's define of
DEBUG_OSHAIKU to 2 (for full debug).
- I then made a few printf-style formatting changes so that the formatting wouldn't cause compiler errors when targeting x86_64. (Warnings are treated as errors, and I never loosen code quality settings ). Of course, my changes would likely break x86 regular build, so I won't submit a patch -- at least not in the current state.
- They were mostly simple things because I'm building for x86_64 and the strings were using
%ld for UINT32; resolving compiler complains like "expected
unsigned long parameter but received
- There were just a couple where
ACPI_MUTEX types preprocessed into
mutex *, but the format string included
%ld. Changed these to
%p and casted the formatting input to
(void*), since it's actually a pointer.
Built and runs, but I can see the hang when I enabled debug output and disabled paging -- it seems to be some infinite loop, with this spamming over and over:
acpi: ACPI_STATUS AcpiOsAcquireMutex(mutex*, UINT16)(mutex: 0xffffffff820076c0; timeout: 65535)
acpi: ACPI_STATUS AcpiOsAcquireMutex(mutex*, UINT16)(mutex: 0xffffffff820076c0; timeout: 65535 result: 0)
acpi: void AcpiOsReleaseMutex(mutex*)(mutex: 0xffffffff820076c0)
Occasionally the thread number will switch (the beginning
acpi[%d] format is rendered with
find_thread(NULL) as the first parameter), and there are a few other messages thrown in between.
So I started again, this time not disabling the paging. The acquire/release spam starts extremely early in the ACPI-related logs. It looks like other things are happening in-between, but never when the mutex is actually held -- unless I'm distracted and not reading carefully.
Once the rest of the messages finish, it seems the main spam only has an occasional set of lines like these:
acpi: cpu_status AcpiOsAcquireLock(spinlock*)(spinlock: 0xffffffff82016610)
acpi: void AcpiOsReleaseLock(spinlock*, cpu_status)(spinlock: 0xffffffff82016610)
This is repeated about 3 times before it returns back to acquiring and releasing the mutex.
And much less common, I'm seeing the following single line, obviously with different results:
acpi: void* AcpiOsAllocate(ACPI_SIZE)(result: 0xffffffff8228cc80)
It makes sense that the results differ each time, since I'm not seeing any traces of that memory freed.
Interestingly, the mutex from the previous boot has the exact same pointer value on this boot. I suppose that's probably to be expected if address space isn't randomized.
Anyway, I've run out of free time for today. I must chase my daughters to sleep and then get some rest myself.
When I get time again, I'll reduce the tracing a bit and see if I can find where/why it gets stuck in this loop of acquiring/releasing a mutex, then periodically acquiring more memory for ACPI. As always, I appreciate any pointers.