You are not logged in.

#1 2019-02-01 20:58:40

defaultxr
Member
Registered: 2013-02-12
Posts: 8

Kernel panics on resume from suspend since upgrading to linux 4.20

Hello,

Since upgrading to linux-4.20, I'm not able to resume from suspend anymore. It worked fine previously, and I can still suspend with systemctl suspend, but when I re-open my laptop lid, instead of resuming, the screen stays black and the caps lock light blinks. I've tried every linux kernel since 4.20 and they all have the same issue, unfortunately. Just upgraded to 4.20.6-arch1 last night and still having the problem.

I tried switching to the linux-lts kernel (at 4.19.18 currently) to see if it would fix the problem, but unfortunately I have basically the same issue with it, so it must be caused by something else as well.

The laptop is an MSI GT72S 6QF, which has an Intel Core i7 CPU and an Nvidia GTX980 GPU. I'm using intel-ucode 20180807.a-1 (though I tried booting without it and have the same issue, not sure if it would affect it) and Nvidia's proprietary graphics driver 415.27-4.

I'd like to submit a bug about this, so it can hopefully be fixed, however the screen remains black so there's not really any chance as far as I'm aware to see any kernel panic message.

I asked on #archlinux a few days ago for help, and one person suggested I try using Netconsole to log kernel messages, as per its Arch wiki page. I tried that, and was able to receive messages from the kernel on another computer on my network, however when I tried suspending and resuming, I didn't get any other messages, let alone a kernel panic, unfortunately. So it doesn't seem like that would work.

I could try downgrading linux, linux-headers, the nvidia packages, systemd, etc, if that would help diagnose the issue at all. However I'm guessing it's the kernel panic that would be the most useful, so that's mostly what I'm trying to get, so that this regression can be reported and hopefully fixed.

Can anyone can help me get the kernel panic saved somehow, or (even better) help me to be able to resume from suspend again?

Thank you.

Last edited by defaultxr (2019-02-01 21:00:52)

Offline

#2 2019-02-01 21:09:57

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: Kernel panics on resume from suspend since upgrading to linux 4.20

If you downgrade the linux package to 4.19.12 the issue is no longer present?

Offline

#3 2019-02-01 21:28:02

defaultxr
Member
Registered: 2013-02-12
Posts: 8

Re: Kernel panics on resume from suspend since upgrading to linux 4.20

I downgraded to linux 4.19.12. Due to dependencies, I had to downgrade linux-headers, nvidia, and nvidia-utils as well:

[2019-02-01 15:14] [ALPM] downgraded linux (4.20.6.arch1-1 -> 4.19.12.arch1-1)
[2019-02-01 15:14] [ALPM] downgraded linux-headers (4.20.6.arch1-1 -> 4.19.12.arch1-1)
[2019-02-01 15:14] [ALPM] downgraded nvidia-utils (415.27-1 -> 415.25-1)
[2019-02-01 15:14] [ALPM] downgraded nvidia (415.27-4 -> 415.25-4)

I did this and restarted, then tried suspending again. Suspend worked, but upon trying to resume, the screen still stayed black. However, this time it appears the kernel didn't panic (as the caps lock light was not blinking). So maybe it's another component that is causing the issue? Could it be something related to systemd maybe? I can try downgrading other packages if you think they might be related.

Offline

#4 2019-02-01 21:39:59

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: Kernel panics on resume from suspend since upgrading to linux 4.20

I would suggest using the ALA to downgrade all packages to a date when  the version of linux you were using before the 4.20 update was in the repositories and check everything works as expected.
Edit:
Before doing that was there anything in the journal from the resume using 4.19.12?

Last edited by loqs (2019-02-01 21:41:42)

Offline

#5 2019-02-01 22:15:43

defaultxr
Member
Registered: 2013-02-12
Posts: 8

Re: Kernel panics on resume from suspend since upgrading to linux 4.20

Weird, I tried downgrading as per your link and it's still not waking. Not KPing either, but the screen remains black when I try to resume.

