Re: [regression, bisected] Keyboard not responding after resuming from suspend/hibernate

From: Numan DemirdÃÄen
Date: Tue Dec 18 2018 - 02:26:14 EST


Sun, 2 Dec 2018 23:28:09 +0100 tarihinde
Pavel Machek <pavel@xxxxxx> yazdÄ:

>On Fri 2018-11-30 15:44:55, Numan DemirdÃÄen wrote:
>> Sun, 28 Oct 2018 22:06:54 +0300 tarihinde
>> Numan DemirdÃÄen <if.gnu.linux@xxxxxxxxx> yazdÄ:
>>
>> >Thu, 25 Oct 2018 09:49:03 +0200 tarihinde
>> >Pavel Machek <pavel@xxxxxx> yazdÄ:
>> >
>> >> Hi!
>> >>
>> >> Here's problem bisected down to:
>> >>
>> >> commit 9d659ae14b545c4296e812c70493bfdc999b5c1c
>> >> Author: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
>> >> Date: Tue Aug 23 14:40:16 2016 +0200
>> >>
>> >> locking/mutex: Add lock handoff to avoid starvation
>> >>
>> >> Implement lock handoff to avoid lock starvation.
>> >>
>> >> Numan, I assume revert of that patch on the 4.18 kernel still
>> >> makes it work?
>> >>
>> >
>> >Unfortunately, I could not revert
>> >9d659ae14b545c4296e812c70493bfdc999b5c1c on kernels from 4.18.16 to
>> >4.10-rc1 because there were too much conflicts, which I could not
>> >solve as an "average Joe". I tried
>> >a3ea3d9b865c2a8f7fe455c7fa26db4b6fd066e3 which is parent of
>> >9d659ae14b545c4296e812c70493bfdc999b5c1c and succeeded to compile
>> >kernel.
>> >
>> >git checkout a3ea3d9b865c2a8f7fe455c7fa26db4b6fd066e3
>> >
>> >Then, I compiled kernel and rebooted with it. I tried a couples of
>> >times suspending and resuming, all of the time keyboard worked as
>> >expected.
>> >
>>
>> With this one line patch from Takashi Iwai, keyboard is working as
>> expected after resuming from suspend/hibernate.
>>
>> --- a/kernel/locking/mutex.c
>> +++ b/kernel/locking/mutex.c
>> @@ -59,7 +59,7 @@ EXPORT_SYMBOL(__mutex_init);
>> * Bit2 indicates handoff has been done and we're waiting for
>> pickup. */
>> #define MUTEX_FLAG_WAITERS 0x01
>> -#define MUTEX_FLAG_HANDOFF 0x02
>> +#define MUTEX_FLAG_HANDOFF 0x00
>> #define MUTEX_FLAG_PICKUP 0x04
>>
>> #define MUTEX_FLAGS 0x07
>>
>>
>> Thanks in advance and regards,
>
>Ok. So it is a regression, and you can ask Linus to apply this
>.. but... that's kind of heavy solution. Peter, do you have any other
>ideas?
>
> Pavel

Hi,

I did not mention the one line patch from Takashi Iwai as a means of fix
but as a hint. Sorry for misunderstanding.

Here is a another hint from another user:

I found that passing the options i8042.reset=1 i8042.dumbkbd=1 i8042.direct=1
results in the keyboard functioning after resume. However, there is a
long delay before the keyboard or mouse will respond to input on the
lock screen.[1]

[1] https://bugzilla.kernel.org/show_bug.cgi?id=195471#c39

--
Numan DemirdÃÄen

Attachment: pgpCtdr2P72na.pgp
Description: Dijital OpenPGP imzası