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@xxxxxxxxxxxxxxxxxxx> 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
