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.

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.

Thank you!

Please list your mounts. Got any network fs mounted?

No network mounts. I tried both swap partition and swap file. Got the same result.

FYI, memory is 8GB and SSD is 500GB:
* EFI 100mb starting from 2048 sector (aligned by gdisk)
* swap 10GB
* / 40GB
* /home rest

It's a dedicated Slackware machine.

/dev/nvme0n1p1   /boot/efi        vfat        defaults         0   1
#/dev/nvme0n1p2   swap             swap        defaults         0   0
/tmp/swapfile    none             swap        defaults         0   0
/dev/nvme0n1p3   /                ext4        defaults         1   1
/dev/nvme0n1p4   /home            ext4        defaults         1   2
#/dev/cdrom      /mnt/cdrom       auto        noauto,owner,ro,comment=x-gvfs-show 0   0
/dev/fd0         /mnt/floppy      auto        noauto,owner     0   0
devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0
tmpfs            /dev/shm         tmpfs       defaults         0   0

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.

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):

# 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:

# 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

Wow! You're awesome! I just tried kernel 4.9.77 and both wifi and hibernation work great!

1st hibernation: 5.1 seconds
2nd hibernation: 5.7 seconds
3rd hibernation: 14 seconds
4th hibernation: 12 seconds

This result is more than acceptable. I almost gave up and really appreciate your help.

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.

I'm going to try 4.14.14 without this module.

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.

From CONFIG_INTEL_ISH_HID: Intel Integrated Sensor Hub

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.