[Intel-gfx] Panic after S3 resume and modeset with MST

Takashi Iwai tiwai at suse.de
Mon Mar 27 16:02:13 UTC 2017


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,

Takashi


More information about the Intel-gfx mailing list