Panic after S3 resume and modeset with MST

Takashi Iwai
2017-03-27T16:02:15Z

Hi,

the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
drm/i915: Call intel_dp_mst_resume() before resuming displays

seems to trigger a kernel panic when some modeset change happens after
S3 resume. The details are found in openSUSE bugzilla,
https://bugzilla.suse.com/show_bug.cgi?id=1029634

In short, the following procedure causes a kernel panic (supposedly)
almost 100% on Dell Latitude with Skylake with MST DP on dock:

- Boot with a docking station, DP-1 connected.
- Login on X
- xrandr --output eDP-1 --primary --auto --output DP-1-1 --auto --left-of eDP-1
==> This changes the mode.
- Suspend ("systemctl suspend" in my case), and close the lid.
- Remove from the dock (keep the lid closed).
- Open the lid, which resumes automatically. It works.
- Suspend again.
- Connect to the dock again (keep the lid closed).
- Open the lid, which resumes automatically. It's still OK.
- xrandr --output eDP-1 --primary --auto --output DP-1-1 --auto --left-of eDP-1
==> Now the kernel feezes.

Reverting the commit mentioned above fixes the problem.

The problem is present in all versions I tested. The reported kernel
in the Bugzilla is 4.4.x-based one, but the issue is seen in 4.11-rc3,
too. Note that the S3 resume itself works in 4.11-rc3; the kernel
panic happens when invoking xrandr manually after that.

Unfortunately, I couldn't get a kernel panic message, so far. kdump
didn't work well in this case by some reason. There are some
screenshots taken by the original reporter (could switch VT
beforehand), but I don't know whether it helps.

If you have any hints for further debugging, it'd be highly
appreciated.

thanks,