Re: i8042 AUX port [serio1] suspend takes a second on Dell XPS 13 9360
From: Paul Menzel <hidden>
Date: 2018-02-15 08:26:41
Also in:
lkml
Possibly related (same subject, not in this thread)
- 2020-07-09 · Re: i8042 AUX port [serio1] suspend takes a second on Dell XPS 13 9360 · Paul Menzel <hidden>
Dear Mario, dear Dmitry, On 02/14/18 18:11, Mario.Limonciello@dell.com wrote:
quoted
-----Original Message----- From: Paul Menzel [mailto:pmenzel+linux-input@molgen.mpg.de] Sent: Wednesday, February 14, 2018 10:41 AM To: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; it+linux- input@molgen.mpg.de; Limonciello, Mario [off-list ref]; Thorsten Leemhuis [off-list ref] Subject: Re: i8042 AUX port [serio1] suspend takes a second on Dell XPS 13 9360
quoted
On 01/30/18 19:07, Dmitry Torokhov wrote:quoted
On Tue, Jan 30, 2018 at 09:52:45AM -0800, Dmitry Torokhov wrote:quoted
quoted
On Tue, Jan 30, 2018 at 06:36:34PM +0100, Paul Menzel wrote:quoted
quoted
quoted
I do not know, when it started, but with Linux 4.14-rc8 and 4.15, benchmarking suspend and resume time with `sleepgraph.py` [1][2], there is a regression, that i8042 AUX port [serio1] suspend takes a second on Dell XPS 13 9360 and TUXEDO Book 1406.It would be really helpful to know when the regression started.So the reason it takes longer is because the touchpad does not want to talk to us for some reason and we wait until commands time out: [ 94.591636] calling serio1+ @ 2299, parent: i8042 [ 94.794292] psmouse serio1: Failed to disable mouse on isa0060/serio1 [ 95.593303] call serio1+ returned 0 after 974280 usecs but it is not clear why it happens, I do not think we changed anything in that path for a while, so it might be some other change affecting things indirectly. I'm afraid you'll have to narrow the scope, and ideally bisect.Please keep in mind the XPS 9360 has a touchpad that can operate in I2C or PS2 modes. It's connected to both buses and with the right initialization sequence will come up in I2C mode. Assuming Paul M. has compiled and used hid-multitouch and i2c-hid the touchpad should be operating in I2C mode. When this happens I expect that the touchpad shouldn't be responding to PS2 commands. As a debugging tactic, you may consider to unload psmouse before suspend and still see the touchpad operational.
Thank you! Unloading *psmouse* with `sudo modprobe -r psmouse` indeed worked on the Dell XPS 13 9360, that means, the cursor is still functioning.
quoted
Thank you for your replies. First of all, it looks like *only* the Dell system is effected as I was unable to reproduce it on the TUXEDO Book 1406. I have to verify that by finding old log files.Does this other laptop you are drawing a comparison to also have a touchpad that can operate in multiple modes? To make an accurate comparison you should determine what mode it's in.
Yeah, removing the module *psmouse*, the cursor didn’t work there anymore. I was really sure, that I saw that problem once on the TUXEDO device too, but must have been mistaken, that’s why I corrected it. Sorry for the misunderstanding. So, why does *psmouse* get loaded on the Dell XPS 13 9360 since at least Linux 4.13? Or where the modules added causing the touchpad to operate in I2C mode, which causes PS2 to stop to work? Please find the full Linux kernel messages attached. Kind regards, Paul
Attachments
- smime.p7s [application/pkcs7-signature] 5174 bytes