[ltp] Re: tp_smapi 0.18 and hdaps lockups

[Shem Multinymous]

Hi,

As worthy of a true Heisenbug, I witness a embedded controller hang a
few minutes after the announcement (despite several days of smooth
testing). I'm not sure what's going on yet, but be careful.

BTW, when embedded controller hangs you can still shut down cleanly
using a USB keyboard or USB mouse. And if you have suspend-to-disk
capabilities (swsusp or suspend2), a suspend cycle will reset the
embedded controller so you can continue working where you left off.

  Shem


On 4/1/06, Shem Multinymous <multinymous@gmail.com> wrote:
> Version 0.18 of the tp_smapi is out. This release improves stability
> and code structure. There are no changes in functionality.
>
> One major issue addressed is occasional embedded controller lockup
> (manifested as keyboard+mouse input death) triggered by tp_smapi's
> hdaps patch (i.e., "make HDAPS=3D1"). The fix was to avoid retrying
> failed sensor reads from inside the mousedev_poll timer handler. The
> fact that such retries confuse the embedded controller suggests that
> there's something horribly wrong with touching the embedded controller
> at all in that softirq context (maybe there's a race condition with
> ACPI events that talk to the same hardware through a different
> interface?).
>
> My conclusion is that vanilla hdaps is therefore also broken, but
> doesn't trigger the hang frequently because it spends so little time
> in softirq (no retries). The hdaps patch in tp_smapi now does the
> same, meaning it's equally un/broken.