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

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

> Date: Tue, 20 Feb 2024 19:00:33 +0100
> From: Stephan Marwedel <projetos%jucara.org@localhost>
> 
> 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 message.

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, 

> >> Even The attempt to disable the device ihidev0 via the entry
> >> userconf=disable ihidev* in /boot.cfg does not result correct
> >> suspend to RAM.
> > Can you describe what happens when you try in this case?
> 
> 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=3; 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:
> 
> geekbox# sleep 1; drvctl -S dwiic1; sleep 1; drvctl -Q dwiic1
> 
> drvctl: DRVSUSPENDDEV: Device busy
> 
> 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.)