Hibernation takes ~10 seconds only once after a reboot; After resume, it takes about 3-4 minutes.
Linux - Laptop and NetbookHaving a problem installing or configuring Linux on your laptop? Need help running Linux on your netbook? This forum is for you. This forum is for any topics relating to Linux and either traditional laptops or netbooks (such as the Asus EEE PC, Everex CloudBook or MSI Wind).
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hibernation takes ~10 seconds only once after a reboot; After resume, it takes about 3-4 minutes.
Hello, this issue is really weird. I got a Lenovo ThinkPad Yoga 370 and was able to successfully install Slackware64 14.2 after spending some R&D time (UEFI + NVMe SSD). Then, I realized that the WiFi card in this laptop is new and this version of Slackware (kernel 4.4.14) doesn't support it. No WiFi, but hibernation works fine even after resume.
Since I cannot live without WiFi, I downloaded and installed kernel 4.14.14 packages from Slackware64-Current. Now, WiFi works fine and hibernation sort of works... After a clean reboot, hibernation is very quick (5-10 seconds), but after resume, it takes almost 3-5 minutes. First time, I tried this, I thought that the process just hung and just force rebooted the machine. Next time, after a quick hibernation/resume, I decided to wait and hibernation worked almost after 3 minutes. I checked /var/log/messages and /var/log/syslog and found what's causing this delay.
Code:
PM: hibernation entry
...
PM: Syncing filesystems...
<---------------------------------- Almost 3-4 minutes delay here. No other processes.
PM: done
The first hibernation after a reboot doesn't have this delay. I have no idea why it takes this long to sync filesystems. I tried to hibernate right after resume and also tried to wait long. Didn't make a difference. Google returned similar symptoms, but not the same.
Not sure what I can do now. Does anyone have any idea what's causing this delay in filesystem syncing?
Summary:
Kernel 4.4.14: No WiFi support, but Hibernation works great
Kernel 4.14.14: WiFi support, but Hibernation becomes too slow from second time.
Looks like you have a NVM Express drive. I would primarily blame the drive for that. Try to test the drive performance 1) after a boot 2) after a hibernation/resume.
Code:
hdparm -Tt --direct /dev/nvme0n1
as root. Better run the command several times in a row for more meaningful results.
Never had experience with this kind of an interface. From what I've read, some sophisticated alignment is needed. This Intel guide may be of any help. It also says about a way of more precise hdparm testing. Also you could try to play with kernel config. As long as you're a Slackware user I guess you're comfortable with kernel compilation. May be some drive specific config is missing for the new kernel.
p.s. Btw there is a forum thread about an issue that looks pretty similar to yours, but on Windows.
Ah! I never thought about that. It could be the NVMe driver.
This is result (average):
Code:
# after a fresh boot
cached reads: 1069.68 MB/sec
disk reads: 1478.48 MB/sec
# after a resume
cached reads: 1034.49 MB/sec
disk reads: 1536.72 MB/sec
No meaningful difference, I guess. This read/write test gave me the following result:
Code:
# after a fresh boot
write: 1.3 GB/sec
read: 2.8 GB/sec
# after a resume
write: 1.3 GB/sec
read: 2.8 GB/sec
Again, no difference there. I checked my alignment and since it's 2048-sector boundaries (512 bytes/sector), each starting block is all divisible by 4096 bytes. I found this article about my SSD (Samsung 960 EVO M.2 NVMe SSD 500GB). Looks like I had to use 6144 KiB (12288 sectors)? But, still its performance is consistent. Not sure if this is the culprit.
I'm looking into the kernel config now. Thanks for the hints!
For our record, it was not the sys_sync() call between the "Syncing filesystems..." and "done" messages in hibernate() in kernel/power/hibernate.c. The delay was still there even after commenting out this call. I added more debug messages and found that some messages "before" creating the hibernation image were logged "after" resume in /var/log/message. And the location of delay was like random. I thought this was because of write buffering, so I added the sys_sync() call back and even added more after my debug messages to avoid buffering. Now, the delay had moved into freeze_processes() after "Syncing filesystems... done", so it was obvious that the delay was not because of the SSD. There was a loop that tries to freeze all threads in this function. Adding more debug messages with the names of threads being frozen, I found the delay right before freezing syslogd. I didn't think that syslogd was causing the delay. Instead, since this thread is responsible for logging debug messages into /var/log/message, killing this thread just happened to delay message logging after resume when the thread became alive. I tried to not kill this thread to see what would happen if syslogd was still alive. Now, the delay had moved one thread ahead, which was klogd. Hibernation worked, but the issue was still there. I skipped freezing klogd as well, but this time hibernation didn't work at all.
From these experiments, I was not able to find which thread is causing my issue because once syslogd and klogd got frozen, there is no way to see more debug messages with correct timestamps before hibernation completes (if my theory about syslogd is correct).
I even removed all modules and drivers related to network (because hibernation works fine without wifi in kernel 4.4.14), but no luck. Now, I don't have many options:
1. Live with slow hibernation
2. Just shutdown with no hibernation
3. Try Slackware64-current even if it's the same kernel 4.14.14 causing the issue "assuming" that it was a bad combination of the newer kernel and older packages (e.g., pm-utils...)
Maybe, I'll try the current branch later and report back.
You also can try to use the LTS 4.9 kernel. I had some video driver glitches on gentoo with 4.14. Obviously I wasn't the only one facing issues with 4.14 so that the gentoo kernel ebuild was dowgraded to 4.9
OK, I found the module that caused this hibernation issue. I was configuring screen auto-rotation and found that my 4.9.77 didn't recognize the Intel Sensor Hub at all. It worked with 4.14.14, so I compared their config files. It was the INTEL_ISH_HID module. When I compiled this module, the hibernation delay came back! Argh... so I had to choose either hibernation or auto-rotation; my pick was of course hibernation and manual rotation.
The ISH is responsible for setting the CPU power-state, including putting the CPU into the low-power mode. Maybe somewhere there lays the root cause for the issue?
Is ISH a must have? Isn't it a new feature so 4.9.77 without it works fine? This module was introduced in kernel 4.9. So there was no low-power CPU mode before this release? Or do we need ISH now to put the CPU in modern laptops into the low-power mode?
Found this article. "suspend and wakeup seems to be really slow now" after applying the intel-ish-hid patch.
The Integrated Sensor Hub (ISH) enables the ability to offload sensor polling and algorithm processing to a dedicated low power processor in the chipset. This allows the core processor to go into low power modes more often, resulting in the increased battery life. The current processors that support ISH are: Cherrytrail, Skylake, Broxton and Kaby Lake.
So if I just completely disable the sensor hub, the core process doesn't have to do anything because there is no sensor data at all? Is it even possible to leave the sensor hub alive and deactivate this driver? I don't believe so. No driver, no hardware.. so no additional responsibilities to the core process.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.