ACPI issues (maybe)
Please post any bug reports to bugs@, whether it's ACPI-related or
Is this bug new in 1.8? Do you experience this problem when you
run a UP kernel?
That's how you enable some debugging features when the acpi driver is
compiled in the kernel. However, compiling the ACPI driver in the kernel
is not supported at the moment, as some modifications to ACPI-CA code are
given as *.patch files in /sys/dev/acpica5 and those are not used when
compiled in the kernel (I believe there's a few other drivers which also
use *.patch files, but I haven't tried to see if these are not used either).
To compile an acpi driver with debugging feature enabled for an SMP kernel,
export ACPI_DEBUG=yes CFLAGS='-O -pipe -DSMP=1'
for bourne shell users, or for *csh,
setenv ACPI_DEBUG yes
setenv CFLAGS '-O -pipe -DSMP=1'
Sounds like ACPI driver failed to load. Do you have this problem
when you boot with ACPI disabled (debug.acpi.disabled="acpi" in the
#2 Updated by qhwt+dfly almost 8 years ago
I feel relieved to hear that somehow ;) I saw a similar problem on
some of PCs around, but disable_on_poweroff always worked. Does updating
BIOS fix it?
I recommend against compiling acpi driver in the kernel.
I believe I know it. In short, don't use that option, and build acpi
driver with an environment variable ACPI_DEBUG set to yes:
export CFLAGS='-O -pipe -DSMP=1' (only for SMP kernel)
make obj && make depend && make && make install
The problem is that you used an option which only applies to acpi driver
compiled in the kernel, but if you build the kernel by buildkernel or
nativekernel, that option gets propagated to module build without adding
necessary files. When you reboot your laptop, acpi driver fails to
load because of missing symbols which are supposed to be defined in those
missing files. If this is the case, /var/run/dmesg.boot should contain
#4 Updated by qhwt+dfly almost 8 years ago
That's too bad. Can you try to see if `acpiconf -d' also locks up your
laptop. What it does is call acpi_Disable() to transfer the system into
legacy(non-ACPI) mode, and this function is also called when you reboot
it, or try to shutdown with hw.acpi.disable_on_poweroff=1. You'd better
try this in single-user mode to avoid fsck in the next boot.
#5 Updated by josepht almost 8 years ago
I do not get a lock-up with 'acpiconf -d'. Though lock-up doesn't
seem like the correct term. With hw.acpi.disable_on_poweroff=1
a 'shutdown -h now' shuts down the laptop as usual but at the "Press
any key to reboot..." message I must press and hold the power button
to power off the laptop. With hw.acpi.disable_on_poweroff=0 a
'shutdown -h now' shuts down the laptop and a single tap of the power
button powers off the laptop. I seems like the laptop goes into
suspend mode rather than actually powering off the hardware.
- Description updated (diff)
- Category set to ACPI
- Status changed from New to Closed
- Assignee deleted (
- Target version set to 4.2.x
Apparently the Core Duo T2050 (the processor in that laptop) is 32-bit only.
Closing this one as i386 is no longer supported.