Kernel 5.x and above suspend issue

I'm new of this forum, but I'am not new to th GNU/linux ecosystem.
My old HP dv5 1199el has suspend issues with kernel from version 5.0.

When I try to put it in suspend state, it turn off the screen, but the pc stay turned on.
I had the same issue in arch, when they passed the linux-lts from 4.19.x to 5.4.x.

I tried to use some kernel parameter on startup, like acpi_sleep and mem_sleep_default, with no results.

I'm not able to investigate more, so I'm asking your help.

I paste some basic infos about my pc, if you want more, please ask me.

Thank you.

$ screenfetch 

 ██████████████████  ████████     x@x
 ██████████████████  ████████     OS: Manjaro 20.0.1 Lysia
 ██████████████████  ████████     Kernel: x86_64 Linux 4.19.121-1-MANJARO
 ██████████████████  ████████     Uptime: 33m
 ████████            ████████     Packages: 1132
 ████████  ████████  ████████     Shell: bash 5.0.16
 ████████  ████████  ████████     Resolution: 1280x800
 ████████  ████████  ████████     DE: Cinnamon 4.4.8
 ████████  ████████  ████████     WM: Muffin
 ████████  ████████  ████████     WM Theme: Mint-Y-Dark-Teal (Mint-Y-Dark-Teal)
 ████████  ████████  ████████     GTK Theme: Mint-Y-Dark-Teal [GTK2/3]
 ████████  ████████  ████████     Icon Theme: Papirus-Adapta-Nokto-Maia
 ████████  ████████  ████████     Font: Cantarell 10
 ████████  ████████  ████████     Disk: 174G / 195G (94%)
                                  CPU: Intel Core2 Duo T9400 @ 2x 2.534GHz
                                  GPU: NV96
                                  RAM: 1636MiB / 3911MiB

$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port (rev 07)
00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03)
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.3 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
00:1f.6 Signal processing controller: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem (rev 03)
01:00.0 VGA compatible controller: NVIDIA Corporation G96CM [GeForce 9600M GT] (rev a1)
02:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 02)
06:00.0 FireWire (IEEE 1394): JMicron Technology Corp. IEEE 1394 Host Controller
06:00.1 System peripheral: JMicron Technology Corp. SD/MMC Host Controller
06:00.2 SD Host controller: JMicron Technology Corp. Standard SD Host Controller
06:00.3 System peripheral: JMicron Technology Corp. MS Host Controller
06:00.4 System peripheral: JMicron Technology Corp. xD Host Controller

Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   36 bits physical, 48 bits virtual
CPU(s):                          2
On-line CPU(s) list:             0,1
Thread(s) per core:              1
Core(s) per socket:              2
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           23
Model name:                      Intel(R) Core(TM)2 Duo CPU     T9400  @ 2.53GHz
Stepping:                        6
CPU MHz:                         2418.280
CPU max MHz:                     2534,0000
CPU min MHz:                     800,0000
BogoMIPS:                        5054.99
Virtualization:                  VT-x
L1d cache:                       64 KiB
L1i cache:                       64 KiB
L2 cache:                        6 MiB
NUMA node0 CPU(s):               0,1
Vulnerability Itlb multihit:     KVM: Mitigation: Split huge pages
Vulnerability L1tf:              Mitigation; PTE Inversion; VMX EPT disabled
Vulnerability Mds:               Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Full generic retpoline, STIBP disabled, RSB filling
Vulnerability Tsx async abort:   Not affected
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe sysca
                                 ll nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx
                                 16 xtpr pdcm sse4_1 lahf_lm pti tpr_shadow vnmi flexpriority dtherm
inxi -Fxxxza --no-host

would probably be more helpful than screenfetch and such.

Judging from the little I can see .. you have an 'older' machine (core 2 duo) .. meaning you dont really need kernels 5.X+ .. and right now the longest lasting LTS kernels available are 4.9 and 4.14 (supported at least until 2024) .. so is there any reason to need/want a newer kernel ?


Why sure there is, it's all shiny and sparkly and has that new car smell. All the cool kids insist on that.


