# Lid Close Action Issue on ThinkPad



## TempleBSD (Dec 27, 2021)

I have a fresh install of 13.0-Release on a ThinkPad T460. Suspend and resume works as expected from X or Terminal environments using acpiconf -s 3. The default install should have no lid-close action as far as I know, however when I - without setting hw.acpi.lid_switch-state - close my lid, the screen turns of. Reopening it, turns on the monitor but leaves a frozen system. Any setting to hw.acpi.lid_switch_state is ignored and neither the rc.suspend script, nor my personal script called from devd on system:ACPI,subsystem:Lid get called.



Spoiler: output of kldstat





```
Id Refs Address                Size Name
 1   93 0xffffffff80200000  1009b20 kernel
 2    1 0xffffffff8120a000     40b0 coretemp.ko
 3    1 0xffffffff81210000     a2d0 acpi_video.ko
 4    1 0xffffffff8121b000   67fe38 zfs.ko
 5    2 0xffffffff8189b000     4478 acl_nfs4.ko
 6    1 0xffffffff818a0000     3e90 cc_htcp.ko
 7    1 0xffffffff818a4000     9160 acpi_ibm.ko
 8    1 0xffffffff818ae000     adc0 cryptodev.ko
 9    1 0xffffffff818b9000    1ab70 geom_eli.ko
10    1 0xffffffff822f9000     3284 linsysfs.ko
11    4 0xffffffff822fd000     db70 linux_common.ko
12    1 0xffffffff8230b000     639c linprocfs.ko
13    1 0xffffffff82312000     3378 acpi_wmi.ko
14    1 0xffffffff82316000     3250 ichsmb.ko
15    1 0xffffffff8231a000     2180 smbus.ko
16    1 0xffffffff8231d000    17310 if_iwm.ko
17    1 0xffffffff82335000     2110 pchtherm.ko
18    1 0xffffffff82400000   207d78 iwm8000Cfw.ko
19    1 0xffffffff82338000    388f8 linux.ko
20    1 0xffffffff82371000    30ac8 linux64.ko
21    1 0xffffffff823a2000     2260 pty.ko
22    1 0xffffffff823a5000     3530 fdescfs.ko
23    1 0xffffffff82608000   158458 i915kms.ko
24    1 0xffffffff82761000    7f548 drm.ko
25    2 0xffffffff823a9000     cbc8 linuxkpi_gplv2.ko
26    2 0xffffffff823b6000     2328 lindebugfs.ko
```






Spoiler: cat /etc/sysctl.conf





```
security.bsd.see_other_uids=0
security.bsd.see_other_gids=0
security.bsd.see_jail_proc=0
security.bsd.unprivileged_read_msgbuf=0
security.bsd.unprivileged_proc_debug=0
kern.randompid=1
vfs.zfs.min_auto_ashift=12

kern.evdev.rcpt_mask=6
vfs.read_max=128
kern.sched.preempt_thresh=224
hw.syscons.bell=0
kern.vt.enable_bell=0
kern.ipc.shm_allow_removed=1
# hw.acpi.lid_switch_state=s3

hw.psm.trackpoint.sensitivity=96
hw.psm.trackpoint.upper_plateau=128
hw.psm.synaptics.touchpad_off=0

net.inet.tcp.cc.algorithm=htcp
net.inet.tcp.cc.htcp.adaptive_backoff=1
net.inet.tcp.cc.htcp.rtt_scaling=1
net.inet.tcp.rfc6675_pipe=1
net.inet.tcp.syncookies=0
net.inet.tcp.nolocaltimewait=1
kern.ipc.soacceptqueue=1024
kern.ipc.maxsockbuf=8388605
net.inet.tcp.sendspace=262144
net.inet.tcp.recvspace=262144
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
net.inet.tcp.sendbuf_inc=32768
net.inet.tcp.recvbuf_inc=65536
net.local.stream.sendspace=16384
net.local.stream.recvspace=16384
net.inet.raw.maxdgram=16384
net.inet.raw.recvspace=16384
net.inet.tcp.abc_l_var=44
net.inet.tcp.initcwnd_segments=44
net.inet.tcp.mssdflt=1448
net.inet.tcp.minmss=524
net.inet.ip.intr_queue_maxlen=2048
net.route.netisr_maxqlen=2048
```






Spoiler: cat /etc/rc.conf





```
clear_tmp_enable="YES"
dumpdev="NO"
syslogd_flags="-ss"
sendmail_enable="NONE"

hostname="ThinkPad"

keymap="de.kbd"
moused_enable="YES"
moused_flags="-VH"

wlans_iwm0="wlan0"
ifconfig_wlan0="WPA DHCP powersave"
background_dhclient="YES"

dbus_enable="YES"
zfs_enable="YES"
linux_enable="YES"
openntpd_enable="YES"

# power saving
powerd_enable="YES"
powerd_flags="-a hiadaptive -b adaptive"
performance_cx_lowest="Cmax"
economy_cx_lowest="Cmax"

kldlist="i915kms acpi_ibm acpi_video"
```






Spoiler: cat /boot/loader.conf





