[RESOLVED] Thinkpad P53s reboot issue

occamzchainsaw · 2026-02-03 18:32:38

Hey everyone,

let me preface this by saying I am not very experienced with Arch. The forums have been very helpful in getting me going, but, so far, I have not found a solution to my reboot problem. Also, other than the issue I describe below, the system runs flawlessly.

Here's my setup:
ThinkPad P53s (i7-8565U, Nvidia Quadro P520)
EFI boot with GRUB
kernel: 6.12.68-1-lts
display manager: ly
DE: hyprland

This is a pretty fresh install (2 days ago, most of that time spent chasing this reboot issue lol). I previously ran Mint Cinammon for a while and reboot worked fine there.

The problem:
on reboot, the system seemingly shuts down (display and power LEDs go off), but the laptop does not fully shut down (fan spinning, keyboard backlight still on - I can even change it with Fn+space). From there, it just hangs in that state, never getting to the actual reboot part. Poweroff or shutdown commands work just fine, and the laptop shuts down correctly.

My initial thinking was this may have something to do with a systemd not shutting down correctly and keeping the system alive. To rule out all the hyprland-related stuff and the ly service I booted and logged in straight into the tty - no luck. Disabling ly@tty1.service also yielded no result.
Next up, Nvidia power management services. I enabled nvidia-suspend, nvidia-hibernate, and nvidia-resume - same behavior.
I looked over the journalctl -b -1 entries and nothing seemed to error out, I see "Reached target System Reboot" and "Journal stopped" entries so it looks like the system is actually handing over the shutdown sequence to the kernel.

At this point, I figured the issue must be caused by something either preventing the kernel from sending the shutdown command (I guess by default over acpi) or the command is ignored due to some hardware not being ready to shut down (or refusing to do so, idk). This set it me on a path to check multiple different kernel parameters, based on advice from various forum/reddit posts.
I have tried using:

nowatchdog, reboot=pci, reboot=efi, reboot=acpi, pcie_aspm=off, tpm_tis.interrupts=0, xhci_hcd.quirks=270336, mei_me.blacklist=yes, mei.blacklist=yes

Pretty much any and all combinations of the above did not resolve the issue.

I figured maybe some BIOS settings could be the culprit. I tried disabling/enabling Thunderbolt BIOS Assist Mode, the TPM module, Intel SpeedStep, setting OS Optimized Defaults. Each tried individually, none helped.

I will add that I tried booting into the live environment at some point during all this and reboot didn't work there either!

At this point, I am at wits' end. If there are any kind and knowledgeable souls who may shed some light on this, I will be very grateful. If anyone would like me to post more info, please tell the newbie what command to run

Last edited by occamzchainsaw (2026-02-12 15:21:40)

V1del · 2026-02-03 20:56:45

The LTS kernel is over a year old from a new features/new developments perspective, can you repro on the non LTS kernel?

occamzchainsaw · 2026-02-04 15:04:19

