https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #9 from Sergey Kondakov (virtuousfox@gmail.com) --- (In reply to Nicholas Kazlauskas from comment #1)
Do you mind posting an dmesg log with drm=debug=4 as part of your boot parameters?
An xorg log would be good too if applicable.
I'm curious to know what the actual sequence / system setup is for reproducing this as this isn't really a typical sequence. I think you'd run into other NULL pointer dereferences even if this one is guarded.
I think the stream itself is NULL and it shouldn't be in the context.
I don't think that putting 'drm=debug=4' into boot cmd has changed anything but here's some more data. I also stumbled into another baffling regression (bug #203703) recently (from 5.0 to 5.1) concerning network packet scheduling (fq_codel qdics) that halts affected Ethernet device, it also gives out repeatable kernel trace on random network activity unless qdics is changed on dumb "pfifo_fast" early on, similarly how this gives out same repeatable amdgpu trace on some random GPU activity. Weird.