Bug 90077

Summary: 180° rotation results in a black screen and kernel errors
Product: DRI Reporter: Rui Tiago Matos <tiagomatos>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: intel-gfx-bugs
Version: unspecified   
Hardware: Other   
OS: All   
i915 platform: i915 features: display/Other

Description Rui Tiago Matos 2015-04-17 18:01:41 UTC
Using the intel DDX 2.99.917 on a HD Graphics 4400.

When doing a 180 rotation using gnome-control-center I'm getting a black screen and the kernel errors below. Yet, using xrandr --output eDP1 --rotate inverted everything works fine.

In GNOME, it's mutter that ends up calling XRRSetCrtcConfig and both in that case and with xrandr, the arguments to XRRSetCrtcConfig are exactly the same, they look like:

Breakpoint 1, XRRSetCrtcConfig (dpy=0x1cd5a80, resources=0x6276800, crtc=63, timestamp=0, x=0, y=0, mode=77, rotation=4, outputs=0x72a0ce0, noutputs=1) at XrrCrtc.c:126

in both cases. So, I'm stumped as to why one works and the other doesn't. Here's the journal output when it fails:

gdm-Xorg-:0[3533]: (II) intel(0): switch to mode 1366x768@60.0 on eDP1 using pipe 0, position (0, 0)...n none
kernel: [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe A
kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

If I then lock/unlock the session, which turns DPMS off and back on again I get regular output back (i.e. stops being black) and the following kernel trace:

kernel: ------------[ cut here ]------------
kernel: WARNING: CPU: 0 PID: 3533 at drivers/gpu/drm/i915/intel_display.c:1256 assert_plane.constp...[i915]()
kernel: plane A assertion failure (expected on, current off)
kernel: Modules linked in: synaptics_usb ccm rfcomm fuse arc4 intel_rapl iosf_mbi x86_pkg_temp_the...obuf2_me
kernel: CPU: 0 PID: 3533 Comm: Xorg Tainted: G        W      3.19.0-1.fc22.x86_64 #1
kernel: Hardware name: LENOVO 20AMS22U0C/20AMS22U0C, BIOS GIET72WW (2.22 ) 03/25/2014
kernel:  0000000000000000 0000000073d612f6 ffff880213effb28 ffffffff817761b3
kernel:  0000000000000000 ffff880213effb80 ffff880213effb68 ffffffff8109bbfa
kernel:  ffff8800371a0000 0000000000000000 ffff8800371a0000 ffff8800c8d94800
kernel: Call Trace:
kernel:  [<ffffffff817761b3>] dump_stack+0x45/0x57
kernel:  [<ffffffff8109bbfa>] warn_slowpath_common+0x8a/0xc0
kernel:  [<ffffffff8109bc85>] warn_slowpath_fmt+0x55/0x70
kernel:  [<ffffffffa0142c94>] assert_plane.constprop.85+0x74/0xb0 [i915]
kernel:  [<ffffffffa014a2e3>] hsw_disable_ips+0x33/0x190 [i915]
kernel:  [<ffffffffa014a6c8>] intel_crtc_disable_planes+0x48/0x140 [i915]
kernel:  [<ffffffff810c565d>] ? ttwu_do_activate.constprop.91+0x5d/0x70
kernel:  [<ffffffffa014b450>] haswell_crtc_disable+0x40/0x390 [i915]
kernel:  [<ffffffffa014c669>] intel_crtc_control+0x59/0x120 [i915]
kernel:  [<ffffffffa014c791>] intel_crtc_update_dpms+0x61/0x70 [i915]
kernel:  [<ffffffffa0152309>] intel_connector_dpms+0x69/0x80 [i915]
kernel:  [<ffffffffa003ecea>] drm_mode_obj_set_property_ioctl+0x36a/0x370 [drm]
kernel:  [<ffffffffa003ed2f>] drm_mode_connector_property_set_ioctl+0x3f/0x60 [drm]
kernel:  [<ffffffffa002ea8b>] drm_ioctl+0x1db/0x640 [drm]
kernel:  [<ffffffff8140fc62>] ? brightness_store+0xf2/0x120
kernel:  [<ffffffff81231476>] do_vfs_ioctl+0x2c6/0x4d0
kernel:  [<ffffffff8121f101>] ? __sb_end_write+0x21/0x70
kernel:  [<ffffffff81231701>] SyS_ioctl+0x81/0xa0
kernel:  [<ffffffff8113f9e6>] ? __audit_syscall_exit+0x1f6/0x2a0
kernel:  [<ffffffff8177c969>] system_call_fastpath+0x12/0x17
kernel: ---[ end trace 75b0c3fa16143d67 ]---
Comment 1 Chris Wilson 2015-04-17 18:14:52 UTC
It's not the call to set the rotation that matters, but a preceding one. The issue is that a regression slipped into 3.19 that caused the kernel to think that the first rotation was of a 0x0 plane.
Comment 2 Jani Nikula 2015-08-18 14:32:43 UTC
(In reply to Chris Wilson from comment #1)
> It's not the call to set the rotation that matters, but a preceding one. The
> issue is that a regression slipped into 3.19 that caused the kernel to think
> that the first rotation was of a 0x0 plane.

Which one is that exactly? Has it been fixed since? Can we close this one?
Comment 3 Rui Tiago Matos 2015-08-18 14:40:58 UTC
This seems fixed at least as of 4.1.4 .
Comment 4 Jani Nikula 2015-08-18 15:51:53 UTC
Thanks for the follow-up!
Comment 5 Jari Tahvanainen 2016-10-10 11:54:57 UTC
Closing resolved+fixed based on "This seems fixed..." by Reporter.

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.