[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAB4CAwfms8_zJ=xB5wJ0Sgr6gu9-mFnqwEz2cUR-sOHdEV5zqQ@mail.gmail.com>
Date: Thu, 16 Aug 2018 10:45:12 +0800
From: Chris Chiu <chiu@...lessm.com>
To: jacob.jun.pan@...ux.intel.com, Len Brown <lenb@...nel.org>,
linux-pm@...r.kernel.org,
Linux Kernel <linux-kernel@...r.kernel.org>,
Linux Upstreaming Team <linux@...lessm.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>, pavel@....cz
Subject: Keyboard lost after exit s2idle on ASUS UX433FN
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?
Chris
Powered by blists - more mailing lists