This is interesting. I will store this in my notes too. The issue is I am working on a laptop and so dont have a serial port. But I think I have found the problem. I am soaking it for now, I will respond to the thread if my hunch works. Thanks, Prateek Sefa Eyeoglu via arch-general <arch-general@lists.archlinux.org> writes:
I recently had a similar issue.
As it was breaking my workflow for day-to-day use I investigated the issue.
If the computer is unresposive while resuming it's very likely to be a kernel panic.
If there is no display output at all, either the graphics driver itself causes the panic, or some kernel module before that.
The only way to debug these kinds of kernel panics was to use a serial port and a second computer to get a tty.
As most computers have a COM-header on the mainboard, it's fairly easy to get things connected. I purchased a COM-RS232 PCIe Shield and found a Serial to USB adapter at home.
I then set the following kernel cmdline
no_console_suspend console=tty0 console=ttyS0,115200
no_console_suspend was needed in my case, but it might not be needed in all cases, I am sure it's not recommended to always have that enabled, but as we are debugging here we should be fine.
The two console= arguments set the console (kernel log, systemd log and panics) to both tty0 (the default) as well as ttyS0 at a baud of 115200 (Check if ttyS0 is your serial port while booted).
Now you can get your USB-Serial adapter, connect it with your computer's COM port and start a serial console like screen, minicom or picocom.
Now you should see the kernel log while booting. You can even have getty on there to login via serial. (I don't know right now if it is autostarted or if you need to start it manually with systemctl start getty@ttyS0.service)
Now you can get to debugging: Reproduce your issue and see what you get there.
P.S. There are other ways to see the console without working graphics. There is USB-3.0 debugging (couldn't get that to work myself) and netconsole (didn't work for my issue, maybe it wasn't initialised before the panic)
P.S.P.S. I planned to write this process up somewhere, I guess having it here is a start. I may create a Wiki article about this in the future.
P.S.P.S.P.S. My issue was an actual kernel bug, which I fixed and got merged with recent 5.11 and 5.12 releases. See https://git.kernel.org/pub/scm/linux/kernel/git/ torvalds/linux.git/commit/?id=7df4ceb60fa9a3c5160cfd5b696657291934a2c9
Hello All,
After upgrading to the new kernel I see that my system freezes when I try to resume from sleep. This happens intermittently but frequent enough to be irritating. I have to reboot the system to recover.
I am running kernel 5.12.7-arch1-1
The issue was not seen with kernel 5.11.
I am running arch on btrfs and I suspect it is a btrfs issue somehow. When I check dmesg (journactl --dmesg --boot -1) I see that it always ends with the following two lines when the issue is seen.
May 29 07:12:40 matrix kernel: PM: suspend entry (deep) May 29 07:12:40 matrix kernel: Filesystems sync: 0.025 seconds
I wanted to know how do I attempt to debug this issue?
Regards, Prateek