Most recent kernel where this bug did not occur: 2.6.15.X Distribution: Debian (testing with most recent kernel-package from unstable for compiling 2.6.18) Hardware Environment: IBM Thinkpad X21 (Intel Mobile Pentium III [LV], Intel 440ZXM, all but HDD stock components, most recent bios/embeded controler firmware) Software Environment: normal desktop distribution stuff, cpufreqd (2.1.1) (all other cpufreq-deamons dosn't "fix" it so there is no bug) Problem Description: I normaly use cpufreqd to switch the frequency from this processor in a "ondemand" way, never had problems with older kernels then 2.6.16. Because of some strange behavior I had to compile the cpufreq-kernel-option with debug options, because the relaxed speedstep checks wouldn't work without it, and are needed for this first generation speedstep. Then some users reported this "bug" (needed debug option) and someone "fixed" this in a 2.6.16-rc. With this and all more recent kernel-versions the error occours: Booting and the first 2 to 4 minutes of doing something works without a problem, but after this time (and some freqency switching) I can't use all "special" functions (as I think) provided by IBM's embeded controler. switching the volume with the "hardware" buttons gets very slow (normal switch/respond-time after pressing is <1sek, then it >5sek) and the FN-F* funktions don't work at all (FN-F7 for Monitor swich, ...) If I simply don't switch the frequency (disable the deamon) and reboot, the bug is gone but this is now solution, because the causes mutch more powercounsuming I have tested any possible cpufreq kernel options combination, but if switching works, this bug is there... Steps to reproduce: compile kernel with any working cpufreq option combination, boot it, switch the frequency some times, get this bug...
switching from Preemption Model (Preemptible Kernel (Low-Latency Desktop)) ---> Voluntary Kernel Preemption (Desktop) to Preemption Model (Preemptible Kernel (Low-Latency Desktop)) ---> Preemptible Kernel (Low-Latency Desktop) causes the same bug with 2.6.15.x kernels... and the bug bugs the whole acpi, even the power_off (last init.d cmd) needs mutch more time to to its job (on all kernels)
This bug is still present in latest kenel versions. Because of security and feature lack while using the old 2.6.15.7 kernel I am going to think about not using linux anymore. Disable speedstep realy is no option on a (sub-)notebook It would be greate if someone could even try to fix this bug.
Created attachment 9375 [details] syslog with acpi exeption (and maybe more helpful information)
I may have found some helpful ACPI output: this is from my syslog and the timestamp matches the point where acpi stoped working correctly. I'll attach the whole file: Oct 29 18:40:17 localhost kernel: ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for [EmbeddedControl] [20060707] Oct 29 18:40:17 localhost kernel: ibm_acpi: acpi_evalf(TMP0, d, ...) failed: 19 Oct 29 18:40:18 localhost kernel: ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for [EmbeddedControl] [20060707] Oct 29 18:40:18 localhost kernel: ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.ISA_.EC__.AC__._PSR] (Node c136c540), AE_TIME Oct 29 18:40:18 localhost kernel: ACPI Exception (acpi_ac-0096): AE_TIME, Error reading AC Adapter state [20060707] Oct 29 18:40:18 localhost kernel: ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for [EmbeddedControl] [20060707] Oct 29 18:40:18 localhost kernel: ibm_acpi: acpi_evalf(TMP0, d, ...) failed: 19 I hope this helps and someone cares
Moved to ACPI bucket.
The bug disappears with the 2.6.18.3 kernel, but is still present in 2.6.19-rc6 (so it is not really fixed now). With 2.6.18.3 all buttons and acpi functions work, but it still throws a lot of errors to syslog (even with no debug/verbose option set): Nov 23 20:45:08 localhost kernel: ACPI: read EC, OB not full Nov 23 20:45:08 localhost kernel: ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for [EmbeddedControl] [20060707] Nov 23 20:45:08 localhost kernel: ibm_acpi: acpi_evalf(TMP7, d, ...) failed: 19 Nov 23 21:15:48 localhost kernel: ACPI: read EC, OB not full Nov 23 21:15:48 localhost kernel: ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for [EmbeddedControl] [20060707] Nov 23 21:15:48 localhost kernel: ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.LID_._LID] (Node c13765e0), AE_TIME Nov 23 22:53:20 localhost kernel: ACPI: read EC, OB not full Nov 23 22:53:20 localhost kernel: ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for [EmbeddedControl] [20060707] Nov 23 22:53:20 localhost kernel: ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.LID_._LID] (Node c13765e0), AE_TIME Nov 23 23:40:14 localhost kernel: ACPI: read EC, IB not empty Nov 23 23:40:14 localhost kernel: ACPI: read EC, IB not empty Nov 23 23:40:14 localhost kernel: ACPI: read EC, OB not full Nov 23 23:40:14 localhost kernel: ACPI Exception (evregion-0424): AE_TIME, Returned by Handler for [EmbeddedControl] [20060707] Nov 23 23:40:14 localhost kernel: ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.ISA_.EC__.AC__._PSR] (Node c136c540), AE_TIME Nov 23 23:40:14 localhost kernel: ACPI Exception (acpi_ac-0096): AE_TIME, Error reading AC Adapter state [20060707]
With Kernel 2.6.20.X this bug is disappeared, hopefully for ever, as I change my notebook to a newer one, I cannot check newer kernel releases