Solved ThinkPad E16 Gen 3: reboot and poweroff hang with USB-C connected

Hi,

I am experiencing intermittent reboot and poweroff hangs on my Lenovo ThinkPad E16 Gen 3. My tests now point to an attached USB-C cable as the trigger.

Environment:

  • Lenovo ThinkPad E16 Gen 3, machine type 21TF
  • BIOS: R2YET22W (1.11), dated February 26, 2026
  • Embedded Controller firmware: 1.11
  • FreeBSD 15.1-RELEASE-p3, GENERIC amd64
  • Kernel: releng/15.1-n283611-88e7371d9dc2
  • Intel Core 7 240H with Intel integrated graphics
  • drm-latest-kmod-6.9.1501000_1
  • SwayFX 0.6
When I run doas reboot or doas poweroff with USB-C connected, the shutdown appears to proceed, but the laptop sometimes fails to restart or switch off. The screen goes off, while the power-button and Esc LEDs remain lit. The laptop stays warm and can drain its battery. I have to hold the power button to turn it off.

This happens both with a USB-C monitor that supplies power and with only a USB-C charging cable connected. Therefore, an external display is not required to trigger the problem. Reboot and poweroff have worked in my tests without USB-C connected.

I initially suspected SwayFX. However, exiting it with swaymsg exit and then shutting down from the text console did not reliably prevent the hang.

The kernel log contains these ACPI errors:

sh:
ACPI Error: No handler for Region [ECSI] [EmbeddedControl]
ACPI Error: Region EmbeddedControl (ID=3) has no handler
ACPI Error: Aborting method \_SB.UBTC.ECRD due to previous error (AE_NOT_EXIST)
ACPI Error: Aborting method \_SB.UBTC.NTFY due to previous error (AE_NOT_EXIST)
ACPI Error: Aborting method \_SB.PC00.LPCB.EC._Q4F due to previous error (AE_NOT_EXIST)
acpi_ec0: evaluation of query method _Q4F failed: AE_NOT_EXIST
acpi_tz0: _CRT value is absurd, ignored (-273.1C)


These messages were captured during normal operation after a reboot, rather than at the exact point where shutdown hangs.

My graphics settings in /boot/loader.conf are:

sh:
compat.linuxkpi.i915_enable_dc="2"
compat.linuxkpi.i915_enable_fbc="1"
compat.linuxkpi.i915_enable_psr="1"
I tested all three set to 0, but experienced a complete freeze during use and restored the original values. I do not know whether that freeze is related to the shutdown issue. No new crashdump was saved.

Is this a known ACPI or USB-C power-management issue on this model? What diagnostics would help determine where reboot or poweroff gets stuck?

I can provide the full dmesg, firmware information and configuration files.

Thanks.
 
Might need to set this:
Code:
% sysctl -d hw.usb.no_shutdown_wait
hw.usb.no_shutdown_wait: No USB device waiting at system shutdown.
 
SirDice
sh:
❯ sysctl -d hw.usb.no_shutdown_wait
hw.usb.no_shutdown_wait: No USB device waiting at system shutdown.


❯ doas sysctl hw.usb.no_shutdown_wait=1
hw.usb.no_shutdown_wait: 0 -> 1


A test will follow....
 
I tested hw.usb.no_shutdown_wait=1, but it had no effect.


My tests consistently show that both reboot and poweroff hang when USB-C remains connected. With USB-C disconnected, they work. This also happens with a charger alone, so an external monitor is not required to trigger the issue.


What would be the next diagnostic step to identify where shutdown gets stuck?
 
I’ve done some reading on a similar issue with Lenovo laptops. There are three key points: 1. Updating the EFI. 2. OS kernel issues (updating the kernel). 3. A hardware reset of the EC chip. The funny thing is, the support website even provides a procedure for resetting the chip. This all dates back to the 2022–2026 period and manifests differently across various laptop models.
https://forums.lenovo.com/t5/Lenovo...-to-Reset-the-Embedded-Controller/m-p/5286519
Look for something like this:
https://support.lenovo.com/ua/en/do...e-for-windows-and-linux-thinkstation-p7-intel

A quick look at the issues reveals that problems involving this core chip occur on Manjaro Linux, Linux Mint, and Arch Linux.
Code:
Thanks for seth 's replay
i updated the kernel, 6.1.7.arch1-1 or 5.15.89-1-lts works fine
This clearly demonstrates that the EC chip plays a fundamental role in managing many processes.
https://chromeos.dev/en/posts/embedded-controller
 
Not the same hardware, but I see the same ACPI error messages on a ThinkPad E15 AMD Gen3 when plugging out [1] and plugging in the USB-C charging cable.