```
aesni_load="YES"
geom_eli_load="YES"
cryptodev_load="YES"
zfs_load="YES"
cc_htcp_load="YES"
coretemp_load="YES"
acpi_ibm_load="YES"
acpi_video_load="YES"

kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
security.bsd.allow_destructive_dtrace=0
kern.vty=vt

hw.pci.do_power_nodriver="3"
hw.snd.latency="7"
hint.p4tcc.0.disabled="1"
hint.acpi_throttle.0.disabled="1"
hint.ahcich.0.pm_level="5"

drm.i915.enable_rc6="7"
drm.i915.semaphores="1"
compat.linuxkpi.enable_dc="2"
compat.linuxkpi.enable_fbc="1"
drm.i915.intel_iommu_enabled="1"

hw.psm.trackpoint_support="1"
hw.psm.synaptics_support="1"
hw.inet.tcp.socreceive_stream="1"
net.link.ifqmaxlen="2048"
```




I have no idea what is causing this unexpected behavior. Without the lid action set, I would assume that nothing should happen on lid close. That something somewhere triggers the observed behaviour is preventing the intended S3 suspension.

If anyone can help with figuring out where this comes from, I would be very happy. If more info is needed, feel free to request. Thanks


----------



## jbo (Dec 27, 2021)

This is a very long shot and probably not gonna solve your problem but in my notes I have this:

```
hw.acpi.lid_switch_state=S3
```
I use a capital S.

The only reason I am providing this answer is because you stated that `hw.acpi.lid_switch_state` has no effect at all.
I'd gladly check the docs to see whether this is by any chance case sensitive (I doubt it) but I have to go boil some potatoes now.


----------



## TempleBSD (Dec 27, 2021)

Thank you for the hint! The sysctl service and utility both do sanity checking on the input. Therefore invalid input is discarded immediately. The lowercase s is legal and I have also seen others write it that way. Personal preference probably. Enjoy those potatoes of yours!


----------



## George (Dec 27, 2021)

Hey,
Do you have bios settings for acpi or the lid switch?



> The default install should have no lid-close action as far as I know, however when I - without setting hw.acpi.lid_switch-state - close my lid, the screen turns of.



The lid switch driver evokes (calls) an event handler, and merely informs you (the userland) via devd.
The event handlers actions are controlled by the sysctl hw.acpi.lid_switch_state. It's default action is to do nothing though ("NONE").

Looking at acpi_lid.c, it seems like evdev gets involved as well?!


----------



## TempleBSD (Dec 28, 2021)

The T460 does not have any settings regarding acpi or lid switch - I went through them to validate that. Some blog post mentioned that an unsupported TPM can prevent suspend from working, so I disabled mine. Suspend however is working wonderfully. Its just that triggering it on the lid close event does not work because there is some other action taking place which freezes the Laptop.


----------



## grahamperrin@ (Dec 28, 2021)

System freeze on lid close only, FreeBSD-13
					

I have a Thinpad T470s, upgraded from 12.2 to 13.  When I close the lid, the system freezes solid, as in full lock up. Need to force restart with power button.  In my sysctl.conf I have (worked in 12.2) # sleep hw.acpi.supported_sleep_state=S3 hw.acpi.lid_switch_state=S3   If I run acpiconf -s 3...




					forums.freebsd.org
				




There's an unanswered question …


----------



## jbo (Dec 29, 2021)

As luck would have it, I just tried this on my new ThinkPad Carbon X1 Gen9 with stable/13 and I the same symptoms: The system is able to enter S3 but completely locks up on wake-up. Needs a hard-reset.


----------



## TempleBSD (Jan 1, 2022)

Thats interesting


jbodenmann said:


> As luck would have it, I just tried this on my new ThinkPad Carbon X1 Gen9 with stable/13 and I the same symptoms: The system is able to enter S3 but completely locks up on wake-up. Needs a hard-reset.


For me, the symptoms differ. Mine does not go to sleep properly on lidclose but does resume properly on lidopen. This can be tested by acpiconf -s 3 and then closing the lid - reopening it will trigger a wakeup which works like a charm. Its when I close it in non-suspended state that it gets frozen.


----------



## TempleBSD (Jan 1, 2022)

grahamperrin said:


> System freeze on lid close only, FreeBSD-13
> 
> 
> I have a Thinpad T470s, upgraded from 12.2 to 13.  When I close the lid, the system freezes solid, as in full lock up. Need to force restart with power button.  In my sysctl.conf I have (worked in 12.2) # sleep hw.acpi.supported_sleep_state=S3 hw.acpi.lid_switch_state=S3   If I run acpiconf -s 3...
> ...


Power button has no manual configuration but works like a normal power button. If i press it for a bit, the system shuts off. I have however mapped acpiconf -s 3 to a shortcut to make it easier to live with the broken lid close.


----------



## grahamperrin@ (Jan 2, 2022)

I can't visualise the hardware. Does a ThinkPad T460 have LEDs or whatever to help tell when it's attempting to wake from sleep?

If so, is there truth in the alternative summary below?

Your computer:

