Bug #569
closed
ACPI issues (maybe)
0%
Description
Hi.
Please post any bug reports to bugs@, whether it's ACPI-related or
not.
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,
you do:
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
boot loader)?
Cheers.
Updated by josepht almost 18 years ago
This was happening before 1.8 and also happens with a UP kernel.
No this only happened with 'options ACPI_DEBUG' in my kernel config
file.
Thanks,
Joe
Updated by qhwt+dfly almost 18 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:
cd /sys/dev/acpica5
export ACPI_DEBUG=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
the clue.
Cheers.
Updated by josepht almost 18 years ago
I updated to the latest BIOS from Toshiba and there is no change.
Joe
Updated by qhwt+dfly almost 18 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.
Cheers.
Updated by josepht almost 18 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.
Joe
Updated by alexh over 14 years ago
Does this still happen? Is this relevant to anyone?
Cheers,
Alex Hornung
Updated by qhwt+dfly over 14 years ago
Hi.
If you still have access to the laptop M115-S3094, can you confirm that
the problem (can't power off using shutdown command) persists or not?
Updated by tuxillo almost 10 years ago
- Description updated (diff)
- Category set to ACPI
- Status changed from New to Closed
- Assignee deleted (
0) - Target version set to 4.2
Hi,
Apparently the Core Duo T2050 (the processor in that laptop) is 32-bit only.
Closing this one as i386 is no longer supported.
Cheers,
Antonio Huete