With the USB-C power cord attached, shutdown -r now or Ctrl+Alt+Delete reboots the system, and poweroff(8) or hardware power button pressed, powers off the machine as expected, no "hangs".

In your case, I would check the 16.0-CURRENT branch if the issue occurs there as well. No need to install, booting a mini-memstick or memstick image [2] from a USB pendrive will suffice. If the issue is also present in 16, file a problem report or ask on freebsd-current@freebsd.org mailing list.

EDIT: Also, check in BIOS/UEFI the power management settings.

[1]
Code:
Oct  1 23:35:06 le15 power_profile[6901]: changed to 'economy'
Oct  1 23:35:06 le15 kernel: ACPI Error: No handler for Region [ECSI] (0xfffff80001825f00) [EmbeddedControl] (20250807/evregion-292)
Oct  1 23:35:06 le15 kernel: ACPI Error: Region EmbeddedControl (ID=3) has no handler (20250807/exfldio-428)
Oct  1 23:35:06 le15 kernel: ACPI Error: Aborting method \_SB.UBTC.ECRD due to previous error (AE_NOT_EXIST) (20250807/psparse-689)
Oct  1 23:35:06 le15 kernel: ACPI Error: Aborting method \_SB.UBTC.NTFY due to previous error (AE_NOT_EXIST) (20250807/psparse-689)
Oct  1 23:35:06 le15 kernel: ACPI Error: Aborting method \_SB.PCI0.LPC0.EC0._Q4F due to previous error (AE_NOT_EXIST) (20250807/psparse-689)
Oct  1 23:35:06 le15 kernel: acpi_ec0: evaluation of query method _Q4F failed: AE_NOT_EXIST

[2] https://download.freebsd.org/snapshots/ISO-IMAGES/16.0/
 
Thanks. I'll try to update the EC controller in the next few days as soon as I have time.

If that doesn't help, I might try 16 Branch.

I'll let you know whether it works or not.
 
May be a dodgy USB-C cable?
This also happens with USB-C YubiKeys, USB-C chargers, and USB-C smartphones. The laptop has two USB-C ports, which are probably connected in parallel. Strangely enough, the YubiKey only works with one of them.
 
I might not be an expert on such matters, but would there be any changes if you booted FreeBSD in safe mode - Single-User Mode.
 
I'm assuming the USB-C end is on the laptop, so what is on the other end of the cable? Is it a mini-dock that has other things plugged into it?
Sorry posted without fully reading all the previous responses. Yes I skimmed them all but was not fully engaged.
 
I'm assuming the USB-C end is on the laptop, so what is on the other end of the cable? Is it a mini-dock that has other things plugged into it?
Sorry posted without fully reading all the previous responses. Yes I skimmed them all but was not fully engaged.
USB-C Charger and USB-C YubiKey that is all.
 
  • Like
Reactions: mer
I have narrowed the problem down to the i915/DRM graphics stack.


With i915kms loaded, I experience GPU hangs. The logs show repeated GPU HANG, Resetting rcs0 for preemption time out, and GL_CONTEXT_LOST messages. During one incident, I could still switch to another TTY and restart Sway, but the graphics session failed again later.


After a GPU hang, running kldunload i915kms left the screen black, with the LEDs still on and no working TTY switching. This resembles the shutdown/reboot failure described earlier.


As a comparison, I worked for three hours in the console using nvim, with i915kms not loaded. There were no freezes, and both reboot and poweroff worked.


Current versions:


  • FreeBSD 15.1-RELEASE-p4
  • drm-latest-kmod 6.12.85.1501000
  • Mesa 26.2.2_1
  • SwayFX 0.6
  • Intel Core 7 240H integrated graphics

These results strongly point to the graphics stack, although I have not identified the exact cause. USB-C is not required to trigger the problem.


I will mark this thread as resolved regarding the investigation and pursue the graphics issue separately. The underlying bug is not fixed.


Thank you to everyone who helped.
 
intel hardware fun
i have a bunch of gen 8 intel nucs with integrated graphics. if they go in power saving they lock hard as in you need to power them off and this is with windows 11.
i researched a lot, tried various graphics drivers, update hdmi firmware nothing worked.
in the end i discovered that if i keep some uaudio adapter (cheap phones) plugged in the type c port power saving wont lock the box
so ...
 
I think I've solved the problem. When I bought the laptop, it was important to me that the battery last a long time. So I set the following values in /boot/loader.conf:


#power
compat.linuxkpi.i915_enable_dc=2
compat.linuxkpi.i915_enable_fbc=1
compat.linuxkpi.i915_enable_psr=1


When I started having problems shutting down and restarting the laptop, I set all the values to 0. The problem was still there. Yesterday, I simply commented out the values in loader.conf, and I haven’t had any freezes since then.
 
Back
Top