[ltp] Hotkeys not working after suspend/resume to disk (X220t)

[Milan Plžík]

On Sat, Aug 13, 2011 at 5:48 PM, Henrique de Moraes Holschuh
<hmh@hmh.eng.br> wrote:
> On Sat, 13 Aug 2011, Milan Plžík wrote:
>>   I'm tring to configure X220 tablet to use suspend to disk, howeve=
r
>> it looks like after having successfully resumed, thinkpad hotkeys
>> don't work. I tried to rmmod/modprobe thinkpad-acpi module, but with
>> no luck. Interestingly, looks like suspend/resume to RAM fixes this
>> issue -- hotkeys I tested started to work correctly again. I was not
>> able to make further progress with debugging, but maybe some part of
>> hotkeys_resume (drivers/platform/x86/thinkpad_acpi.c) disables hotkeys
>> when resuming from disk; but I have not tested it.If there is anything
>> I can do/test, I'm ready for any suggestions.
>
> It could be a driver bug, yes.  But in that case, unloading it and
> loading it back would fix the issue.
>
> If it is indeed a problem in the driver, it will likely be caused by
> something _new_ we should be doing to enable/disable something in the
> X220 firmware that does not appreciate a suspend to disk.

  My idea was more like that firmware gets into state which driver
 doesn't expect (but that's just another speculation), but as mentioned
 below, apparently the situation is not as simple as I originally
 thought.

>
> I suggest you try switch suspend to disk to use ACPI S4 instead of S5.
> That might cure the problem.  *KEEP TRACK OF POWER USAGE* when you d=
o
> so, you might find out that something in the thinkpad was not powered
> off properly by S4.

  I tried also S4, but it did not make any vsible difference;
 unfortunately, I don't have any power measuring equipment, so I can't
 do much testing here. And also, NB, I use tuxonice, not regular
 in-kernel suspend. Looks like vanilla kernel works correctly; patched
 (tuxonice, BFS scheduler, tuxonice) misbehaves.

>
> IMO, suspend-to-disk is always a bad idea in Linux.  The way it relo=
ads
> the kernel in x86/x86_64 is not even close to safe re. firmware
> interaction.

  I have not been that far to study mechanisms used, but from my
 knowledge, yes, it possibly features some kind of black magic.

>
> It is far safer to use only suspend-to-ram for always-available
> situations, and power off in all others.

  My motivation is to drain battery as least as possible (and I'm
 accustomed to plug thinkpad out of the socket after suspending it),
 and I prefer having few more battery-minutes spared to few seconds
 spared on laptop resuming from RAM.

>
> In any case, please report the issue in bugzilla.kernel.org.  We wan=
t to
> fix it.  Also, please check whether a firmware update solves the iss=
ue.
> If it does, PLEASE tell be about it and I will make sure to have the
> driver complain to the user when it finds the problematic version of the
> firmware.

  Looks like first I need to find difference between
 http://aur.archlinux.org/packages.php?ID=50956 and generic kernel in
 arch linux. If I'll find any issue that is related to mainline kernel,
 I'll file the proper bug report.

>
> --
>  "One disk to rule them all, One disk to find them. One disk to brin=
g
>  them all and in the darkness grind them. In the Land of Redmond
>  where the shadows lie." -- The Silicon Valley Tarot
>  Henrique Holschuh
>