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: <CAJZ5v0i6PXg1rTjBTZy3tGVihmb84qZpqzmHrwSdACWZ+SOgYg@mail.gmail.com>
Date:   Thu, 16 Aug 2018 10:54:15 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Chris Chiu <chiu@...lessm.com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        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 10:18 AM Chris Chiu <chiu@...lessm.com> wrote:
>
> On Thu, Aug 16, 2018 at 3:26 PM, Rafael J. Wysocki <rafael@...nel.org> wrote:
> > 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/
> >
> Thanks for the great help. I can have the keyboard work after s2idle with
> the following command
>
> echo 1 > /sys/devices/system/cpu/cpuX/cpuidle/state8/disable
>
> cpuX, X can be 0 to 7 on this CPU.
> And only state8 disable would work, it fails on state 0~7 disabled.

Well, if you disable one of states 0-7 alone, it will still attempt to
use state8. :-)

It generally uses the deepest one enabled.

> There're 9 (0-8) states on the cpuidle of this machine. However, I have another
> laptop with the same CPU Intel Core i7-8565U which only have 4(0-3) states
> under the same '/sys/devices/system/cpu/cpuX/cpuidle/' entry. Sorry that I
> don't have enough background knowledge about cpuidle. I thought the #C
> state should be depend on CPU, but why the same i7-8565 has different
> number of C-states?

What is there in /sys/devices/system/cpu/cpuidle/current_driver on
each of these systems?

>  And for this case, should I just disable C-8 state or there
> should be a generic fix with it?

No, it just doesn't work specifically on your system, unfortunately,
so you need to disable state8 manually, at least for the time being.
If all UX433FNs turn out to be affected, we may consider adding a
quirk for them, but for now we just don't know.

Do the "name" and "desc" sysfs files of state8 on the affected system
contain "C10" and "MWAIT 0x60", respectively?

To make a more persistent record of this issue, you can file a bug at
bugzilla.kernel.org against cpuidle and put all of the relevant
information into it.  It is possible that some special magic is needed
to make the deepest idle state safe on this system and it may be hard
to find out, but at least it is good to know that this happens.

> > Is s2idle the default suspend method on that system?  If so, have you
> > checked whether or not suspend-to-RAM works too?
> >
>
> Yes, it's default s2idle. If I do 'echo mem > /sys/power/state', the keyboard
> would still fail.

OK

What's there in /sys/power/mem_sleep ?

Thanks,
Rafael