https://bugzilla.suse.com/show_bug.cgi?id=1207948 https://bugzilla.suse.com/show_bug.cgi?id=1207948#c14 --- Comment #14 from Jiri Slaby <jslaby@suse.com> --- (In reply to Martin Jambor from comment #9)

...

Does pstore store anything to efi afterall?

I tried following https://blogs.oracle.com/linux/post/pstore-linux-kernel-persistent-storage- file-system

I got as far as "cat /sys/module/pstore/parameters/backend" resulting in "efi" but no file ever appeared in /sys/fs/pstore

Weird. It would be also some /sys/firmware/efi/efivars/[Dd]ump*. But apparently, nothing is logged. Is the service running: systemctl status systemd-pstore.service ?

...

Do you have kdump set up?

I don't think so. So no, unless it is somehow on default.

It should be a matter of zypper in kdump systemctl enable kdump Add something like crashkernel=192M to the kernel commandline. Reboot systemctl status kdump /sys/kernel/kexec_loaded should return 1. /boot/initrd-kdump should exist crash it by s2disk /var/crash should contain a folder after a crash. The blinking LED should not happen, the kdump kernel should be loaded instead. Thinking about it, it probably won't work. The resume kernel+initrd probably didn't manage to load kdump yet at this phase. Or maybe it jumped to the suspended kernel already and the suspended kernel crashes. In which case it could work. (In reply to Martin Jambor from comment #12)

(In reply to Jiri Slaby from comment #6)

...

Yeah and I also asked you about: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/ Documentation/power/basic-pm-debugging.rst

What last step (from [freezer, devices, ...]) does not expose the crash?

None of them exposes it - even "core" returns fine without any problems - except for "none" which of course results in the panic.

Which means the BIOS does something weird during suspend. Or kernel does something weird during resume.

Funny thing, when triggering the suspend with

echo platform > /sys/power/disk echo disk > /sys/power/state

(as opposed to "systemctl hibernate") the virtual console echo works at the end of the unsuccessful resuming from disk. I.e. I can see the letters I type - but there is no reaction from bash or anything, the next bash prompt is not displayed either - until the panic when everything stops... is it perhaps some watchdog that is triggering it?

Another note: klog.service makes tty10 the console. Can you comment out the whole line containing /usr/bin/setlogcons in /usr/lib/systemd/system/klog.service? And also ignore_loglevel or loglevel=7 kernel parameters could help to show something (added on top of no_console_suspend). -- You are receiving this mail because: You are on the CC list for the bug.