Hi Paul,
On Tue, Jan 30, 2018 at 06:36:34PM +0100, Paul Menzel wrote:
> Dear Linux folks,
>
>
> 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.
Thanks.
--
Dmitry
Dear Dmitry,
On 01/30/18 19:07, Dmitry Torokhov wrote:
> On Tue, Jan 30, 2018 at 09:52:45AM -0800, Dmitry Torokhov wrote:
>> On Tue, Jan 30, 2018 at 06:36:34PM +0100, Paul Menzel wrote:
>>> 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.
Thank you for looking into this. Just to note, that it worked with Linux
4.14.1 from Ubuntu 17.10, so it’s probably something in 4.15. Bisecting
will take a bit, as the FTRACE stuff broke in Linux 4.15-rc1 and was
only fixed in 4.15-rc9. Hopefully, it’s just one commit I need to
backport. I’ll get back to you hopefully at the end of the week.
Kind regards,
Paul
On Tue, Jan 30, 2018 at 09:52:45AM -0800, Dmitry Torokhov wrote:
> Hi Paul,
>
> On Tue, Jan 30, 2018 at 06:36:34PM +0100, Paul Menzel wrote:
> > Dear Linux folks,
> >
> >
> > 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.
Thanks.
--
Dmitry
Dear Dmitry,
Am 30.01.2018 um 19:39 schrieb Paul Menzel:
> On 01/30/18 19:07, Dmitry Torokhov wrote:
>> On Tue, Jan 30, 2018 at 09:52:45AM -0800, Dmitry Torokhov wrote:
>>> On Tue, Jan 30, 2018 at 06:36:34PM +0100, Paul Menzel wrote:
>>>> 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.
>
> Thank you for looking into this. Just to note, that it worked with Linux
> 4.14.1 from Ubuntu 17.10, so it’s probably something in 4.15. Bisecting
> will take a bit, as the FTRACE stuff broke in Linux 4.15-rc1 and was
> only fixed in 4.15-rc9. Hopefully, it’s just one commit I need to
> backport. I’ll get back to you hopefully at the end of the week.
Unfortunately, I am unable to reproduce it currently. Also not with the
original Linux kernel versions I tried. I’ll report back, when I see it
the next time.
Kind regards,
Paul
> -----Original Message-----
> From: Paul Menzel [mailto:[email protected]]
> Sent: Wednesday, February 14, 2018 10:41 AM
> To: Dmitry Torokhov <[email protected]>
> Cc: [email protected]; [email protected]; it+linux-
> [email protected]; Limonciello, Mario <[email protected]>;
> Thorsten Leemhuis <[email protected]>
> Subject: Re: i8042 AUX port [serio1] suspend takes a second on Dell XPS 13 9360
>
> Dear Dmitry,
>
>
> On 01/30/18 19:07, Dmitry Torokhov wrote:
> > On Tue, Jan 30, 2018 at 09:52:45AM -0800, Dmitry Torokhov wrote:
>
> >> On Tue, Jan 30, 2018 at 06:36:34PM +0100, Paul Menzel wrote:
>
> >>> 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 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.
>
> Starting the bisect between 4.14 and 4.15-rc1 it turns out, that the
> problem is also reproducible with 4.14, and I remembered wrong. Looking
> more into it, I could also reproduce it with Linux 4.13.0-32-generic
> from Ubuntu 16.04 (Hardware Enablement Stack). But my old logs do not
> show the problem. As the UEFI firmware was updated to version 2.5.0 in
> the meantime, it could also be related to that.
>
> So it turns out, with 4.16-rc1 I see this delay/failure message only
> during the first suspend. Suspending a second time, I do not see the
> message.
>
> Any hints how to debug this further are much appreciated. Could it be
> related to the embedded controller?
>
>
> Kind regards,
>
> Paul
Dear Dmitry,
On 01/30/18 19:07, Dmitry Torokhov wrote:
> On Tue, Jan 30, 2018 at 09:52:45AM -0800, Dmitry Torokhov wrote:
>> On Tue, Jan 30, 2018 at 06:36:34PM +0100, Paul Menzel wrote:
>>> 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.
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.
Starting the bisect between 4.14 and 4.15-rc1 it turns out, that the
problem is also reproducible with 4.14, and I remembered wrong. Looking
more into it, I could also reproduce it with Linux 4.13.0-32-generic
from Ubuntu 16.04 (Hardware Enablement Stack). But my old logs do not
show the problem. As the UEFI firmware was updated to version 2.5.0 in
the meantime, it could also be related to that.
So it turns out, with 4.16-rc1 I see this delay/failure message only
during the first suspend. Suspending a second time, I do not see the
message.
Any hints how to debug this further are much appreciated. Could it be
related to the embedded controller?
Kind regards,
Paul
Dear Mario, dear Dmitry,
On 02/14/18 18:11, [email protected] wrote:
>
>
>> -----Original Message-----
>> From: Paul Menzel [mailto:[email protected]]
>> Sent: Wednesday, February 14, 2018 10:41 AM
>> To: Dmitry Torokhov <[email protected]>
>> Cc: [email protected]; [email protected]; it+linux-
>> [email protected]; Limonciello, Mario <[email protected]>;
>> Thorsten Leemhuis <[email protected]>
>> Subject: Re: i8042 AUX port [serio1] suspend takes a second on Dell XPS 13 9360
>> On 01/30/18 19:07, Dmitry Torokhov wrote:
>>> On Tue, Jan 30, 2018 at 09:52:45AM -0800, Dmitry Torokhov wrote:
>>
>>>> On Tue, Jan 30, 2018 at 06:36:34PM +0100, Paul Menzel wrote:
>>
>>>>> 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.
>> 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
Dear Mario, dear Dmitry,
On 02/15/18 09:26, Paul Menzel wrote:
> On 02/14/18 18:11, [email protected] wrote:
>>
>>
>>> -----Original Message-----
>>> From: Paul Menzel [mailto:[email protected]]
>>> Sent: Wednesday, February 14, 2018 10:41 AM
>>> To: Dmitry Torokhov <[email protected]>
>>> Cc: [email protected]; [email protected]; it+linux-
>>> [email protected]; Limonciello, Mario <[email protected]>;
>>> Thorsten Leemhuis <[email protected]>
>>> Subject: Re: i8042 AUX port [serio1] suspend takes a second on Dell
>>> XPS 13 9360
>
>>> On 01/30/18 19:07, Dmitry Torokhov wrote:
>>>> On Tue, Jan 30, 2018 at 09:52:45AM -0800, Dmitry Torokhov wrote:
>>>
>>>>> On Tue, Jan 30, 2018 at 06:36:34PM +0100, Paul Menzel wrote:
>>>
>>>>>> 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.
But to clarify, the TUXEDO device can be booted with
`psmouse.synaptics_intertouch=1`, and the cursor still works. (I am
going to send a patch.) So the EC(?) on the TUXEDO device seems to
support PS2 and I2C modes, and doesn’t show the same problems as the
Dell device.
>>> 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.
Starting the system with `psmouse.synaptics_intertouch=1`, the one
second delay is still reproducible.
Kind regards,
Paul
> -----Original Message-----
> From: Paul Menzel [mailto:[email protected]]
> Sent: Thursday, February 15, 2018 2:26 AM
> To: Limonciello, Mario <[email protected]>; Dmitry Torokhov
> <[email protected]>
> Cc: [email protected]; [email protected]; it+linux-
> [email protected]; [email protected]
> Subject: Re: i8042 AUX port [serio1] suspend takes a second on Dell XPS 13 9360
>
> Dear Mario, dear Dmitry,
>
>
> On 02/14/18 18:11, [email protected] wrote:
> >
> >
> >> -----Original Message-----
> >> From: Paul Menzel [mailto:[email protected]]
> >> Sent: Wednesday, February 14, 2018 10:41 AM
> >> To: Dmitry Torokhov <[email protected]>
> >> Cc: [email protected]; [email protected]; it+linux-
> >> [email protected]; Limonciello, Mario <[email protected]>;
> >> Thorsten Leemhuis <[email protected]>
> >> Subject: Re: i8042 AUX port [serio1] suspend takes a second on Dell XPS 13 9360
>
> >> On 01/30/18 19:07, Dmitry Torokhov wrote:
> >>> On Tue, Jan 30, 2018 at 09:52:45AM -0800, Dmitry Torokhov wrote:
> >>
> >>>> On Tue, Jan 30, 2018 at 06:36:34PM +0100, Paul Menzel wrote:
> >>
> >>>>> 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.
>
> >> 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?
>
It was like that before this laptop even launched to the market.
It's been like that since way before 4.13. I want to say maybe 3.13ish is when
I2C mode would come up instead.
The order of events goes something like this:
1) Touchpad is initially in PS2 mode
2) psmouse loads
3) It reports that it may be supportable by a different bus
4) The sequence to switch to I2C mode happens
5) i2c-hid and hid-multitouch get loaded
6) psmouse is no longer functional
Dmitry is there a way that we can connect the two events? When i2c-hid finds
the touchpad notify psmouse to unload or at least stop trying to access it to prevent
the problem Paul is talking about with suspend?
Dear Mario,
Thank you for your reply.
Am 15.02.2018 um 16:22 schrieb [email protected]:
>> -----Original Message-----
>> From: Paul Menzel [mailto:[email protected]]
>> Sent: Thursday, February 15, 2018 2:26 AM
>> To: Limonciello, Mario <[email protected]>; Dmitry Torokhov
>> <[email protected]>
>> Cc: [email protected]; [email protected]; it+linux-
>> [email protected]; [email protected]
>> Subject: Re: i8042 AUX port [serio1] suspend takes a second on Dell XPS 13 9360
>> On 02/14/18 18:11, [email protected] wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Paul Menzel [mailto:[email protected]]
>>>> Sent: Wednesday, February 14, 2018 10:41 AM
>>>> To: Dmitry Torokhov <[email protected]>
>>>> Cc: [email protected]; [email protected]; it+linux-
>>>> [email protected]; Limonciello, Mario <[email protected]>;
>>>> Thorsten Leemhuis <[email protected]>
>>>> Subject: Re: i8042 AUX port [serio1] suspend takes a second on Dell XPS 13 9360
>>
>>>> On 01/30/18 19:07, Dmitry Torokhov wrote:
>>>>> On Tue, Jan 30, 2018 at 09:52:45AM -0800, Dmitry Torokhov wrote:
>>>>
>>>>>> On Tue, Jan 30, 2018 at 06:36:34PM +0100, Paul Menzel wrote:
>>>>
>>>>>>> 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.
>>
>>>> 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?
>
> It was like that before this laptop even launched to the market.
> It's been like that since way before 4.13. I want to say maybe 3.13ish is when
> I2C mode would come up instead.
Indeed, analyzing the behavior on the current 8th generation Dell XPS 13
93*7*0 with the shipped Ubuntu with Linux 4.4.0-112-generic, the same
delay is visible.
> The order of events goes something like this:
> 1) Touchpad is initially in PS2 mode
> 2) psmouse loads
> 3) It reports that it may be supportable by a different bus
> 4) The sequence to switch to I2C mode happens
> 5) i2c-hid and hid-multitouch get loaded
> 6) psmouse is no longer functional
>
> Dmitry is there a way that we can connect the two events? When i2c-hid finds
> the touchpad notify psmouse to unload or at least stop trying to access it to prevent
> the problem Paul is talking about with suspend?
That would be great. Please tell me, if there is a bug tracker, where
this issue should reported to to track it.
Kind regards,
Paul
Dear Dmitry, dear Mario,
Am 21.02.18 um 10:22 schrieb Paul Menzel:
> Am 15.02.2018 um 16:22 schrieb [email protected]:
>>> -----Original Message-----
>>> From: Paul Menzel [mailto:[email protected]]
>>> Sent: Thursday, February 15, 2018 2:26 AM
>>> On 02/14/18 18:11, [email protected] wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Paul Menzel [mailto:[email protected]]
>>>>> Sent: Wednesday, February 14, 2018 10:41 AM
>>>
>>>>> On 01/30/18 19:07, Dmitry Torokhov wrote:
>>>>>> On Tue, Jan 30, 2018 at 09:52:45AM -0800, Dmitry Torokhov wrote:
>>>>>
>>>>>>> On Tue, Jan 30, 2018 at 06:36:34PM +0100, Paul Menzel wrote:
>>>>>
>>>>>>>> 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.
>>>
>>>>> 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?
>>
>> It was like that before this laptop even launched to the market.
>> It's been like that since way before 4.13. I want to say maybe
>> 3.13ish is when
>> I2C mode would come up instead.
>
> Indeed, analyzing the behavior on the current 8th generation Dell XPS 13
> 93*7*0 with the shipped Ubuntu with Linux 4.4.0-112-generic, the same
> delay is visible.
>
>> The order of events goes something like this:
>> 1) Touchpad is initially in PS2 mode
>> 2) psmouse loads
>> 3) It reports that it may be supportable by a different bus
>> 4) The sequence to switch to I2C mode happens
>> 5) i2c-hid and hid-multitouch get loaded
>> 6) psmouse is no longer functional
>>
>> Dmitry is there a way that we can connect the two events? When
>> i2c-hid finds
>> the touchpad notify psmouse to unload or at least stop trying to
>> access it to prevent
>> the problem Paul is talking about with suspend?
>
> That would be great. Please tell me, if there is a bug tracker, where
> this issue should reported to to track it.
The issue is still present with Linux 5.8-rc4. Does Mario’s plan sound
feasible?
Kind regards,
Paul