[PATCH - 2.6.19 -0/2] Backport of psmouse suspend/shutdown cleanups

[PATCH - 2.6.19 -0/2] Backport of psmouse suspend/shutdown cleanups

[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 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

Re: [PATCH - 2.6.19 -0/2] Backport of psmouse suspend/shutdown cleanups

[Dmitry Torokhov]

On 2/21/07, Thomas Renninger <trenn@suse.de> 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.

-- 
Dmitry

Re: [PATCH - 2.6.19 -0/2] Backport of psmouse suspend/shutdown cleanups

[Pavel Machek]

Hi!

I'm not input or stable maintainer, but...

> 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?

>  - 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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH - 2.6.19 -0/2] Backport of psmouse suspend/shutdown cleanups

[Alexey Starikovskiy]

Pavel Machek wrote:
> 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.

Re: [PATCH - 2.6.19 -0/2] Backport of psmouse suspend/shutdown cleanups

[Rafael J. Wysocki]

Hi,

On Wednesday, 21 February 2007 20:52, Pavel Machek wrote:
> Hi!
> 
> I'm not input or stable maintainer, but...
> 
> > 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?
> 
> >  - 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.

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

Re: [PATCH - 2.6.19 -0/2] Backport of psmouse suspend/shutdown cleanups

[Dmitry Torokhov]

Hi Pavel,

On 2/21/07, Pavel Machek <pavel@ucw.cz> wrote:
>
> 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.

> 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? ;)

>
> 3) AFAICT it is not a regression.
>

But it is very annoying for HP laptop owners.

-- 
Dmitry

Re: [PATCH - 2.6.19 -0/2] Backport of psmouse suspend/shutdown cleanups

[Pavel Machek]

Hi!

> On 2/21/07, Pavel Machek <pavel@ucw.cz> wrote:
> >
> >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.

> >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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH - 2.6.19 -0/2] Backport of psmouse suspend/shutdown cleanups

[Henrique de Moraes Holschuh]

On Wed, 21 Feb 2007, Alexey Starikovskiy wrote:
> Pavel Machek wrote:
> >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.

-- 
  "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

Re: [stable] [PATCH - 2.6.19 -0/2] Backport of psmouse suspend/shutdown cleanups

[Greg KH]

On Wed, Feb 21, 2007 at 06:08:05PM +0100, Thomas Renninger 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.

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

Re: [stable] [PATCH - 2.6.19 -0/2] Backport of psmouse suspend/shutdown cleanups

[Greg KH]

On Wed, Feb 21, 2007 at 04:21:14PM -0800, Greg KH wrote:
> On Wed, Feb 21, 2007 at 06:08:05PM +0100, Thomas Renninger 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.
> 
> 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

Re: [PATCH - 2.6.19 -0/1] Backport of psmouse suspend/shutdown cleanups

[Thomas Renninger]

On Wed, 2007-02-21 at 12:26 -0500, Dmitry Torokhov wrote:
> On 2/21/07, Thomas Renninger <trenn@suse.de> 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

Re: [PATCH - 2.6.19 -0/1] Backport of psmouse suspend/shutdown cleanups

[Dmitry Torokhov]

On 2/22/07, Thomas Renninger <trenn@suse.de> 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

Re: [PATCH - 2.6.19 -0/1] Backport of psmouse suspend/shutdown cleanups

[Thomas Renninger]

On Thu, 2007-02-22 at 10:02 -0500, Dmitry Torokhov wrote:
> On 2/22/07, Thomas Renninger <trenn@suse.de> 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

Re: [PATCH - 2.6.19 -0/1] Backport of psmouse suspend/shutdown cleanups

[Dmitry Torokhov]

Hi Thomas,

On 2/26/07, Thomas Renninger <trenn@suse.de> 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

Re: [PATCH - 2.6.19 -0/1] Backport of psmouse suspend/shutdown cleanups

[Thomas Renninger]

On Mon, 2007-02-26 at 09:34 -0500, Dmitry Torokhov wrote:
> Hi Thomas,
> 
> On 2/26/07, Thomas Renninger <trenn@suse.de> 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