sleeps in response to `acpiconf -s 3`
does nothing (makes no attempt to wake) when you close the lid
wakes normally when you open the lid
goes dark when you close the lid _whilst doing nothing to sleep the computer_
behaves abnormally when you open the lid
– if so, please describe the step five abnormality in detail.


For a moment, back to the opening post:



TempleBSD said:


> turns on the monitor but leaves a frozen system.



𣀓– there, _frozen_ was ambiguous.

Was the screen drawn but static, i.e. no change to a visible on-screen clock after a period of more than one minute?

Was the display entirely blank, dark grey, as if the backlight was on?


----------



## TempleBSD (Jan 2, 2022)

Ok, here we go:

First Situation:
1. put system to sleep using acpiconf -s 3
2. close lid (does nothing, computer already sleeping from step 1) - may be left out
3. open lid / press power button if 2 was skipped
result: computer goes to sleep and wakes up perfectly

Second Situation:
1. close lid
2. display can be seen quickly turning off (without the usual info from tty about the suspend)
3. open lid
result: display turns on quickly and displays last state but system is completely locked up (mouse/keyboard do nothing, clock in my statusbar does not update and so on) requiring a reset (long power button press)

Additionally: the T460 does have means to indicate active/going to sleep/sleeping via LEDs on the inside and the outside of the case. These are static on when active, quickly blink when changing states and slowly fade-blink when sleeping. Off means off of course.


----------



## TempleBSD (Jan 2, 2022)

However, after playing with some tunables, the suspend functionality on lid close now works. I have no idea what could have made it work and will investigate further tomorrow.


----------



## grahamperrin@ (Jan 3, 2022)

At least for the purpose of future diagnosis, it may help to configure FreeBSD to *shut down* in response to a press on the power button.

Then:



TempleBSD said:


> 1. close lid
> 2. display can be seen quickly turning off (without the usual info from tty about the suspend)
> 3. open lid
> result: display turns on quickly and displays last state but system is completely locked up



If – with any combination of tunables – you can reproduce that one symptom with those three steps, a normal (short) press on the power button should be enough to tell whether the operating system is truly, completely frozen. 


I have my FreeBSD 14.0-CURRENT configured to behave in this way with an HP EliteBook 8570p. Until recently, I occasionally encountered a bug that caused everything to seem frozen – no response to integral keyboard or touchpad input, no response to USB keyboard or trackball input. In fact, not _entirely_ frozen: the OS responded normally to the power button, which, on this hardware, is physically separate from the integral keyboard.


----------



## fernandel (Jan 7, 2022)

I have Thinkpad T495 and I use `acpiconf -s 3` and it works but with sysctl.switch... doesn't work. Nothing hapenned. But with `acpiconf -s 3` when going off I closed the lid and when I open it start normal.


----------



## icodeforyou (Jun 16, 2022)

I can say that this issue does not appear to be limited to Thinkpads. I am running an Ideapad 520S-14IKB and the acpi suspend on lid close is extremely unreliable to say the least. The laptop has a tendency to not wake up again and just reinitialize completely. It appears to be far better via `acpiconf -s 3`. 

Now I was wondering how to debug or at least work around this. Is there any possibility or triggering a shell script on lid close instead of just going to sleep? Then that would be a nice workaround...


----------



## blackhaz (Jun 20, 2022)

Thinkpad X1 Yoga 1st Gen here. Since the upgrade from 12 to 13.1, the laptop sometimes does not wake up. I am suspending by zzz which, according to the man page, looks up the configured ACPI suspend state (S3 by default) and initiates acpiconf -s. The only option is to force shutdown on a sleeping system and power back on, which is, of course, not ideal.


----------



## icodeforyou (Jun 21, 2022)

I should add to this thread: my lid_close issue on the Ideapad 520S went away once I found the solution to another, apparently related issue in this thread: https://forums.freebsd.org/threads/...ume-on-lenovo-ideapad-520s.85543/#post-572045

The solution was to install the newest Intel UHD drivers from ports here, and to set `debug.acpi.max_threads="1"` in `/boot/loader.conf`. Not quite sure which one of the two things did the real work though...


----------



## Deleted member 70435 (Jun 22, 2022)

TempleBSD said:


> kldlist="i915kms acpi_ibm acpi_vi


you need to make changes here.


----------



## jbo (Jun 22, 2022)

Vadim Alexandrov said:


> Das ist falsch.


As much as I can appreciate some proper raw German, please see forum rule #9: https://forums.freebsd.org/threads/freebsd-forums-rules.38922

</party_pooper>


----------



## thinman (Nov 2, 2022)

TempleBSD said:


> However, after playing with some tunables, the suspend functionality on lid close now works. I have no idea what could have made it work and will investigate further tomorrow.


I'm wondering if you ever nailed down the fix for this. I've just come into a T460 and am having the exact same issue running 13.1R-p3. Suspend works fine from 'zzz' or through xfce but freezes hard on lid close.


----------



## BobSlacker (Nov 2, 2022)

I have a T430 and when I use any login manager I have this problem. FreeBSD get stuck on wake up.
But with `startx` I can resume without problems.


----------