Sorry, here it is:

$ inxi -Fxxxza --no-host
System:    Kernel: 4.19.121-1-MANJARO x86_64 bits: 64 compiler: gcc v: 9.3.0 
           parameters: BOOT_IMAGE=/@/boot/vmlinuz-4.19-x86_64 root=UUID=ce089543-0741-480c-b9e6-ec8f5dbbfb68 rw 
           rootflags=subvol=@ apparmor=1 security=apparmor resume=UUID=df6ed733-9c2d-4f14-adbe-fff38fdbcce4 
           Desktop: Cinnamon 4.4.8 dm: LightDM 1.30.0 Distro: Manjaro Linux 
Machine:   Type: Laptop System: Hewlett-Packard product: HP Pavilion dv5 Notebook PC v: Rev 1 serial: <filter> Chassis: Quanta 
           type: 10 serial: <filter> 
           Mobo: Quanta model: 3603 v: 02.26 serial: <filter> BIOS: Hewlett-Packard v: F.21 date: 08/20/2009 
CPU:       Topology: Dual Core model: Intel Core2 Duo T9400 bits: 64 type: MCP arch: Penryn family: 6 model-id: 17 (23) 
           stepping: 6 microcode: 60F L2 cache: 6144 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 ssse3 vmx bogomips: 10109 
           Speed: 2254 MHz min/max: 800/2534 MHz Core speeds (MHz): 1: 2036 2: 2051 
           Vulnerabilities: Type: itlb_multihit status: KVM: Split huge pages 
           Type: l1tf mitigation: PTE Inversion; VMX: EPT disabled 
           Type: mds status: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled 
           Type: meltdown mitigation: PTI 
           Type: spec_store_bypass status: Vulnerable 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full generic retpoline, STIBP: disabled, RSB filling 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: NVIDIA G96CM [GeForce 9600M GT] vendor: Hewlett-Packard driver: nouveau v: kernel bus ID: 01:00.0 
           chip ID: 10de:0649 
           Display: x11 server: X.Org 1.20.8 driver: nouveau unloaded: modesetting alternate: fbdev,nv,vesa 
           resolution: 1280x800~60Hz 
           OpenGL: renderer: NV96 v: 3.3 Mesa 20.0.6 direct render: Yes 
Audio:     Device-1: Intel 82801I HD Audio vendor: Hewlett-Packard driver: snd_hda_intel v: kernel bus ID: 00:1b.0 
           chip ID: 8086:293e 
           Sound Server: ALSA v: k4.19.121-1-MANJARO 
Network:   Device-1: Intel PRO/Wireless 5100 AGN [Shiloh] Network driver: iwlwifi v: kernel port: 9000 bus ID: 02:00.0 
           chip ID: 8086:4237 
           IF: wlp2s0 state: up mac: <filter> 
           Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Hewlett-Packard driver: r8169 v: kernel 
           port: 6000 bus ID: 03:00.0 chip ID: 10ec:8168 
           IF: enp3s0 state: down mac: <filter> 
Drives:    Local Storage: total: 298.09 GiB used: 173.57 GiB (58.2%) 
           ID-1: /dev/sda vendor: Western Digital model: WD3200BEVT-60ZCT0 size: 298.09 GiB block size: physical: 512 B 
           logical: 512 B speed: 3.0 Gb/s rotation: 5400 rpm serial: <filter> rev: 1A12 scheme: MBR 
Partition: ID-1: / raw size: 18.00 GiB size: 18.00 GiB (100.00%) used: 11.21 GiB (62.3%) fs: btrfs dev: /dev/sda2 
           ID-2: /home raw size: 178.00 GiB size: 175.08 GiB (98.36%) used: 162.36 GiB (92.7%) fs: ext4 dev: /dev/sda5 
           ID-3: swap-1 size: 4.00 GiB used: 0 KiB (0.0%) fs: swap swappiness: 60 (default) cache pressure: 100 (default) 
           dev: /dev/sda6 
Sensors:   System Temperatures: cpu: 39.0 C mobo: N/A gpu: nouveau temp: 41 C 
           Fan Speeds (RPM): N/A 
