Lid Close Action Issue on ThinkPad

T

TempleBSD

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.

Code: 
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
Code: 
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
Code: 
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"
Code: 
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
 
This is a very long shot and probably not gonna solve your problem but in my notes I have this:
Code: 
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.
 
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!
 
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.
Click to expand...

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?!
 
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.
 
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.
 
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.
Click to expand...
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.
 
grahamperrin said:
forums.freebsd.org

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 forums.freebsd.org

There's an unanswered question …
Click to expand...
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.
 
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:
  1. sleeps in response to acpiconf -s 3
  2. does nothing (makes no attempt to wake) when you close the lid
  3. wakes normally when you open the lid
  4. goes dark when you close the lid whilst doing nothing to sleep the computer
  5. 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.
Click to expand...

𣀓– 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?
 
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.
 
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
Click to expand...

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.
 
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.
 
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...
 
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.
 
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.
Click to expand...
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.
 
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.
 
thinman said:
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
Click to expand...
Just an update that my T460 is now suspending and resuming correctly under 13.2-BETA2. Thanks, dev team!
 
Thank you for the update, I am on 13.1, so I can expect my T470s to be "fixed" when the 13.2 is released. I have found that attaching power/charger (power on) BEFORE closing the lid will prevent freezing.
 
This gives me great hope for 13.2 because I have this exact issue with my ThinkPad p50. Closing the lid and re-opening causes a black screen of death, only remedy is holding down the power button. This is pretty much the only thing giving a suboptimal user experience. I'll try to remember to post my results here when I upgrade.
 
I must be lucky. I've just put a new install of 13.1-RELEASE on my X201. Once I set the sysctl to S3, suspend and resume on lid close and open works perfectly. I've installed kde5 plasma as the desktop, interestingly I noticed under the "power management" configuration, it has no "suspend" option in the dropdown for lid close. Meh. Once I set the sysctl, it works well. Makes a loud beep. Only fault is it sets the screen brightness to maximum on resume. A single press of Fn+End restores brightness to normal.
 
You must log in or register to reply here.
Back
Top