Re: [PATCH - 2.6.19 -0/1] Backport of psmouse suspend/shutdown cleanups
On Mon, 2007-02-26 at 09:34 -0500, Dmitry Torokhov wrote: Hi Thomas, On 2/26/07, Thomas Renninger [EMAIL PROTECTED] wrote: On Thu, 2007-02-22 at 10:02 -0500, Dmitry Torokhov wrote: Hope this makes sense (I must admit it makes little sense to me ;) ). Same for me at the beginning. I tracked two of the HP problems (wrong temperature, wrong _PPC value) down to wrong EC reads - BIOS issue. Someone (this is the guy who actually solved this) reported that unloading psmouse helps. When I saw this report confirmed by other people a .shutdown workaround was easy and got also confirmed working... And now it even makes a bit sense... There is a little microprocessor (Embedded Controller) pre-processing sensor or other data which gets accessed via ACPI. This one also access mouse/keyboard hardware (described a bit in ACPI specs). Yes, I am aware that KBC is usually emulated by EC chip nowadays, what does not really makes sense to me is how crazy the firmware is. ... FYI: You might stumble again over the EC in future... I saw reports where mouse jittering or similar bugs where fixed in drivers/acpi/ec.c If trying ec_intr=0 boot param, not loading any ACPI modules or the big hammer: acpi=off helps to solve mouse or keyboard problems it's probably Embedded Controller related (which might need a fix in ec.c, AML or EC BIOS code (in this case we seem to have the latter problem :) )...). Yep, seen that, except for AML workarounds. Do you have any examples? Although there seem to be lees complaints about mice jittering nowadays... Or maybe they simply got tired of complaining ;) I remember one mouse jittering issue got fixed by BIOS update, but I don't know whether they fixed the EC firmware, modified EC reads/writes in AML or whatever... Reducing thermal polling or ACPI (EC) activity in general could also help, therefore I expect workarounds in AML could be an option. I also remember some cleanups in drivers/acpi/ec.c (some time ago) that fixed up some machines... Thomas - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - 2.6.19 -0/1] Backport of psmouse suspend/shutdown cleanups
On Thu, 2007-02-22 at 10:02 -0500, Dmitry Torokhov wrote: On 2/22/07, Thomas Renninger [EMAIL PROTECTED] wrote: When adding the .shutdown workaround I went down and realized it must be this: psmouse_set_state(psmouse, PSMOUSE_CMD_MODE); or this: psmouse_set_state(psmouse, PSMOUSE_IGNORE); as I added the stuff in serio.c, I didn't realize that your psmouse patch is enough... So it's the first command that is needed on shutdown(PSMOUSE_CMD_MODE)? Dmitry: Could you explain me in a short sentence what this is doing, so that I can explain HP the problem again more detailed (without reading specs...). Actually there are 2 pieces that are needed for HP laptops: 1. They really get upset if mouse (integrated synaptics touchpad) is disabled when they about to reboot. The original code was simply doing psmouse_reset() which issues reset command to clear state of the device so it will be closer to the boot state. Hovewer (in accordance to the spec) after reset mice stay disabled, so we have to issue: ps2_command(psmouse-ps2dev, NULL, PSMOUSE_CMD_ENABLE); to keep HP laptops happy. Why it would make any difference is a mystery to me. 2. Synaptics touchpads do not get fully reset by 0xff, we need to explicitely enable gestures - again, HP only (there may be other boxes with this problem of course). So we call psmouse-cleanup(psmouse) to activate protocol-specific cleanup. Hope this makes sense (I must admit it makes little sense to me ;) ). Same for me at the beginning. I tracked two of the HP problems (wrong temperature, wrong _PPC value) down to wrong EC reads - BIOS issue. Someone (this is the guy who actually solved this) reported that unloading psmouse helps. When I saw this report confirmed by other people a .shutdown workaround was easy and got also confirmed working... And now it even makes a bit sense... There is a little microprocessor (Embedded Controller) pre-processing sensor or other data which gets accessed via ACPI. This one also access mouse/keyboard hardware (described a bit in ACPI specs). This post makes things a bit more clear: http://forum.thinkpads.com/viewtopic.php?t=20958 -- On a T43p (and probably several others) this is a Renesas H8S/2161BV, a 16-bit single-chip micro-controller located below the ExpressCard/CardBus slots. It has its own OS in 128 KB flash memory and since this OS is available in the EC updates, it is possible to analyze and modify it. Or we will at least be able to better understand how it can be configured since there doesn't seem to be much documentation available about the EC. -- FYI: You might stumble again over the EC in future... I saw reports where mouse jittering or similar bugs where fixed in drivers/acpi/ec.c If trying ec_intr=0 boot param, not loading any ACPI modules or the big hammer: acpi=off helps to solve mouse or keyboard problems it's probably Embedded Controller related (which might need a fix in ec.c, AML or EC BIOS code (in this case we seem to have the latter problem :) )...). I expect the EC accesses keyboard/mouse registers at late shutdown and gets confused if it's in wrong state. The EC seem to hold it's confused state in some kind of volatile memory as long as it can drain some power from battery (unplugging AC and battery for several minutes when machine is shut down was reported to fix the issue...) and does not get fully reinitialized on next boot. Thomas - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - 2.6.19 -0/1] Backport of psmouse suspend/shutdown cleanups
Hi Thomas, On 2/26/07, Thomas Renninger [EMAIL PROTECTED] wrote: On Thu, 2007-02-22 at 10:02 -0500, Dmitry Torokhov wrote: Hope this makes sense (I must admit it makes little sense to me ;) ). Same for me at the beginning. I tracked two of the HP problems (wrong temperature, wrong _PPC value) down to wrong EC reads - BIOS issue. Someone (this is the guy who actually solved this) reported that unloading psmouse helps. When I saw this report confirmed by other people a .shutdown workaround was easy and got also confirmed working... And now it even makes a bit sense... There is a little microprocessor (Embedded Controller) pre-processing sensor or other data which gets accessed via ACPI. This one also access mouse/keyboard hardware (described a bit in ACPI specs). Yes, I am aware that KBC is usually emulated by EC chip nowadays, what does not really makes sense to me is how crazy the firmware is. ... FYI: You might stumble again over the EC in future... I saw reports where mouse jittering or similar bugs where fixed in drivers/acpi/ec.c If trying ec_intr=0 boot param, not loading any ACPI modules or the big hammer: acpi=off helps to solve mouse or keyboard problems it's probably Embedded Controller related (which might need a fix in ec.c, AML or EC BIOS code (in this case we seem to have the latter problem :) )...). Yep, seen that, except for AML workarounds. Do you have any examples? Although there seem to be lees complaints about mice jittering nowadays... Or maybe they simply got tired of complaining ;) -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - 2.6.19 -0/1] Backport of psmouse suspend/shutdown cleanups
On Wed, 2007-02-21 at 12:26 -0500, Dmitry Torokhov wrote: On 2/21/07, Thomas Renninger [EMAIL PROTECTED] wrote: Hi, I like to ask for inclusion into stable series for these. The original patch from Dmitry can be found here: http://bugzilla.kernel.org/show_bug.cgi?id=7689 comment #64, #65. The reason is: - These patches fix a lot weird stuff on all recent HP nc/nx series laptop models. - The problem with the psmouse thing is, if you booted a broken kernel, rebooting a fixed one will still result in a broken system (things break (or get fixed) on shutdown and survive the reboot). Therefore the patch(es) should get into as much kernels as possible to avoid further confusions on bug reports... This test report shows the behavior nicely: http://bugzilla.kernel.org/show_bug.cgi?id=7689#c45: 1-Boot in good state with original kernel 2-Reboot going in bad state with original kernel 3-Reboot with 2.6.20 patched kernel-still in bad state 4-Reboot with 2.6.20 patched kernel-going in good state: battery reporting ok, cpufreq working and go to full speed. 5-reboot with original Fedora kernel-still in *good* state 6-reboot going in bad state The symptoms of breakages are (because of wrong EC reads/writes) very different, depending on the laptop model: - Cannot reach highest freq on (all?) HP Intel Dual core machines This is the only 100% reproducable bug I saw... - Shutdowns because of critical temperature (e.g. showing 1200 C) HP NX 9420 shutting down on huge, bogus thermal temperature values https://bugzilla.novell.com/show_bug.cgi?id=234475 - There are probably a lot other bug reports out there that will lead to this problem... These are patches against the plain 2.6.19 kernel (not stable .X, I hope nothing changed at these specific files..., if there changed something I can resubmit). As we are using these in SLE10 SP1, I did the backports back to 2.6.16 and will send more if I get your ok for that. Dmitry (or others), can you please review. I had to fiddle a bit on each kernel version. I did a compile test on x86_64 (CONFIG_PM on) and powerpc (CONFIG_PM off). And I verified 2.6.20 (original) and 2.6.16 working with s2disk and s2ram. Still I could have done a little typo/mistake somewhere... Hi Thomas, The patches look good, however I believe that only psmouse patch is enough to fix the issues you referring to in your mail (I don't have a box that exibits these symptoms so I can't verify). The second patch, while useful, should not be included in stable series unless the first patch alone does not work. When adding the .shutdown workaround I went down and realized it must be this: psmouse_set_state(psmouse, PSMOUSE_CMD_MODE); or this: psmouse_set_state(psmouse, PSMOUSE_IGNORE); as I added the stuff in serio.c, I didn't realize that your psmouse patch is enough... So it's the first command that is needed on shutdown(PSMOUSE_CMD_MODE)? Dmitry: Could you explain me in a short sentence what this is doing, so that I can explain HP the problem again more detailed (without reading specs...). I run into the problem that Ingo Molnar's patch (Don't call _PPC on startup) hid the problem, later calls to _PPC seemed to return zero again (I wonder if recent ThinkPads also suffer from this or whether this is unrelated)... Some dozen reboots later I can confirm that: a) _PPC reports 0 on startup (1 otherwise) with this patch b) AC state works now (found that by luck, 100% reproducable, when booted with AC (un)plugged, the AC state is stuck to (off)on and will never change again - gets also fixed with this patch) c) mouse (and a + b) still work after s2ram (could only test this without X) and s2disk. Problems (a + b) were reproducable in the mentioned way: - reboot a broken kernel and the next booted kernel will be broken - reboot a fixed kernel and the next booted kernel will work I tested this on a 2.6.16 kernel. I expect that they don't fully reinitialize their EC after reboot (unplugging AC and battery for some minutes, is also a reported workaround for that problem), just a guess... Maybe this even fixes the endless loop some HPs run into - I didn't test this, don't know how to slip into it. I will send patch to stable separated now ... Thanks, Thomas - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - 2.6.19 -0/1] Backport of psmouse suspend/shutdown cleanups
On 2/22/07, Thomas Renninger [EMAIL PROTECTED] wrote: When adding the .shutdown workaround I went down and realized it must be this: psmouse_set_state(psmouse, PSMOUSE_CMD_MODE); or this: psmouse_set_state(psmouse, PSMOUSE_IGNORE); as I added the stuff in serio.c, I didn't realize that your psmouse patch is enough... So it's the first command that is needed on shutdown(PSMOUSE_CMD_MODE)? Dmitry: Could you explain me in a short sentence what this is doing, so that I can explain HP the problem again more detailed (without reading specs...). Actually there are 2 pieces that are needed for HP laptops: 1. They really get upset if mouse (integrated synaptics touchpad) is disabled when they about to reboot. The original code was simply doing psmouse_reset() which issues reset command to clear state of the device so it will be closer to the boot state. Hovewer (in accordance to the spec) after reset mice stay disabled, so we have to issue: ps2_command(psmouse-ps2dev, NULL, PSMOUSE_CMD_ENABLE); to keep HP laptops happy. Why it would make any difference is a mystery to me. 2. Synaptics touchpads do not get fully reset by 0xff, we need to explicitely enable gestures - again, HP only (there may be other boxes with this problem of course). So we call psmouse-cleanup(psmouse) to activate protocol-specific cleanup. Hope this makes sense (I must admit it makes little sense to me ;) ). -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