Info:      Processes: 252 Uptime: 2h 18m Memory: 3.82 GiB used: 1.45 GiB (37.9%) Init: systemd v: 245 Compilers: gcc: 9.3.0 
           Shell: bash v: 5.0.16 running in: gnome-terminal inxi: 3.0.37 

I don't want a new kernel because I need it or I aim it, I would use version 3.10 if I could, because it was the last version when my pc was working 100% compatible.

I would use a new kernel because I'm trying btrfs and I red this and there is suggested to use the latest kernel.

Another thing is to improve my knowledge of linux. Is that a guilt to be mocked of?

I didnt mock anything. I simply asked if there is an actual reason.

Yeah .. I guess btrfs you kinda want 5.0+ .. swap files are available then .. and at 5.6+ SSD trim, etc.

Sorry if you feel I was mocking you, but this is a recurring theme on the Manjaro forum. Many people with older hardware insist they must be on the newest kernels for no good reason.

Many of these users get downright indignant that their old hardware doesn't work properly with the newest kernels. They often complain vociferously that it is Manjaro's fault, when Manjaro has nothing to do with kernel development.

So, ya many of these new Manjaro users leave a bad taste in your mouth because of their incessant whining and lack of understanding.

Sorry to take it out on you.

My own personal opinion on your issue is forget about btrfs. Your only likely to cause yourself problems. Don't go looking to create issues when your system is currently working fine on the older kernels.

Simply use timeshift for backups instead of the snapshot feature in btrfs. Btrfs is not 100% solid yet and you may regret opening this can of worms if you go there. Just my opinion.

Ok, thank you for your replies.
So, do you think that I must return using ext4 instead fo btrfs?
I know btrfs is not 100% complete, but I read many users sotisfied with it, and I wanted to let it a try.

My impression, after few month, is that the system goes very well and snapshots feature is great. My idea was formatting the entire disk in btrfs, so that's why I needed to have a recent kernel.

It's your system, do as you please. Just be sure you have full backups of all data stored elsewhere on redundant backup drives.

Btrfs is great, until it isn't.

One day it may just break on you, and then your snapshots may be totally unrecoverable. As long as you still keep separate backups then you have no big worries. However, if you get lulled into a false sense of security and then something happens you're hooped. Just be sure you keep your external backups current, or you could be sorry.

Thank you for explaining your idea so clearly.

After this off topic digression on btrfs, I will assume my risks trying it.
Would you mind suggest me a way to analyze,and hopefully solve, the suspend issue, please?

:slightly_smiling_face: The suspend feature works rather well on my hardware and I am currently using the kernel: 5.6.13-1-MANJARO.

Your BIOS is dated 2009. (I harp on this quite a bit.) Is there a more current one available? If so, you should install it. That may not fix your problem, but it is a very good place to start.


Nope, it is the latest version for my notebook.

If your bios allows, as a simple test disable wifi and LAN. Reboot and then test your suspend function. Also disconect all peripheral devices and test suspend.

I tried to disable wifi (lan is not permitted) but the result is the same.
With last release of kernel 5.6.11 my pc goes on suspend state, it take a while but after a couple of minutes it goes. Anyway it don't resume properly. Screen shows the wallpaper but it doesn't take any input. It is freezed.

Is there any log I could send you to investigate my issue?

Thank you.

Generally, logs aren't very useful when suspending because the actual problem almost never appears in the logs.

partially solved.

I installed propietary nvidia-340xx driver and the system goes to suspend state and it resemes without any issue. Kernel 5.6.16.

I'm not completly satisfied, becasue from at least a year I used nouveau driver with no issues. And I would prefer using free drivers.

So, it seems that nouveau causes the problem with recent kernel versions. Would you suggest to report the bug, or first could you help me in other ways to investigate into this issue, please?

Thank you.

Very nice work on your part. That is unfortunate, as I'm not sure how much longer the 340 series driver is going to be supported.

This topic was automatically closed after 180 days. New replies are no longer allowed.

Forum kindly sponsored by