Created attachment 126907 [details] dmesg output when booting the drm-nightly kernel I have been able to use both builtin screen and an external monitor on my Surface Pro 4 up until and including kernel 4.7. However 4.8-rc8 as well as drm-nightly from Thursday evening (Sept 29) does not at all present the external monitor when I do xrandr and it is black. x86_64 4.8.0-rc8-mssp4+ Debian Stretch Surface Pro 4 eDP-1 works but DP-1 is not visible (as it is for 4.7) Attaching dmesg.
Can you bisect please?
It might take a while before I could do that (busy!). Any hints regarding possible culprit commits?
Changed as Highest+Blocker due to regression w/o workaround
OK, so it seems like it is commit 731c7d3a in the drm-intel-nightly log which introduces the problem. Note that I did this bisecting manually, because git bisect got lost (or did it?) in June somewhere. However, I of course realize that 731c7d3a is not very precise since it is merged in. Stopping here, anyway, due to limited knowledge of how to bisect.
Hmm... I just learnt that git bisect is merged-branch-aware, so I guess I should simply let it run until it gives me a final answer. I'll do that.
git bisect gives fce91f2 which is about guc. I then realized that I had the following line in my i915.conf: options i915 enable_guc_submission=Y guc_log_level=3 When I remove these options, the display port output starts to work also for later kernels, such as 4.8.0-rc8, i.e. the problem disappears. But this is still a bug, right? It seems strange that DP output disappears just because guc is enabled.
(In reply to Mikael Djurfeldt from comment #6) > git bisect gives fce91f2 which is about guc. > > I then realized that I had the following line in my i915.conf: > > options i915 enable_guc_submission=Y guc_log_level=3 > > When I remove these options, the display port output starts to work also for > later kernels, such as 4.8.0-rc8, i.e. the problem disappears. > > But this is still a bug, right? It seems strange that DP output disappears > just because guc is enabled. [ 9.190503] i915: `Y' invalid for parameter `enable_guc_submission' so looks like it refused to even load the module with the invalid knob in place. That behaviour is slightly amusing since you can pass non-existing modparams just fine, but apparently trying to pass an invalid value for a modparam that does exist is fatal.
Yes---ahem, sorry for missing this. Please do whatever you find suitable with this "bugreport".
(In reply to Mikael Djurfeldt from comment #8) > Yes---ahem, sorry for missing this. > > Please do whatever you find suitable with this "bugreport". The way the kernel fails with invalid parameter values is indeed silly, but considering that module parameters in general have sharp edges and you need to know what you're doing, and especially this specific parameter being "unsafe", I'll just close this bug. Works as expected, although what is expected may seem a bit unexpected. ;)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.