Bug description: When rotating the screen to the left or right using e.g. "xrandr -o left", it goes blank. I am no longer able to use Ctrl+Alt+F<n> for switching to a console, but the machine is still reachable over network. It also does not switch back when calling a shell command like "xrandr -o left; sleep 10; xrandr -o normal". "xrandr -o inverted" works as expected, but calling "xrandr -o normal" afterwards also causes the screen to go blank. The monitor is connected through LVDS, I was not able to configure the machine to deliver any output on DP/HDMI/DVI despite trying all BIOS options. I use Debian Jessie, but quick check with some live cds revealed, that also Fedora and Ubuntu are affected when the kernel version matches. Bisect revealed that first commit which showed this behaviour is: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1 It is still present in today's mainline kernel. System environment: -- chipset: i915 I guess (the one included in Intel Atom E3825) -- system architecture: x86_64 package versions (all from debian jessie): -- libdrm version: 2.4.56-1 -- xserver-xorg-video-intel (from debian jessie): 2:2.21.15-2+b2 -- xserver-xorg version: (from debian jessie): 1:7.7+7 -- Kernel version: Since 77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1 at least until today's mainline (dfe2c6dcc8ca2cdc662d7c0473e9811b72ef3370) -- Machine model: Can't tell details about the product, but it contains an Intel Atom E3825 CPU and is quite standard apart from that. See attached cpuinfo and lspci for the details. -- Display connector: LVDS Please let me know if you need any further information.
Created attachment 107800 [details] Contents of /proc/cpuinfo
Created attachment 107801 [details] lspci output
Created attachment 107802 [details] xorg log for properly working version
Created attachment 107803 [details] xorg log for defective version
Downstream bug at debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764445
Can you please boot using "drm.debug=0xe" as Kernel parameters (you can pass it from Grub), then reproduce the bug, run "dmesg > dmesg.txt" and attach the file here?
Created attachment 107823 [details] dmesg output with drm.debug=0xe
In the attached debug output, the rotation attempt should have happend somewhere around 42.648 according to xorg log output.
Hi Paulo, can we think this bug is a duplicated as bug #84310?
Probably not a duplicate of that one since the platforms are very different.
Reverting this single method call (which was added as part of the bisected patch) from the 3.17.1 kernel makes rotation work again: diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index d8324c6..057b6be 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4609,7 +4609,6 @@ static void valleyview_modeset_global_resources(struct drm_device *dev) if (req_cdclk != dev_priv->vlv_cdclk_freq) valleyview_set_cdclk(dev, req_cdclk); - modeset_update_crtc_power_domains(dev); }
The hardware has DisplayPort only, no DisplayPort++ which would allow me to connect using a passive DP->HDMI cable. Now I finally got my hands on a DisplayPort monitor, and the rotation works there. So the issue affects LVDS only.
Should be fixed with commit 50f6e502718fd187f8e11a7b5048b21f85ac77e4 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Nov 6 14:49:12 2014 +0200 drm/i915: Move the .global_resources() hook call into modeset_update_crtc_power_domains() The patch is unfortunately only in drm-intel-nightly heading towards 3.19. Backporting might become messy, but we can try if this is confirmed. If the bug still exists on latest drm-intel-nightly then please reopen.
I just tried with commit 50f6e502718fd187f8e11a7b5048b21f85ac77e4 from drm-intel-nightly. It seems that I am running into a different issue, the screen goes blank before even attempting to rotate, and dmesg show a call trace. I can provide all the details about this issue. Please let me know whether you would like to have the information attached here or in a separate bug report.
Let's assume for now it's the same thing in different disguise, so please attach the new logs here for now.
(In reply to ws from comment #0) > The monitor is connected through LVDS, I was not able to configure the > machine to deliver any output on DP/HDMI/DVI despite trying all BIOS options. VLV does not have LVDS. What does 'lspci -nns 02' say? Please include dmesg from boot with drm.debug=14 module parameter set.
Output of lspci -nns 02: 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0c)
Created attachment 109663 [details] [50f6e50] dmesg output with debug.drm=0xe
Created attachment 109664 [details] [50f6e50] dmesg output without debug.drm=0xe Attaching this as well, I could not find the message with debug.drm=0xe in the logs.
drm.debug=14 please
(In reply to Jani Nikula from comment #20) > drm.debug=14 please Sorry, jumped the gun seeing debug.drm in the comment. Please ignore.
Created attachment 109666 [details] [50f6e50] dmesg output with drm.debug=14 My fault, this is with the right parameters now. The call trace is still not shown here, but drm messages are more verbose now.
What kind of machine is this? Where is the LVDS connected you speak of? The dmesg says you have a DP branch device, possibly a converter of some sort.
It's a MB-Q7-2 baseboard with a conga-QA3 on it. I don't know the details of the hardware, e.g. which converter is placed on which of the boards.
These appear to be the products: http://www.tq-group.com/en/products/product-details/prod/mb-q7-2-fuer-qseven/extb/Main/productdetail/ http://www.congatec.com/en/products/qseven/conga-qa3.html The data sheet for the QA3 references NXP PTN3460 which is probably this one: http://www.nxp.com/products/interface_and_connectivity/displayport/high_speed_multiplexer/PTN3460BS.html This is really quite out of the ordinary hardware. I do find it amusing they've gone out of their way to add an eDP->LVDS converter to the design, yet repeatedly advertise it as "legacy free" in the web page.
Presuming the log from comment #22 is with just the eDP->LVDS output, the VBT on the thing doesn't indicate that port C is eDP. What if you try this hack patch: diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 6421593d95de..e5ab5f2ee879 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4527,7 +4527,7 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port port) [PORT_D] = PORT_IDPD, }; - if (port == PORT_A) + if (port == PORT_C) return true; if (!dev_priv->vbt.child_dev_num)
With this patch applied, nothing obvious changes, the screen still goes blank even before attempting the rotation. The call trace in the dmesg output is gone however.
(In reply to ws from comment #27) > With this patch applied, nothing obvious changes, the screen still goes > blank even before attempting the rotation. The call trace in the dmesg > output is gone however. Just as note: I did not actually apply the patch, I made the same change manually to 50f6e502718fd187f8e11a7b5048b21f85ac77e4. Did not find the revision to which this patch should be applied directly.
Can you please try to retest latest drm-intel-nightly from http://cgit.freedesktop.org/drm-intel
Just tried it, screen still goes blank before attempting to rotate. Do you require any log output?
(In reply to ws from comment #30) > Just tried it, screen still goes blank before attempting to rotate. Do you > require any log output? Before even attempting to rotate? Or while trying to rotate? Big difference here ;-) Also what happens if you try normal modeset (different resolutions)?
Yes, before even attempting to rotate. This is what happened for each kernel since 3.17 if I recall correctly. I mentioned it in comment 14.
(In reply to ws from comment #32) > Yes, before even attempting to rotate. This is what happened for each kernel > since 3.17 if I recall correctly. I mentioned it in comment 14. Just for info, I'm not exactly sure from which version on this happened. If required, I can do bisecting once again. I guess it is a different bug, that's why I asked whether I should open a new bug for that issue.
Well just dropping rotate from the summary should be enough since now it's misleading. Still looks like something just falls over on modesets.
(In reply to Daniel Vetter from comment #31) > Also what happens if you try normal modeset (different resolutions)? You mean setting the resolution as a kernel parameter or XOrg configuration? Where do I find information about what resolutions make sense? The display is a G104X1-L04 from Data Modul with a resolution of 1024x768.
What happens on drm-intel-nightly? Does the initial boot work, or do you end up with a blank screen? If booting up works, does rotation work?
(In reply to ws from comment #14) > I just tried with commit 50f6e502718fd187f8e11a7b5048b21f85ac77e4 from > drm-intel-nightly. It seems that I am running into a different issue, the > screen goes blank before even attempting to rotate, and dmesg show a call > trace. I can provide all the details about this issue. Please let me know > whether you would like to have the information attached here or in a > separate bug report. I think a bisect on this additional regression might be interesting. Otherwise we pretty much have no chance with this on here I fear.
I just tried with a drm-intel-nightly from yesterday (commit 762f876e5a6f4f1a8b5a8e19d4bdd1309c372ed4), and it seems to be back to the original problem. Boot works, I get a proper display, and rotation makes the screen go blank. The problem from comment 14 seems to be gone now.
Just tried the patch below, it makes everything work for me: diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 90b460c..b5b50e3 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4857,8 +4857,6 @@ static void modeset_update_crtc_power_domains(struct drm_device *dev) crtc->enabled_power_domains = pipe_domains[crtc->pipe]; } - - intel_display_set_init_power(dev_priv, false); } /* returns HPLL frequency in kHz */
I have a packard bell easynote TE69BM laptop. It seems that the graphic card in this laptop is reported the same as above in this bug, so it is a similar or the same one, and I think it may be the same bug. Everything works perfectly until I rotate the screen, then rotation itself works but screen goes blank (just shows a cursor). Switching to a vt and back fixes the issue until a next attempt of rotation. I didn't test all possible combinations, but I tested inverting the screen and back. The display being rotated is a builtin laptop one.
(In reply to Michał Zegan from comment #40) > I have a packard bell easynote TE69BM laptop. > It seems that the graphic card in this laptop is reported the same as above > in this bug, so it is a similar or the same one, and I think it may be the > same bug. > Everything works perfectly until I rotate the screen, then rotation itself > works but screen goes blank (just shows a cursor). Switching to a vt and > back fixes the issue until a next attempt of rotation. > I didn't test all possible combinations, but I tested inverting the screen > and back. > The display being rotated is a builtin laptop one. Michał, what does 'lspci -nns 02' say for you?
All, please try current drm-intel-nightly from http://cgit.freedesktop.org/drm-intel, we have some fixes there.
(In reply to Jani Nikula from comment #42) > All, please try current drm-intel-nightly from > http://cgit.freedesktop.org/drm-intel, we have some fixes there. And I suppose that in the last 6 months we got even more fixes. Can anybody please retest and report the results?
This issue is not longer occurs on BYT and eDP panel with the following configuration Hardware information ==================== Platform : BYT-M (Toshiba) Motherboard model : Satellite C55t-A Motherboard type : Portable PC Notebook Motherboard manufacturer : TOSHIBA CPU family : Atom CPU information : Intel(R) Celeron(R) CPU N2820 @ 2.13GHz GPU Card : Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0c) (prog-if 00 [VGA controller]) Memory ram : 4 GB Software information ===================== --> Component : drm url : http://cgit.freedesktop.org/mesa/drm tag : libdrm-2.4.67-7-g49041c3 commit : 49041c3 author : Rob Clark <robclark@freedesktop.org> age : 4 weeks ago --> Component : mesa url : http://cgit.freedesktop.org/mesa/mesa tag : mesa-11.1.2 commit : 7bcd827 author : Emil Velikov <emil.velikov@collabora.com> age : 6 weeks ago --> Component : xf86-video-intel url : http://cgit.freedesktop.org/xorg/driver/xf86-video-intel tag : 2.99.917-579-g74cd4d0 commit : 74cd4d0 author : Chris Wilson <chris@chris-wilson.co.uk> age : 6 days ago --> Component : libva url : http://cgit.freedesktop.org/libva/ tag : libva-1.7.0-1-g2339d10 commit : 2339d10 author : Xiang Haihao <haihao.xiang@intel.com> age : 6 days ago --> Component : vaapi (intel-driver) url : http://cgit.freedesktop.org/vaapi/intel-driver tag : 1.7.0-5-g759e44d commit : 759e44d author : peng.chen <peng.c.chen@intel.com> age : 7 days ago --> Component : cairo url : http://cgit.freedesktop.org/cairo tag : 1.15.2 commit : db8a7f1 author : Bryce Harrington <bryce@osg.samsung.com> age : 3 months ago --> Component : xserver url : http://cgit.freedesktop.org/xorg/xserver tag : xorg-server-1.18.0-247-ga288cf5 commit : a288cf5 author : Dave Airlie <airlied@redhat.com> age : 7 days ago --> Component : intel-gpu-tools url : http://cgit.freedesktop.org/xorg/app/intel-gpu-tools tag : intel-gpu-tools-1.14-115-g7fc5256 commit : 7fc5256 author : Lionel Landwerlin <lionel.g.landwerlin@intel.com> age : 4 days ago kernel information =================== Branch = drm-intel-nightly commit 4b39223f6e3bef4dfa678f7239dcd87c38e20e96 Author: Matt Roper <matthew.d.roper@intel.com> Date: Mon Mar 21 11:44:01 2016 -0700 drm-intel-nightly: 2016y-03m-21d-18h-43m-18s UTC integration manifest
I am leaving INTEL. Please, could you work with your INTEL FAEs to find the best possible replacement for me. Liebe Kunden, bitte notieren Sie, ich bin aus. Ich wieder zuruck stehe nie. Ich wunshe Am Besten zu alle. Thank you/Danke, Zoran Stojsavljevic
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.