Bug 217462

Summary: ThinkPad L540: suspend not working (deep / S3 / standby, regression Linux 4.19 -> 6.1)
Product: Drivers Reporter: kolAflash (kolAflash)
Component: Input DevicesAssignee: drivers_input-devices
Status: NEW ---    
Severity: normal CC: bagasdotme, jwrdegoede
Priority: P3    
Hardware: Intel   
OS: Linux   
Kernel Version: Subsystem:
Regression: No Bisected commit-id:
Attachments: ThinkPad L540 failed suspend deep dmesg output - Linux-6.1.27 from Debian-12

Description kolAflash 2023-05-19 00:42:21 UTC
Created attachment 304290 [details]
ThinkPad L540 failed suspend deep dmesg output - Linux-6.1.27 from Debian-12

Since updating from Linux-4.19 to Linux-6.1.27 suspend deep is not working anymore.
(a.k.a. S3, standby or suspend to ram)

Notebook: ThinkPad L540 20AU-S00N00
OS: Debian-12 "Bookworm" (was Debian-10 "Buster" before)
Kernel: Linux-6.1.27 from Debian-12 (was Linux-4.19 from Debian-10 before)

Can I provide any other helpful information?
Do you need a test with a vanilla Linux-6.1 kernel?
Should I perform any other tests or maybe try out boot parameters?

Full dmesg output attached.
Excerpt:
rmi4_f01 rmi4-00.fn01: Failed to write sleep mode: -6.
rmi4_f01 rmi4-00.fn01: Suspend failed with code -6.
rmi4_physical rmi4-00: Failed to suspend functions: -6
rmi4_smbus 0-002c: Failed to suspend device: -6
rmi4_smbus 0-002c: PM: dpm_run_callback(): rmi_smb_suspend+0x0/0x40 [rmi_smbus] returns -6
rmi4_smbus 0-002c: PM: failed to suspend async: error -6
sd 4:0:0:0: [sda] Synchronizing SCSI cache
sd 4:0:0:0: [sda] Stopping disk
PM: Some devices failed to suspend, or early wake event detected
sd 4:0:0:0: [sda] Starting disk
OOM killer enabled.
Restarting tasks ... 
rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts!
psmouse: probe of serio2 failed with error -1



Maybe related:

5.17-rc regression: X1 Carbon touchpad not resumed
https://lore.kernel.org/lkml/YgF%2F0QGFN4SppLKg@shikoro/T/
Comment 1 Bagas Sanjaya 2023-05-19 13:20:50 UTC
(In reply to kolAflash from comment #0)
> Can I provide any other helpful information?
> Do you need a test with a vanilla Linux-6.1 kernel?
> Should I perform any other tests or maybe try out boot parameters?
> 

Try bisection between v4.19 and v6.1.
Comment 2 Hans de Goede 2023-05-19 13:47:55 UTC
This seems to be an issue with using the touchpad in its native RMI mode rather then leaving it in its default / BIOS-compatible PS/2 mode.

As a workaround for now try passing "psmouse.synaptics_intertouch=0" on the kernel commandline, this should restore the old 4.19 kernel behavior of simply using the touchpad in PS/2 mode.

That will hopefully at least get things working for you and then we can take some more time to debug this properly and come up with a proper fix.
Comment 3 kolAflash 2023-05-19 22:14:46 UTC
I was able to use https://snapshot.debian.org/package/linux/ to bisect the problem down to Linux-5.17-rc3, which is the first bad kernel I could find.
https://snapshot.debian.org/package/linux/5.17~rc3-1~exp1/#linux-image-5.17.0-rc3-amd64-unsigned_5.17:7e:rc3-1:7e:exp1

Linux-5.16.18 works fine.
https://snapshot.debian.org/package/linux/5.16.18-1/#linux-image-5.16.0-6-amd64-unsigned_5.16.18-1

I don't think I'll find time to bisect the problem on commit basis.
(I don't have permanent access to the notebook)



Kernel parameter
  psmouse.synaptics_intertouch=0
successfully workarounds the problem.
Thanks a lot for that!

Another workaround is
  rmmod rmi_smbus psmouse
before entering suspend (deep).

Another observation:
The first suspend usually works. But the second then won't work.
Comment 4 Bagas Sanjaya 2023-05-20 02:06:00 UTC
On 5/20/23 05:14, bugzilla-daemon@kernel.org wrote:
> I don't think I'll find time to bisect the problem on commit basis.
> (I don't have permanent access to the notebook)
> 

Then see Documentation/admin-guide/bug-bisect.rst for how to do bisection
with git.
Comment 5 kolAflash 2023-05-20 11:07:46 UTC
Thanks for the hint. That won't be the problem and I've done some git bisects on the Linux kernel before.
https://www.kernel.org/doc/Documentation/admin-guide/bug-bisect.rst
It's just that I don't have access to that ThinkPad L540 anymore. Maybe in two weeks again.



But I had another look into the linked regression report by Hugh Dickins.
  5.17-rc regression: X1 Carbon touchpad not resumed
  https://lore.kernel.org/lkml/YgF%2F0QGFN4SppLKg@shikoro/T/
I'll just do a little conclusion:


That report also has it's bad commit between 5.16 and 5.17-rc3.
> Bisection led to 172d931910e1db800f4e71e8ed92281b6f8c6ee2
> ("i2c: enable async suspend/resume on i2c client devices")
> and reverting that fixes it for me.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=172d931910e1db800f4e71e8ed92281b6f8c6ee2

Jarkko Nikula reported he also could not enter standby on his Lenovo ThinkPad X1 Carbon 8th. (looks like my problem)
For rmi4 and psmouse his dmesg errors look quite the same as mine. But there's one additionally error:
  i801_smbus 0000:00:1f.4: No response
https://lore.kernel.org/lkml/6f1103af-595c-ed0a-b946-97a9331ed148@linux.intel.com/

Hugh and Jarkko also successfully tested a patch by Dmitry Torokhov.
https://lore.kernel.org/lkml/YgHTYrODoo2ou49J@google.com/
But that patch was a little onesided, because it simply disabled async suspend for rmi4.
So finally Dmitry Torokhov wrote this commit, which fixed it for Hugh and Jarkko.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7b1f781f2d2460693f43d5f764198df558e3494b
Also linked as resolution in the regression tracker.
https://linux-regtracking.leemhuis.info/regzbot/regression/89456fcd-a113-4c82-4b10-a9bcaefac68f@google.com/

QUESTION (to myself):
IF IT IS the same issue, why did this not fix it for my ThinkPad L540?
(just checked, it's still in Linux-6.1.27)

There's also an older report by Hugh. Maybe I'll have a look into that later.
  5.11-rc device reordering breaks ThinkPad rmi4 suspend
  https://lore.kernel.org/linux-pm/alpine.LSU.2.11.2101102010200.25762@eggly.anvils/