Here's journalctl -k -b -3 (the last suspend/resume I did on 4.19.12 where it didn't resume but also didn't KP):

Feb 01 15:21:45 hypermulti kernel: PM: suspend entry (deep)
Feb 01 15:21:45 hypermulti kernel: PM: Syncing filesystems ... done.
Feb 01 15:21:52 hypermulti kernel: Freezing user space processes ... (elapsed 0.001 seconds) done.
Feb 01 15:21:52 hypermulti kernel: OOM killer disabled.
Feb 01 15:21:52 hypermulti kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Feb 01 15:21:52 hypermulti kernel: Suspending console(s) (use no_console_suspend to debug)
Feb 01 15:21:52 hypermulti kernel: sd 3:0:0:0: [sda] Synchronizing SCSI cache
Feb 01 15:21:52 hypermulti kernel: sd 3:0:0:0: [sda] Stopping disk
Feb 01 15:21:52 hypermulti kernel: ACPI: EC: interrupt blocked
Feb 01 15:21:52 hypermulti kernel: ACPI: Preparing to enter system sleep state S3
Feb 01 15:21:52 hypermulti kernel: ACPI: EC: event blocked
Feb 01 15:21:52 hypermulti kernel: ACPI: EC: EC stopped
Feb 01 15:21:52 hypermulti kernel: PM: Saving platform NVS memory
Feb 01 15:21:52 hypermulti kernel: Disabling non-boot CPUs ...
Feb 01 15:21:52 hypermulti kernel: smpboot: CPU 1 is now offline
Feb 01 15:21:52 hypermulti kernel: smpboot: CPU 2 is now offline
Feb 01 15:21:52 hypermulti kernel: smpboot: CPU 3 is now offline
Feb 01 15:21:52 hypermulti kernel: smpboot: CPU 4 is now offline
Feb 01 15:21:52 hypermulti kernel: smpboot: CPU 5 is now offline
Feb 01 15:21:52 hypermulti kernel: smpboot: CPU 6 is now offline
Feb 01 15:21:52 hypermulti kernel: smpboot: CPU 7 is now offline
Feb 01 15:21:52 hypermulti kernel: ACPI: Low-level resume complete
Feb 01 15:21:52 hypermulti kernel: ACPI: EC: EC started
Feb 01 15:21:52 hypermulti kernel: PM: Restoring platform NVS memory
Feb 01 15:21:52 hypermulti kernel: Enabling non-boot CPUs ...
Feb 01 15:21:52 hypermulti kernel: x86: Booting SMP configuration:
Feb 01 15:21:52 hypermulti kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2
Feb 01 15:21:52 hypermulti kernel:  cache: parent cpu1 should not be sleeping
Feb 01 15:21:52 hypermulti kernel: CPU1 is up
Feb 01 15:21:52 hypermulti kernel: smpboot: Booting Node 0 Processor 2 APIC 0x4
Feb 01 15:21:52 hypermulti kernel:  cache: parent cpu2 should not be sleeping
Feb 01 15:21:52 hypermulti kernel: CPU2 is up
Feb 01 15:21:52 hypermulti kernel: smpboot: Booting Node 0 Processor 3 APIC 0x6
Feb 01 15:21:52 hypermulti kernel:  cache: parent cpu3 should not be sleeping
Feb 01 15:21:52 hypermulti kernel: CPU3 is up
Feb 01 15:21:52 hypermulti kernel: smpboot: Booting Node 0 Processor 4 APIC 0x1
Feb 01 15:21:52 hypermulti kernel:  cache: parent cpu4 should not be sleeping
Feb 01 15:21:52 hypermulti kernel: CPU4 is up
Feb 01 15:21:52 hypermulti kernel: smpboot: Booting Node 0 Processor 5 APIC 0x3
Feb 01 15:21:52 hypermulti kernel:  cache: parent cpu5 should not be sleeping
Feb 01 15:21:52 hypermulti kernel: CPU5 is up
Feb 01 15:21:52 hypermulti kernel: smpboot: Booting Node 0 Processor 6 APIC 0x5
Feb 01 15:21:52 hypermulti kernel:  cache: parent cpu6 should not be sleeping
Feb 01 15:21:52 hypermulti kernel: CPU6 is up
Feb 01 15:21:52 hypermulti kernel: smpboot: Booting Node 0 Processor 7 APIC 0x7
Feb 01 15:21:52 hypermulti kernel:  cache: parent cpu7 should not be sleeping
Feb 01 15:21:52 hypermulti kernel: CPU7 is up
Feb 01 15:21:52 hypermulti kernel: ACPI: Waking up from system sleep state S3
Feb 01 15:21:52 hypermulti kernel: ACPI: EC: interrupt unblocked
Feb 01 15:21:52 hypermulti kernel: ACPI: EC: event unblocked
Feb 01 15:21:52 hypermulti kernel: sd 3:0:0:0: [sda] Starting disk
Feb 01 15:21:52 hypermulti kernel: usb 1-10: reset full-speed USB device number 6 using xhci_hcd
Feb 01 15:21:52 hypermulti kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Feb 01 15:21:52 hypermulti kernel: ata1: SATA link down (SStatus 4 SControl 300)
Feb 01 15:21:52 hypermulti kernel: ata2: SATA link down (SStatus 4 SControl 300)
Feb 01 15:21:52 hypermulti kernel: ata3.00: configured for UDMA/133
Feb 01 15:21:52 hypermulti kernel: usb 1-7: reset full-speed USB device number 5 using xhci_hcd
Feb 01 15:21:52 hypermulti kernel: psmouse serio1: synaptics: queried max coordinates: x [..5706], y [..4800]
Feb 01 15:21:52 hypermulti kernel: dpm_run_callback(): usb_dev_resume+0x0/0x10 returns -5
Feb 01 15:21:52 hypermulti kernel: PM: Device 1-7 failed to resume async: error -5
Feb 01 15:21:52 hypermulti kernel: OOM killer enabled.
Feb 01 15:21:52 hypermulti kernel: Restarting tasks ...
Feb 01 15:21:52 hypermulti kernel: usb 1-7: USB disconnect, device number 5
Feb 01 15:21:52 hypermulti kernel: done.
Feb 01 15:21:52 hypermulti kernel: video LNXVIDEO:01: Restoring backlight state
Feb 01 15:21:52 hypermulti kernel: audit: type=1130 audit(1549056112.763:72): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 01 15:21:52 hypermulti kernel: Bluetooth: hci0: using rampatch file: qca/rampatch_usb_00000302.bin
Feb 01 15:21:52 hypermulti kernel: Bluetooth: hci0: QCA: patch rome 0x302 build 0x3e8, firmware rome 0x302 build 0x111
Feb 01 15:21:52 hypermulti kernel: Bluetooth: hci0: using NVM file: qca/nvm_usb_00000302.bin
Feb 01 15:21:52 hypermulti kernel: PM: suspend exit
Feb 01 15:21:52 hypermulti kernel: usb 1-7: new full-speed USB device number 7 using xhci_hcd
Feb 01 15:21:52 hypermulti kernel: audit: type=1130 audit(1549056112.903:73): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 01 15:21:52 hypermulti kernel: audit: type=1131 audit(1549056112.903:74): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 01 15:21:52 hypermulti kernel: audit: type=1130 audit(1549056112.929:75): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=resume@modula comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 01 15:21:53 hypermulti kernel: usb 1-7: New USB device found, idVendor=1770, idProduct=ff00, bcdDevice= 1.10
Feb 01 15:21:53 hypermulti kernel: usb 1-7: New USB device strings: Mfr=1, Product=1, SerialNumber=1
Feb 01 15:21:53 hypermulti kernel: usb 1-7: Product: MSI EPF USB
Feb 01 15:21:53 hypermulti kernel: usb 1-7: Manufacturer: MSI EPF USB
Feb 01 15:21:53 hypermulti kernel: usb 1-7: SerialNumber: MSI EPF USB
Feb 01 15:21:53 hypermulti kernel: audit: type=1131 audit(1549056113.473:76): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=resume@modula comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 01 15:21:54 hypermulti kernel: ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Feb 01 15:21:54 hypermulti kernel: ata4.00: configured for UDMA/133
Feb 01 15:21:54 hypermulti kernel: alx 0000:05:00.0 enp5s0: NIC Up: 1 Gbps Full
Feb 01 15:21:54 hypermulti kernel: [UFW BLOCK] IN=enp5s0 OUT= MAC=d8:cb:8a:f1:4b:f2:f0:18:98:87:34:94:08:00 SRC=192.168.0.70 DST=192.168.0.20 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=49611 DPT=22000 WINDOW=65535 RES=0x00 SYN URGP=0
Feb 01 15:21:57 hypermulti kernel: audit: type=1131 audit(1549056117.773:77): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 01 15:22:00 hypermulti kernel: audit: type=1131 audit(1549056120.387:78): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tlp-sleep comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 01 15:22:05 hypermulti kernel: [UFW BLOCK] IN=enp5s0 OUT= MAC= SRC=fe80:0000:0000:0000:dacb:8aff:fef1:4bf2 DST=ff12:0000:0000:0000:0000:0000:0000:8384 LEN=117 TC=0 HOPLIMIT=1 FLOWLBL=532220 PROTO=UDP SPT=55265 DPT=21027 LEN=77
Feb 01 15:22:19 hypermulti kernel: [UFW BLOCK] IN=enp5s0 OUT= MAC=d8:cb:8a:f1:4b:f2:18:a6:f7:31:9a:0b:08:00 SRC=68.189.39.189 DST=192.168.0.20 LEN=132 TOS=0x00 PREC=0x00 TTL=113 ID=42275 PROTO=UDP SPT=6881 DPT=60831 LEN=112
Feb 01 15:22:29 hypermulti kernel: atkbd serio0: Unknown key pressed (translated set 2, code 0x97 on isa0060/serio0).
Feb 01 15:22:29 hypermulti kernel: atkbd serio0: Use 'setkeycodes e017 <keycode>' to make it known.
Feb 01 15:22:29 hypermulti kernel: atkbd serio0: Unknown key released (translated set 2, code 0x97 on isa0060/serio0).
Feb 01 15:22:29 hypermulti kernel: atkbd serio0: Use 'setkeycodes e017 <keycode>' to make it known.

