Commen=
t # 8
on bug 11067=
4
from Chris Hodapp
I've actually found another crash which triggers pretty prompt=
ly whenever I
play (presumably-accelerated) YouTube videos. I'll attach dmesg and
display-manager.service logs for that crash here but I'm happy to file them=
as
a separate bug upon request.
I'm also going to go ahead and upload *another* set of logs from an event w=
hich
happens from time to time where I get blocks of vaporwave-looking colored
blocks mixed with garbled past-images (presumably hanging around in freed
memory). I didn't include this before because I mistakenly thought that the
dmesg output was the same as for the original less-visually-striking lock-u=
ps
that I described up front. However, it's not clear that I was wrong about t=
hat.
Anyway, like I said, I'm going to post these logs too and, once again, I'm
happy to move them to a separate bug upon request.
I'll also describe my technique for capturing these logs, in case it matter=
s:
When these crashes happen, my first response is to try and shift to a diffe=
rent
(text-mode) virtual console to capture the logs. When that works, I save off
the logs and then reboot. However, sometimes the crash is so bad that I'm n=
ot
able to switch to a text-mode virtual console, in which case I have to hard=
-cut
the power and capture the logs retroactively with `journalctl` and a negati=
ve
boot-number arg. I was able to capture the original log by switching virtual
consoles but both of these new ones were captured after a reboot with
`journalctl`.