linux-kernel - Re: Keyboard lost after exit s2idle on ASUS UX433FN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0gKfyB7=5ZGj9uXejoBjkuf2snsKwYJM2Ar1_Vg8A8SCg@mail.gmail.com>
Date:   Thu, 16 Aug 2018 09:26:41 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Chris Chiu <chiu@...lessm.com>
Cc:     Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        Len Brown <lenb@...nel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Upstreaming Team <linux@...lessm.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Pavel Machek <pavel@....cz>
Subject: Re: Keyboard lost after exit s2idle on ASUS UX433FN

On Thu, Aug 16, 2018 at 4:45 AM Chris Chiu <chiu@...lessm.com> wrote:
>
> Hi,
>     We recently hit a weird problem on the ASUS laptop UX433FN with
> latest Intel Core i7-8565U CPU on kernel 4.18. The keyboard stops
> functioning after exit s2idle. It stops firing interrupts after resume
> on any keypress. We thought it should be something wrong with i8042
> driver or even atkbd driver, so we tried to skip the suspend/resume
> path of i8042 and input devices but no luck.
>
>     Then we tried to hack the s2idle code to fail right before it goes
> into the idle state to find out which code really cause the keyboard
> broken. It comes with an interesting finding that if it aborts s2idle
> before cpuidle_resume() in s2idle_enter(), the keyboard is fine. If it
> aborts after cpuidle_resume, then the keyboard down. At least it
> proves that even with dpm_noirq_begin() and
> dpm_noirq_suspend_devices() executed, the keyboard is still alive.
> There should be something wrong with the cpuidle.
>
>     Going deeper into intel_idle_s2idle() which is invoked by
> cpuidle_enter_s2idle(), we found that the keyboard interrupt will no
> longer function after mwait_idle_with_hints() which just simply
> executing intel monitor and mwait instructions. So I don't know what
> should be the next step I can take. Can anyone give some pieces of
> advice?

It may indicate that the deepest C-states used by s2idle simply don't
work correctly on the affected system.

To verify this, you can try to disable the deepest C-states via sysfs
using the "disable" attribute under
/sys/devices/system/cpu/cpuX/cpuidle/stateX/

Is s2idle the default suspend method on that system?  If so, have you
checked whether or not suspend-to-RAM works too?

Thanks,
Rafael