So it looks like it does wake up, but the monitor just doesn't turn back on anymore for some reason?

Offline

#6 2019-02-01 22:37:22

loqs
Member
Registered: 2014-03-06
Posts: 17,196

Re: Kernel panics on resume from suspend since upgrading to linux 4.20

Can you ssh into the system after resume with blank screen or power it off cleanly using the power button to confirm the system has resumed with the exception of the display?

Offline

#7 2019-02-01 22:47:23

seth
Member
Registered: 2012-09-03
Posts: 49,992

Re: Kernel panics on resume from suspend since upgrading to linux 4.20

Does it work w/o any graphical session running?
(This is probably tied to the nvidia blob, GUI and especially GL would provoke it)

Offline

#8 2019-02-02 00:03:37

defaultxr
Member
Registered: 2013-02-12
Posts: 8

Re: Kernel panics on resume from suspend since upgrading to linux 4.20

For the log I posted, I was powering it off with the power button. It didn't seem to respond to just pressing it, I had to hold it to get it to power down.

Actually, I just tried suspending and resuming while logged into a graphical session, and it worked totally fine. Whereas when I was testing suspend/resume previously, I was just doing it at the virtual terminal, before I launched X. So it seems like having X running makes it work better than being at tty. Unfortunately, this is still while everything is reverted to the old versions, so it's not really a solution I guess.

Offline

Board footer

Powered by FluxBB