Messages in this thread | | | From | "Rafael J. Wysocki" <> | Date | Thu, 16 Aug 2018 09:26:41 +0200 | Subject | Re: Keyboard lost after exit s2idle on ASUS UX433FN |
| |
On Thu, Aug 16, 2018 at 4:45 AM Chris Chiu <chiu@endlessm.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
| |