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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
