[SOLVED] Random freezes when resuming from suspend

Hi everybody. I’m a happy Manjaro user since a few weeks. I’ve had a few problems but nothing that I couldn’t either solve or accept until it’s fixed. :wink:

The only bug that gives me a bit of a headache is that, from time to time, when I resume my laptop after suspension, the keyboard and the touchpad are unresponsive. As I have to type my password to login into the desktop session, this behaviour doesn’t allow me to do anything. The only solution is to turn off the laptop with the power button.

As I said, this doesn’t happen always, but only from time to time. I don’t have precise statistics, but I would say roughly on 10% of suspensions.

I searched solutions by myself before opening this topic, but I couldn’t find anything. Indeed, most people who have this problem have it always, and not randomly like me. On my laptop, most of the times suspension and resume work as they should.

The main question I have is the following: how can I retrieve information on what caused the issue when the problem occurs? Is there a log file that I can access? Will it contain information even if the laptop is turned off manually?

Other than this, any clue on what could cause the issue? Suggestions on what to look at?


P.S. The title of the topic says [SOLVED] because I actually solved the problem, but it’s worth mentioning that I solved it by going back to kernel 4.14. With the most recent LTS kernel (4.19) the problem is still there.

You definitely want to test different kernels out for improvement. I would test all these kernels in this order:

If that doesn’t work, I could try helping you write a service to reload your keyboard and touchpad after suspension. I warn you that this will involve a lot of troubleshooting effort. Do not request help on this if you are unwilling to see it through to the end of the troubleshooting process. Frankly I get tired of getting invested in these issues and then the OP always bails out when they see how much work is involved.

Good luck testing out those kernels.

Thanks a lot for your reply. I have already experienced the issue with 3 of these kernels (4.18, 4.19, 4.20), but I’ll give 4.14 a try. Thanks for offering your help, I’ll ask you if I decide to go that way.

An alternative could be to see if the problem occurs with hibernation too. Hibernation takes a bit longer but not so much (I have an SSD disk), and if it doesn’t have the issue it might be a decent second-best option.

Yes hibernation often works when suspend does not. Most people don’t like using that option though. Especially with an SSD, as that results in excessive wear.

What does that mean?

SSD’s are only good for a limited amount of write cycles. The longevity is much improved with recent SSD improvements, but they still wear out if used excessively. Every time you hibernate you could be writing 4GB or more to your swap partition.

Say you hibernate 5 times during the day on a laptop, that could be in excess of 20GB’s per day written to your swap partition from hibernation alone. That eats up your write cycles a lot quicker than just your daily OS write cycle usage.

1 Like

This behavior is what I was getting when I overclocked my cpu too far. There are no advanced processor settings on your laptop? If there are, disable them for now, and try suspending.

I don’t know what these “advanced processor settings” could be. Do you mean power management tools like tlp? Otherwise, I would ask you to explain better.

P.S. Please consider that I don’t have these issues always but only occasionally.

P.P.S. I’ve been with kernel 4.14 for a couple of days and no freezes have occurred so far.

1 Like

Try this after a suspend failurejournalctl --boot=-1

If kernel 4.14 is working for you, it might be a bug in the newer kernels…

If you dont know/ dont see where the settings I described, chances are they don’t exist and are not a solution to the problem.

Thanks, I’ll inspect the outcome of that command if I have a freeze when resuming. For the moment I remain with kernel 4.14.

Kernel 4.14 seems to have no problems. I’m going to use it until I can, hoping that the bug gets fixed in newer kernels.

For your information, this is my hardware:

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 02)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02)
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 02)
00:13.0 Non-VGA unclassified device: Intel Corporation Sunrise Point-LP Integrated Sensor Hub (rev 21)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] (rev 21)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 Network controller: Intel Corporation Wireless 3165 (rev 79)

Same issue here on a Lenovo X250, randomly the system wouldn’t wake up from suspend. Sometimes it freezes if I close the lid on power, even though nothing should happen when plugged in. Running kernel 4.20 now, I’ll try a few other kernels.
Get a few ACPI errors on boot but nothing that should cause this.

“systemctl suspend” seems to work if I wake up the machine right afterwards. Don’t know if it’s the same after a few hours.

However, I’m not surprised. This is probably the 5th or 6th laptop running Arch in the last 10 years and suspend never worked out-of-the-box/without issues. I’ll test and report.

Update: Kernel 4.19 suspends fine from terminal and wakes up. Doesn’t suspend on lid-close though. Also, Fingerprint is not working anymore after wakeup.
Update-2: Nevermind, same ■■■■ different kernel. Wouldn’t wake up after suspend for a few hours. Nothing in the logs.

For me the kernel 414 works fine. With kernel 419 these random freezes keep happening (I keep testing it from time to time). Don’t know what’s the cause. It’s not a big problem until I can use kernel 414, but in one year or so it will stop being maintained, and by then I hope there’s some new kernel that works. Otherwise it won’t be nice.

This service may solve your issue:

Thanks, I’m giving it a try right now and will report how it goes.

@tbg, I applied your fix and used kernel 419 for a while. After 3-5 successful resumes from suspending, I get a freeze, like before. So, it seems, forcing a sleep & wake up of all USB devices does not solve the problem.

Did you run systemctl status on your service?

You should post the output so I can see if the service is running properly.

There are other ways of shutting down problematic devices. If you wish to pursue a solution please post:


The commands below will list how the bus paths relate to different vendor/product ID pairs.

Paste these commands into the terminal.

for X in /sys/bus/usb/devices/*; do 
    echo "$X"
    cat "$X/idVendor" 2>/dev/null 
    cat "$X/idProduct" 2>/dev/null

Then hit enter, and post this output as well.

This is the output of my systemctl status:

● usb-restart.service - Disable, then restart USB devices
   Loaded: loaded (/etc/systemd/system/usb-restart.service; enabled; vendor pre>
   Active: inactive (dead)

This is lsusb:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 009: ID 0bda:0177 Realtek Semiconductor Corp. 
Bus 001 Device 008: ID 2386:3111  
Bus 001 Device 007: ID 8087:0a2a Intel Corp. 
Bus 001 Device 006: ID 0bda:58c2 Realtek Semiconductor Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

And this is the last command:















I meant the unit status, such as:

systemctl status usb-restart.service

I fixed the output of the first command in my previous post.

Forum kindly sponsored by Bytemark