(In reply to Maks Verver from comment #0)
> Created attachment 132716 [details]
> /sys/class/drm/card0/error

Hello Maks,
Could you please add dmesg with parameter drm.debug=0xe on grub, HW and SW specs and steps to reproduce as indicated here: https://01.org/linuxgraphics/documentation/how-report-bugs
Thank you.

(In reply to Elizabeth from comment #1)
> (In reply to Maks Verver from comment #0)
> > Created attachment 132716 [details]
> > /sys/class/drm/card0/error
> 
> Hello Maks,
> Could you please add dmesg with parameter drm.debug=0xe on grub, HW and SW
> specs and steps to reproduce as indicated here:
> https://01.org/linuxgraphics/documentation/how-report-bugs
> Thank you.

Asking this on a GPU hang is pointless, unless in the very unlikely event that they are reproducible. The whole point of the error state is that we capture sufficient information for post-mortem debugging. If you would like more information, that is where we need it.

There is nothing unusual in the rings, batch, buffers or engine state. Looks like we have the joy of discovering a new kbl feature, but we need more hangs to start establishing the pattern.

For hysterical reasons, could you please try booting with i915.enable_dmc=0 on the kernel commandline (i.e. passed by grub), or via modprobe.

(In reply to Chris Wilson from comment #2)
> Asking this on a GPU hang is pointless, unless in the very unlikely event
> that they are reproducible. The whole point of the error state is that we
> capture sufficient information for post-mortem debugging. If you would like
> more information, that is where we need it.
Understood, thanks for the info.

(In reply to Chris Wilson from comment #4)
> For hysterical reasons, could you please try booting with
> i915.enable_dmc=0

Should be i915.enable_dc=0

> on the kernel commandline (i.e. passed by grub), or via modprobe.

FYI, I haven't noticed this issue any more.

I'll close the bug since I can't reproduce the issue. I'll reopen the bug if it shows up again. Thanks for your time.