Backport of psmouse suspend/shutdown cleanups
PATCH 1/1 Backport of psmouse suspend/shutdown cleanups
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...
Thanks,
Thomas
Quoted 48 lines · Thomas Renninger
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 patchedkernel->stillin bad state 4-Reboot with 2.6.20 patchedkernel->goingin good
state: battery reporting ok,
cpufreq working and go to full speed.
5-reboot with original Fedorakernel->stillin *good* state 6-reboot going in bad stateThe 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).
Quoted 9 lines
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_PMon) and powerpc (CONFIG_PMoff). 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.
Signature · 1 line
Dmitry
Quoted 59 lines · Dmitry Torokhov
Quoted 48 lines · Thomas Renninger
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 patchedkernel->stillin bad state 4-Reboot with 2.6.20 patchedkernel->goingin good
state: battery reporting ok,
cpufreq working and go to full speed.
5-reboot with original Fedorakernel->stillin *good* state 6-reboot going in bad stateThe 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).
Quoted 9 lines
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_PMon) and powerpc (CONFIG_PMoff). 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...
Quoted 7 lines
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
Quoted 7 lines · Thomas Renninger
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);
Quoted 8 lines
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 ;) ).
Signature · 1 line
Dmitry
Quoted 28 lines · Dmitry Torokhov
Quoted 7 lines · Thomas Renninger
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);Quoted 8 lines
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);
Quoted 8 lines
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 callpsmouse->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
Hi Thomas,
Quoted 8 lines · Thomas Renninger
Quoted 2 lines · Dmitry Torokhov
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_PPCvalue) down to wrong EC reads -> BIOS issue.
Quoted 8 lines
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.
...
Quoted 9 lines
FYI:
You might stumble again over the EC in future...
I saw reports where mouse jittering or similar bugs where fixed indrivers/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 inec.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 ;)
Signature · 1 line
Dmitry
Quoted 34 lines · Dmitry Torokhov
Hi Thomas,
Quoted 8 lines · Thomas Renninger
Quoted 2 lines · Dmitry Torokhov
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_PPCvalue) down to wrong EC reads -> BIOS issue.Quoted 8 lines
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.
...
Quoted 9 lines
FYI:
You might stumble again over the EC in future...
I saw reports where mouse jittering or similar bugs where fixed indrivers/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 inec.c, AML or EC BIOS code (in this case we seem to have the latter problem :) )...).
Quoted 3 lines
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
Hi!
I'm not input or stable maintainer, but...
Quoted 9 lines
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.
Well, I'd call that "work around hardware problems in broken HP laptops". There's HP BIOS bugzilla somewhere, perhaps we should fix it that way?
Quoted 6 lines
- 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...
Yes, it is quite nasty problem, but:
1) Fix is non-trivial (>100 lines, which violates -stable rule IIRC)
2) Fix is very disconnected from the problem. "Deinitialize mouse so that fans work after reboot". WTF?
3) AFAICT it is not a regression.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 4 lines · Pavel Machek
2) Fix is very disconnected from the problem. "Deinitialize mouse so that fans work after reboot". WTF?
ACPI spec implies that EC controller and PS/2 mouse/keyboards controller are one entity. So if mouse screws up "its" controller, it screws up EC as well, meaning fans will not work.
Regards,
Alex.
Quoted 7 lines · Alexey Starikovskiy
Quoted 3 lines · Pavel Machek
2) Fix is very disconnected from the problem. "Deinitialize mouse so that fans work after reboot". WTF?
ACPI spec implies that EC controller and PS/2 mouse/keyboards controller are one entity. So if mouse screws up "its" controller, it screws up EC as well, meaning fans will not work.
I would be *far* more worried about it screwing up the battery charging control loop. ECs often handle far more dangerous stuff than fans. I don't know if that's the case with the HP models, but it *is* the case for all ThinkPads for example: messing with the EC is messing with the stuff that controls the incendiary bomb in your lap.
If it can't be fixed, the machines should be blacklisted. Slowly killing the machine by shutting down its fans is bad enough to warrant that, anyway.
Signature · 4 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Hi Pavel,
Quoted 5 lines · Pavel Machek
Yes, it is quite nasty problem, but:
1) Fix is non-trivial (>100 lines, which violates -stable rule IIRC)
The fix itself is only 30 lines (counting empty lines and comments) which is not too bad.
Quoted 2 lines
2) Fix is very disconnected from the problem. "Deinitialize mouse so that fans work after reboot". WTF?
Can you imagine how I love this kind of bugs? ;)
Quoted 3 lines
3) AFAICT it is not a regression.
But it is very annoying for HP laptop owners.
Signature · 1 line
Dmitry
Hi!
Quoted 9 lines · Pavel Machek
Quoted 5 lines
Yes, it is quite nasty problem, but:
1) Fix is non-trivial (>100 lines, which violates -stable rule IIRC)
The fix itself is only 30 lines (counting empty lines and comments) which is not too bad.
Well, one of stable rules is
- It cannot be bigger than 100 lines, with context.
I guess it meets all the other criteria... I think this is for stable team to decide.
Quoted 4 lines
Quoted 2 lines
2) Fix is very disconnected from the problem. "Deinitialize mouse so that fans work after reboot". WTF?
Can you imagine how I love this kind of bugs? ;)
Yep. But maybe we should force HP to fix their broken machines? They even claim those machines are linux-certified (or suse-linux-certified or something).... Shame on them.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi,
Quoted 25 lines · Pavel Machek
Hi!
I'm not input or stable maintainer, but...
Quoted 9 lines
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.Well, I'd call that "work around hardware problems in broken HP laptops". There's HP BIOS bugzilla somewhere, perhaps we should fix it that way?
Quoted 6 lines
- 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...
Quoted 8 lines
Yes, it is quite nasty problem, but:
1) Fix is non-trivial (>100 lines, which violates -stable rule IIRC)
2) Fix is very disconnected from the problem. "Deinitialize mouse so that fans work after reboot". WTF?
3) AFAICT it is not a regression.
No, it isn't, but there are many people who have problems with suspending and even rebooting their laptops without this patch. Including me. ;-)
Greetings,
Rafael
Quoted 7 lines · Thomas Renninger
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.
After Dmitry and you can agree on them, can you send them to us at the stable@ address? Picking up patches from bugzilla isn't that easy at times, as there can be some confusion as to the proper patch and descriptions and sign-offs.
thanks,
greg k-h
Quoted 5 lines · Greg KH
Quoted 4 lines · Thomas Renninger
Hi,
I like to ask for inclusion into stable series for these.
Quoted 8 lines
Quoted 3 lines
The original patch from Dmitry can be found here:
http://bugzilla.kernel.org/show_bug.cgi?id=7689
comment #64, #65.After Dmitry and you can agree on them, can you send them to us at the stable@ address? Picking up patches from bugzilla isn't that easy at times, as there can be some confusion as to the proper patch and descriptions and sign-offs.
Oh nevermind, that's what I get for sending email before reading the whole thread...
But I'll wait until Dmitry agrees that both of these patches are needed.
thanks,
greg k-h