Re: port-amd64/57930: ACPI suspend problems on Thinkpad X270

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

The following reply was made to PR port-amd64/57930; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Stephan Marwedel <projetos%jucara.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, port-amd64-maintainer%NetBSD.org@localhost,
	gnats-admin%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: port-amd64/57930: ACPI suspend problems on Thinkpad X270
Date: Tue, 20 Feb 2024 19:05:12 +0000

 > Date: Tue, 20 Feb 2024 19:00:33 +0100
 > From: Stephan Marwedel <projetos%jucara.org@localhost>
 >=20
 > On 2/12/24 21:01, Taylor R Campbell wrote:
 > > Can you share the full dmesg?
 > >
 > > Can you share the output of `acpidump -dt'?  (It will be large, so if
 > > you want to upload it somewhere we can download instead of sending it
 > > through mail to gnats, that's fine.
 > The full dmesg and the output of acpidump -dt are attached to this messag=
 e.
 
 Great, thanks!
 
 By the way, is there any chance you can get a serial console on this
 machine?  That might make it easier to get kernel output especially
 early in the resume path before graphics has come back.  For example,=20
 
 > >> Even The attempt to disable the device ihidev0 via the entry
 > >> userconf=3Ddisable ihidev* in /boot.cfg does not result correct
 > >> suspend to RAM.
 > > Can you describe what happens when you try in this case?
 >=20
 > Unfortunately, after wakeup, keyboard, trackpad and trackpoint are dead
 > and could only be recovered by a reboot. Only the screen resumed
 > correctly from sleep.
 
 Can you log in remotely with ssh when that happens?
 
 Or, can you make the system send dmesg to another machine on the
 network?
 
 other$ nc -N -l 12345 >dmesg.txt
 
 broken# nc -h                     # get nc(1) in RAM
 broken# sysctl -w hw.acpi.sleep.state=3D3; dmesg | nc -N other.local 12345
 
 > When trying to identify the device causing the problem using the
 > commands about, I ended up with getting errors on dwiic1:
 >=20
 > geekbox# sleep 1; drvctl -S dwiic1; sleep 1; drvctl -Q dwiic1
 >=20
 > drvctl: DRVSUSPENDDEV: Device busy
 >=20
 > drvctl: DRVRESUMEDEV: Device busy
 
 Just to clarify: Is this when you booted normally, or when you booted
 with ihidev disabled in userconf?
 
 My guess is that this is when you booted normally, not with ihidev
 disabled in userconf.  If so, I suggest you try the same drvctl thing,
 but with ihidev disabled in userconf.
 
 (When ihidev(4) is not disabled in userconf, it will prevent dwiic(4)
 from suspend/resume with exactly the symptom you described.  This is
 also a bug, really, but it doesn't matter much; the other bugs --
 system resume failure, ihidev(4) attach failure -- are more
 important.)
 
 > This is the only device causing a problem. I am not quite sure what
 > device this is. Maybe the trackpad connected through I2C?
 
 Well, you have some kind of human interface device attached through
 i2c!
 
 dwiic(4) is the driver for DesignWare I2C controllers.
 
 ihidev(4) is the driver for I2C human interface devices, just like
 uhidev(4) is the driver for USB human interface devices -- almost the
 same protocol, just over different transport media.
 
 But you also appear to have PC keyboard/mouse:
 
 [     1.022376] pckbc1 at acpi0 (KBD, LEN0071) (kbd port): io 0x60,0x64 irq=
  1
 [     1.022376] pckbc2 at acpi0 (MOU, LEN2046) (aux port): irq 12
 ...
 [     1.022376] pckbd0 at pckbc1 (kbd slot)
 [     1.022376] pckbc1: using irq 1 for kbd slot
 [     1.022376] wskbd0 at pckbd0: console keyboard
 [     1.022376] pms0 at pckbc1 (aux slot)
 [     1.022376] pms0: Synaptics touchpad version 8.2
 
 Do your physical keyboard and trackpad work, before suspend?  If so,
 ihidev(4) is not either of those.
 
 If these are actually your physical keyboard and trackpad, perhaps the
 ihidev(4) is a touchscreen or something?
 
 > All other devices worked fine when trying to individually suspend and
 > resume them. Even suspending and resuming the USB worked well.
 
 Great!  So this might be narrowed down a bit.  (It is still possible,
 of course, that there is something else awr, and the ihidev(4) bug is
 a red hering -- but we should still try to fix that.)