Date: Wed, 04 May 2022 03:57:01 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 263632] framework laptop crashes a few seconds after resuming from sleep Message-ID: <bug-263632-227-gVCC5ivWdr@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-263632-227@https.bugs.freebsd.org/bugzilla/> References: <bug-263632-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263632 --- Comment #10 from Jonathan Vasquez <jon@xyinn.org> --- Some interesting updates. So it seems that it may not be the kernel that's crashing (yet) but the X server in combination with the kernel.. basically the behavior that I'm experiencing can be reproduced (non-deterministically but it will happen) i= f I do: xrandr --output eDP-1 --scale 0.8 You can use any other number as well. As long you cause frequent changes, it will eventually happen. Now something that's further interesting is that on= ce it locks up, pressing keys or moving your mouse won't work. Attempting to switch to a virtual terminal also won't work, or at least it would seem lik= e it didn't. The first interesting thing I noticed was that even though I wasn't able to do much after it locked up, if I pressed the power button, the syst= em actually received the signal and I could see my tty1 again and the system eventually shuts down. So that would indicate that the kernel hasn't actual= ly crashed. I also saw the following message (same as before but with another line): drmn0: GPU HANG: ecode 12:1:85dffffb, in MainThread [100328] drmn0: Resetting rcs0 for stopped heartbeat on rcs0 drmn0: Xorg[100328] context reset due to GPU hang The second interesting thing was that once I got it locked again, I was actually able to - eventually - switch to a TTY. I just kept pressing Ctrl + Alt + F[1-4] until one of them got through to the system. Lastly, after the system got locked, I managed to switch to a TTY and then = kill X, and start another session immediately. Once I locked it for a second tim= e in a row, my system was truly frozen and I had no chance of switching to a TTY= and the power button also stopped getting its shutdown signal through to the kernel. I had to hard power off the machine. So it's interesting that a sec= ond "hard crash" managed to be worse than the first, as if there was some remna= nt state that managed to worsen things. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-263632-227-gVCC5ivWdr>