I installed the non LTS kernel and rebuilt the nvidia dkms packages (as I'm told I should). It didn't resolve my issue, sadly.

uname -r
6.18.7-arch1-1

Here are my kernel parameters (is that even what I should call them?). The ones I mentioned in my initial post didn't seem to help, so I removed them. If you can spot anything wrong with this list, please do let me know.

GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet nowatchdog nvidia_drm.modeset=1 nvidia_drm.fbdev=1 reboot=pci,force"

twelveeighty · 2026-02-04 15:27:22

Take out 'loglevel=3' and 'quiet' for sure so you may see something come by during the shutdown that may shed some light on the problem.

What's concerning is that the installation Live disk has the same problem. There was a recent update to the install medium. Can you try booting and then reboot with the latest installation medium? That one has kernel 6.18.7.

occamzchainsaw · 2026-02-04 17:54:33

Took out loglevel and quiet - it's tricky to read this stuff, especially that it flies by at mach 5, but I made a little recording on my phone, went over it and I can see only [ OK ] messages. The end of it shows 'Reached target System Shutdown', followed by deactivating swaps, then 'Reached target Unmount All Filesystems', 'Reached target Late Shutdown Services', 'Finished System Reboot', and finally 'Reached target System Reboot'. That last bit I find odd - is it normal that it "finishes" System Reboot and then "reaches target" System Reboot?

I re-flashed a usb disk with an image downloaded today - dated 01 Feb - with kernel version 6.18.7 - same behavior as before.

While testing the live disk I noticed that not only does my keyboard stay lit up, the light on the flash drive was on as well. That would suggest the USB controller prevents the shutdown? I guess they keyboard is also a USB device, technically. Maybe that sheds a bit more light on it.

seth · 2026-02-04 21:08:14

USB controller prevents the shutdown? I guess they keyboard is also a USB device, technically

lsusb -tv

https://bbs.archlinux.org/viewtopic.php?id=311755&p=3 seems to be caused by systemd 259, you could try to downgrade that.

twelveeighty · 2026-02-05 15:53:32

Per seth's point: before downgrading your installed systemd, perhaps first check the Live CD's systemd version. If that's the same version as you would downgrade to but it still has the problem, then we're back to square 1 anyway.

Try running and rebooting from the Mint Live CD again, just to eliminate that the BIOS somehow is involved. Both also use systemd, if I'm not mistaken, so perhaps we can bisect between Mint's version and the Arch Live CD systemd versions instead.

occamzchainsaw · 2026-02-05 16:09:29

I tried downgrading systemd to 258.3-1, which didn't help.

Here's the output from lsusb -vt

/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 008: Dev 002, If 0, Class=Video, Driver=uvcvideo, 480M
        ID 13d3:56a6 IMC Networks 
    |__ Port 008: Dev 002, If 1, Class=Video, Driver=uvcvideo, 480M
        ID 13d3:56a6 IMC Networks 
    |__ Port 009: Dev 003, If 0, Class=Vendor Specific Class, Driver=[none], 12M
        ID 06cb:00bd Synaptics, Inc. Prometheus MIS Touch Fingerprint Reader
    |__ Port 010: Dev 004, If 0, Class=Wireless, Driver=btusb, 12M
        ID 8087:0aaa Intel Corp. Bluetooth 9460/9560 Jefferson Peak (JfP)
    |__ Port 010: Dev 004, If 1, Class=Wireless, Driver=btusb, 12M
        ID 8087:0aaa Intel Corp. Bluetooth 9460/9560 Jefferson Peak (JfP)
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/6p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub

I'm not sure if I can glean anything from that. I ran cat /proc/acpi/wakeup and XHC is enabled at S3. I guess that shouldn't be a problem, but I tried disabling it anyway - still no luck.

Anyway, if it helps diagnose, here's the output from cat /proc/acpi/wakeup

Device	S-state	 Status   Sysfs node
GLAN	 S4	*enabled   pci:0000:00:1f.6
XHC	 S3	*enabled   pci:0000:00:14.0
XDCI	 S4	*disabled
HDAS	 S4	*disabled  pci:0000:00:1f.3
RP01	 S4	*enabled   pci:0000:00:1c.0
PXSX	 S4	*disabled  pci:0000:01:00.0
		*disabled  platform:rtsx_pci_sdmmc.0
RP02	 S4	*disabled
PXSX	 S4	*disabled
RP03	 S4	*disabled
PXSX	 S4	*disabled
RP04	 S4	*disabled
PXSX	 S4	*disabled
RP05	 S4	*enabled   pci:0000:00:1c.4
PXSX	 S4	*enabled   pci:0000:02:00.0
RP06	 S4	*disabled
PXSX	 S4	*disabled
RP07	 S4	*disabled
PXSX	 S4	*disabled
RP08	 S4	*disabled
PXSX	 S4	*disabled
RP09	 S4	*enabled   pci:0000:00:1d.0
PXSX	 S4	*disabled
RP10	 S4	*disabled
PXSX	 S4	*disabled
RP11	 S4	*disabled
PXSX	 S4	*disabled
RP12	 S4	*disabled
PXSX	 S4	*disabled
RP13	 S4	*enabled   pci:0000:00:1d.4
PXSX	 S4	*disabled  pci:0000:3d:00.0
RP14	 S4	*disabled
PXSX	 S4	*disabled
RP15	 S4	*disabled
PXSX	 S4	*disabled
RP16	 S4	*disabled
PXSX	 S4	*disabled
RP17	 S4	*disabled
PXSX	 S4	*disabled
RP18	 S4	*disabled
PXSX	 S4	*disabled
RP19	 S4	*disabled
PXSX	 S4	*disabled
RP20	 S4	*disabled
PXSX	 S4	*disabled
RP21	 S4	*disabled
PXSX	 S4	*disabled
RP22	 S4	*disabled
PXSX	 S4	*disabled
RP23	 S4	*disabled
PXSX	 S4	*disabled
RP24	 S4	*disabled
PXSX	 S4	*disabled
CNVW	 S4	*disabled  pci:0000:00:14.3
AWAC	 S4	*disabled
SLPB	 S3	*enabled   platform:PNP0C0E:00
LID	 S4	*enabled   platform:PNP0C0D:00

Thank you for the replies!

seth · 2026-02-05 16:19:55

I'm not sure if I can glean anything from that.

The keyboard isn't wired via USB.

1. in case there's a parallel windows installation see the 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
2. try to lie to ACPI and pretend to be windows, eg.

acpi_osi=! acpi_osi="Windows 2015"

https://learn.microsoft.com/en-us/windo … inacpi-osi

occamzchainsaw · 2026-02-05 21:01:23

There used to be a dual boot arrangement on this PC before, when I was running Mint alongside Windows 11 22H2. That, however is gone completely, because the current Arch installation is on a new drive (the only drive in the computer). Is there a possibility that the previous Windows install changed something in the firmware that would cause this reboot hang?

Trying to lie to ACPI didn't help. I tried with Windows 2015 and Windows 2022 option (I figured 2022 might work, cause that corresponds to the version that was on here before). The boot menu still lists Windows Boot Manager for some reason. I suppose I could try getting rid of that?

seth · 2026-02-05 21:26:02

Is there a possibility that the previous Windows install changed something in the firmware that would cause this reboot hang?

Possible maybe, likely not so much - except

The boot menu still lists Windows Boot Manager for some reason. I suppose I could try getting rid of that?

That's probably worth a shot and you might want to try to reset the CMOS

occamzchainsaw · 2026-02-11 21:15:00

So, funny story - the drive bought it. I'm not sure why, but it was an old NVMe drive I pulled out of a dead laptop years ago. I installed Arch on a new drive and reboot works just fine. I don't think I did anything differently on this installation, so I will just assume it was the dying drive's fault.

seth · 2026-02-11 21:45:04

\o/
Also RIP disk

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Arch Linux

#1 2026-02-03 18:32:38

[RESOLVED] Thinkpad P53s reboot issue

#2 2026-02-03 20:56:45

Re: [RESOLVED] Thinkpad P53s reboot issue

#3 2026-02-04 15:04:19

Re: [RESOLVED] Thinkpad P53s reboot issue

#4 2026-02-04 15:27:22

Re: [RESOLVED] Thinkpad P53s reboot issue

#5 2026-02-04 17:54:33

Re: [RESOLVED] Thinkpad P53s reboot issue

#6 2026-02-04 21:08:14

Re: [RESOLVED] Thinkpad P53s reboot issue

#7 2026-02-05 15:53:32

Re: [RESOLVED] Thinkpad P53s reboot issue

#8 2026-02-05 16:09:29

Re: [RESOLVED] Thinkpad P53s reboot issue

#9 2026-02-05 16:19:55

Re: [RESOLVED] Thinkpad P53s reboot issue

#10 2026-02-05 21:01:23

Re: [RESOLVED] Thinkpad P53s reboot issue

#11 2026-02-05 21:26:02

Re: [RESOLVED] Thinkpad P53s reboot issue

#12 2026-02-11 21:15:00

Re: [RESOLVED] Thinkpad P53s reboot issue

#13 2026-02-11 21:45:04

Re: [RESOLVED] Thinkpad P53s reboot issue

Board footer