Most recent kernel where this bug did not occur: Distribution: Debian etch (self-compiled kernel) Hardware Environment: i386 P4 2.6 GHZ ACPI/Hyperthreading+SMP Software Environment: gcc 4.0.3-3-debian Problem Description: On boot, right after printing "ACPI (supports S0 S1 S4 S5)" I get a series of errors: [17179574.336000] osl-0856 [07] os_wait_semaphore : Failed to acquire semaphore[c19de8a0|1|0], AE_TIME [17179574.336000] ACPI Exception (utmutex-0257): AE_TIME, Thread 0 could not acquire Mutex [8] [20060127] Sometimes, this does not happen at all. Sometimes it happens only 2 times or 8 times. But occasionally (usually in the first boot of the day), the kernel repeats this error indefinitely (continuously scrolling console). Rebooting (hard reset) will usually allow the computer to correctly reboot.
Created attachment 8287 [details] dmesg (from syslog) of a time when this error occurred (but booted successfully).
Please try build a kernel with acpi debug option disabled, and see if there could have other problems after removing the side effect of printk flood, and acpi debug overhead.
I ended up compiling a kernel with disabled SMP to debug a different bug, and I found that without SMP (Hyperthreading), this bug happens every time instead of only occasionally. I disabled ACPI debugging as well as the "ACPI Exception" printk that occurred in drivers/acpi/utilities/utmisc.c. Disabling the two debug messages just makes the kernel hang when it reaches that spot. This may have made the race condition (I assume) in SMP mode less frequent, but it had no effect in allowing me to boot with SMP disabled. I have no idea how to debug this type of problem.
Checking the error message, the semaphore in question is ACPI_MTX_HARDWARE, used to lock the ACPI hardware. This type of internal semaphore is always called with a WAIT_FOREVER timeout; therefore an AE_TIME should never occur. The next step would be to determine why the timeout is happening (in the OSL)
Given that the thread ID is zero, perhaps this is the case where an attempt to acquire the semaphore is being made at interrupt level. Starting in ACPICA version 20060608, we changed the hardware semaphore to a spinlock to avoid any such problems.
Please test the latest acpi test tree containing ACPICA version 20060608. If doesn't work, just reopen the bug.