https://bugzilla.novell.com/show_bug.cgi?id=179702 trenn@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|HP nx9420 ACPI BIOS Bug, |Latest HP laptops do not reach max cpufreq, |_PPC always returns 1 |might not update thermal,battery info or could |instead of 0 |get "bad firmware state" that even survives | |shutdown. Caused by probably wrong/unfinished | |ACPI BIOS/EC read/writes ------- Comment #103 from trenn@novell.com 2007-01-10 05:17 MST ------- I collected all related HP problems in this bug for now, 10.1 and 10.2. If you describe problems pls drop a short note whether it's 10.1 or 10.2, even the problem exists on both Things should go better for 10.2 with this kernel: ftp.suse.com/pub/projects/kernel/kotd/i386/HEAD/kernel-default.i586.rpm and for 10.1/SLED10 people with this kernel: ftp.suse.com/pub/projects/kernel/kotd/sle10-sp-i386/SLES10_SP1_BRANCH/kernel-default.i586.rpm Would be great if people could try those out. Be aware that there are several problems: a) There still might be issues with ACPI after suspend to disk (concerning fans) There have been several patches suggested, I still want to wait for the final one. In the 10.1/SLED10-SP1 kernel some infrastructure already has been added to be able to apply specific ACPI suspend patches then. b) There is also the phenomenon that some HPs (mostly Pentium Dual Cores?) that when firmware comes into some kind of bad state (you should see this if: cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq does not show the highest supported frequency). If this is the case, booting windows or removing battery and AC (all power) for some minutes should help. Also compiling psmouse as a moudule and rmmodding it before shutddown helps (not sure whether this is enough to bring it back to the "good state". I wonder whether those kernels work fine as soon as the machine is in "good state". I don't/can't go for the psmouse compiled as module workaround which only hides a bug anyway. Thanks to Alessandro, there is another bug opened here: http://bugzilla.kernel.org/show_bug.cgi?id=7689 and Intel people who have much more man power are working on it. It would be great if these kernels could be tested and reported back what works (updating AC/battery state should work now) and what still does not work (still switching into "bad state"?, still AC/battery problems?). Play a bit with the ACPI things, unplugging AC, closing lid, reading out hardware info through /proc/acpi/thermal_zone/*/* and /proc/acpi/battery/*/* and watch a bit the system whether everything works stable for longer time. If you experience much better behaviour, this patch will go in. I am still very busy, came back from vacation some days ago and got 4 new bugs only yesterday. Still I consider this one the most important and will go on with "time intensive" debugging after I at least answered on bugs and emails... Related bugzilla.kernel.org bugs: Thanks to Alessandro (he fall out of CCs?): http://bugzilla.kernel.org/show_bug.cgi?id=7689 Describes the "firmware falls into bad state" problem http://bugzilla.kernel.org/show_bug.cgi?id=5534 Describes the problem of too many notify/gpes/.. happening and processing of ACPI methods get stuck/cancled because all are running in one kernel thread. The latest patch from comment #180 is in above kernels and should make things better (could be that this also cause the "bad state", try to evaluate this...). http://bugzilla.kernel.org/show_bug.cgi?id=7122 Possible broken fans after suspend to disk. This should not be that hard to resolve, but I like above problems should be clarified first. Maybe it's related and those "workaround" patches not needed or can be written nicer. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.