Bugzilla – Bug 119177
acpi not working for HP tc4200
Last modified: 2005-10-31 16:04:11 UTC
Shortly after booting the kernel it stands still. On text console (without the vga parameter) quite a lot of acpi errors occur. Obviously the kernel is still running and showing acpi events by printing typical acpi errors like: ACPI-0700: *** Error: acpi_ev_gpe_dispatch: No handler or method for GPE[11], disabling event The other error messages are too fast out of sight for reading them... With acpi=off or acpi=oldboot the kernel boots, but a lot of problems occur, that make the machine practically unusable. With acpi=noirq the kernel boots a few steps further but than hangs at some IRQ routing problems related to acpi. Is it ignoring noirq ?? Knoppix is booting with acpi on without problems and is working perfectly. Also acpi is working well and has a lot of features... I also tested SuSE 9.3 . It's booting with acpi enabled, but somewhat unstable. It crashes at different stages of installation, but always during some hardware detection. Are there any new major patches for acpi in SL 10? Is it possible to compile a usefull kernel without them?
Finally I found a combination working quite reliable: vanilla 2.6.13.2 with kernel boot option pci=noacpi ACPI is working and the rest of the hardware also looks good. vanilla 2.6.12.6 is booting even without pci=noacpi. ACPI is working, but no hotplug. The kernel from RC1 2.6.13-8-default is not booting with ACPI (even with pci=noapci). The error messages are obviously related to ACPI. Without ACPI a lot more things are broken than I previously reported. For example plugging in an Ethernet cable leads to system lock up...
You probably hit bug #116763 (boot hangs without pci=noacpi). The current update kernel: ftp.suse.com/pub/people/mantel/kotd/kotd/10.0-i386/SL100_BRANCH/kernel-default.i586.rpm should fix this. Could you try it out and report back whether you can boot further or even if everything is OK, please.
Seems to work as good as vanilla 2.6.13.2 ! I get some ACPI warnings I don't get from vanilly 2.6.13.2: Warning: Unknown GPE method type: C271 (name not of form _Lxx or _Exx) The same for C1EC, C272, C273, C212. Perhaps the vanilla kernel just doesn't print the warnings... BTW: Booting a 2.6.13 without pci=noacpi seems to scramble the ACPI-BIOS somehow. Even with pci=noacpi the kernel hangs afterwards shortly after booting it. The only way to fix it is to boot Windows 8-0 Afterwards 2.6.13 is running again (with pci=noacpi). One more thing I forgot to mention: reboot is not working with any 2.6.13 kernel I've tried. The system locks at the moment it should reboot. halt is working. System turns off without problems. With 2.6.12.6 halt and reboot are working both perfectly. This observation, the need to use pci=noacpi and an entry in the kernel changelog from 2.6.12 to 2.6.13 about rework on ACPI interrupt routing, make me think about using a 2.6.12 ...
Perhaps the vanilla kernel just doesn't print the warnings... -> You need to enable ACPI_DEBUG=y As good as 2.6.13.2 means it does not boot without pci=noacpi? Maybe it took to long until the ftp server was synced? Could you verify that you installed the right kernel by: rpm -q --changelog /mounts/dist/kerneltest/i386/HEAD/kernel-default.i586.rpm |less You must see this change in the changelog: * Thu Oct 06 2005 - okir@suse.de - patches.fixes/acpi-endless-loop: [ACPI] Fix ACPI device scan (116763). Give me some hours and I could provide you another kernel where the reboot thing is hopefully also fixed (I will put it into my personal ftp dir, so you do not need to recheck with rpm --changelog). Please boot with sysreq=1 boot param and if it does hang (without pci=noacpi), please press the <sysreq><t> buttons (sysreq is normally ALT-PRINT in the right up corner of the keyboard). You should then see the last functions the kernel was poking around. If you can setup a serial console to save the output, that would be perfect. I let you know as soon as I have build up the kernel.
(In reply to comment #4) > Perhaps the vanilla kernel just doesn't print the warnings... > -> You need to enable ACPI_DEBUG=y I see. CONFIG_ACPI_DEBUG_LITE is not in vanilla ;-) > As good as 2.6.13.2 means it does not boot without pci=noacpi? Exactly! > You must see this change in the changelog: > * Thu Oct 06 2005 - okir@suse.de > - patches.fixes/acpi-endless-loop: [ACPI] Fix ACPI device scan (116763). The changelog is correct. > Give me some hours and I could provide you another kernel where the reboot thing > is hopefully also fixed (I will put it into my personal ftp dir, so you do not > need to recheck with rpm --changelog). Would be great! Thanks! > Please boot with sysreq=1 boot param and if it does hang (without pci=noacpi), > please press the <sysreq><t> buttons (sysreq is normally ALT-PRINT in the right > up corner of the keyboard). You should then see the last functions the kernel > was poking around. Doesn't look good. The sequence is not working. It's working after a correct boot, so I used the right combination. Perhaps a problem with they keyboard. I have to use this dam... fn special key to get <sysreq>. Perhaps this is not working so early at boot time. > If you can setup a serial console to save the output, that > would be perfect. Sorry, it's a "modern" notebook. No serial port :-(
Sorry for the delay..., the reboot issue should be solved with this kernel (the patch will be added to CVS soon): ftp.suse.com/pub/people/trenn/10_0_kernel_reboot_fix/kernel-default-2.6.13-2.i586.rpm
(In reply to comment #6) > the reboot issue should be solved with this kernel Sorry, seems like nothing has changed at all...
Could you attach dmesg and acpidmp output, seems to be something machine specifc.
Created attachment 54302 [details] acpidmp
Created attachment 54305 [details] dmesg
Forgot to set status back to ASSIGN after attaching acpidmp and dmesg... But yesterday I relised a really bigger problem. Seems like ACPI got some more problems: ACPI-0463: *** Warning: Critical trip point Critical temperature reached (100 C), shutting down. The fans weren't running as fast as it could have been. Booting Windows directly after this shutdown was really "noisy". I'm not an ACPI expert, but cat /proc/acpi/thermal_zone/TZ1/cooling_mode gives <setting not supported> cooling mode: active and leeds (for the first time) to the syslog entry ACPI-1048: *** Warning: Failed to acquire semaphore[df7b1220|1|0], AE_TIME That doesn't look good...
Fixed the reboot issue with the kernel parameter reboot=b
Fixed the temperature problems. I misconfigured cpufreq, which somehow lead to problems with the trip points. After fixing cpufreq and a reboot the trip points are working again... Overheating should be no problem anymore...
We should close this one. Further debugging only makes sense if I'd had the hardware in my hands. Is it right, that the machine is running fine now with your workarounds/bootparams added? If you like you might want to add an article what workarounds are needed for your specific machine here: http://susewiki.org/
> We should close this one. > Further debugging only makes sense if I'd had the hardware in my hands. > Is it right, that the machine is running fine now with your > workarounds/bootparams added? Yes. Only some ACPI error messages remain, but most things are obviously working. The only real problem is that irq routing is not working with ACPI (pci=noacpi). But I don't know if that's really a drawback... Ah! Forgot to mention: Neither suspend-to-ram, nor suspend-to-disk is working. Most likely this is related to the irq routing problem. After initializing nearly every found piece of hardware I get something like: ACPI-0212: *** Warning: Device is not power manageable With 2.6.12.6 and ACPI irq routing suspend-to-disk is working! BTW: "shutdown -z" is rebooting the system after successfully returning from suspend-to-disk... "echo disk > /sys/power/state" is working. > If you like you might want to add an article what workarounds are needed for > your specific machine here: > http://susewiki.org/ Good idea! I will add some text the next days. Is there no special page for specific hardware on the wiki? When will a new kernel (with the fixes included) be available through YOU? It would be very useful for normal users to look at the wiki and get an easy step-by-step guide like "install with acpi=off, install updates, change to acpi=on".
> ACPI-0212: *** Warning: Device is not power manageable This is harmless.