[Bug 107827] New: [Regression] [bisected] drm/atomic: "plane A assertion failure" after lid close/lid open on older Intel Mobile GME965/GLE960
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Sep 4 21:32:29 UTC 2018
https://bugs.freedesktop.org/show_bug.cgi?id=107827
Bug ID: 107827
Summary: [Regression] [bisected] drm/atomic: "plane A assertion
failure" after lid close/lid open on older Intel
Mobile GME965/GLE960
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: DRM/Intel
Assignee: intel-gfx-bugs at lists.freedesktop.org
Reporter: dri at kiffy.de
QA Contact: intel-gfx-bugs at lists.freedesktop.org
CC: intel-gfx-bugs at lists.freedesktop.org
Hello maintainers,
Recently Kernel 4.17.17 trickeled down to me via Debian backports. After
closing and opening the lid on my older HP Compaq 6720s laptop with Mobile
GME965/GLE960 graphics I get garbled screen output and the following error:
systemd-logind[486]: Lid closed.
kernel: pci 0000:00:1e.0: PCI bridge to [bus 02]
systemd-logind[486]: Lid opened.
kernel: pci 0000:00:1e.0: PCI bridge to [bus 02]
kernel: ------------[ cut here ]------------
kernel: plane A assertion failure (expected on, current off)
kernel: WARNING: CPU: 0 PID: 726 at drivers/gpu/drm/i915/intel_display.c:1274
assert_plane+0x87/0x90 [i
kernel: Modules linked in: ctr ccm fuse cpufreq_userspace cpufreq_conservative
cpufreq_powersave arc4 i
kernel: e1000e usbcore fan thermal
kernel: CPU: 0 PID: 726 Comm: Xorg Not tainted 4.18.5 #1
kernel: Hardware name: Hewlett-Packard HP Compaq 6720s/30D8, BIOS 68MDU Ver.
F.0D 11/04/2008
kernel: RIP: 0010:assert_plane+0x87/0x90 [i915]
kernel: Code: b5 af c0 84 c0 48 c7 c2 a1 b5 af c0 48 89 f1 48 c7 c7 20 e7 b0 c0
48 0f 44 ca 40 84 ed 48
kernel: RSP: 0018:ffffb38000b5bb08 EFLAGS: 00010282
kernel: RAX: 0000000000000000 RBX: ffff96e4f5ebf800 RCX: 0000000000000006
kernel: RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff96e4ffc16730
kernel: RBP: 0000000000000001 R08: 00000000000787af R09: 000000000000030c
kernel: R10: ffffed2c84dfbf40 R11: ffffffffb89a2f4d R12: 0000000000000000
kernel: R13: ffff96e3f672b000 R14: 0000000000000002 R15: ffff96e4f8758328
kernel: FS: 00007f332ae69a40(0000) GS:ffff96e4ffc00000(0000)
knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 00007f2a141a4db0 CR3: 0000000137c74000 CR4: 00000000000006f0
kernel: Call Trace:
kernel: intel_atomic_commit_tail+0xa93/0xd70 [i915]
kernel: intel_atomic_commit+0x2ad/0x2e0 [i915]
kernel: drm_atomic_helper_set_config+0x66/0x90 [drm_kms_helper]
kernel: __drm_mode_set_config_internal+0x67/0x120 [drm]
kernel: drm_mode_setcrtc+0x476/0x600 [drm]
kernel: ? drm_mode_getcrtc+0x180/0x180 [drm]
kernel: drm_ioctl_kernel+0xaa/0xf0 [drm]
kernel: ? ___sys_recvmsg+0x18b/0x230
kernel: drm_ioctl+0x2e4/0x380 [drm]
kernel: ? drm_mode_getcrtc+0x180/0x180 [drm]
kernel: do_vfs_ioctl+0xa2/0x630
kernel: ? __sys_recvmsg+0x60/0xa0
kernel: ? __sys_recvmsg+0x8f/0xa0
kernel: ksys_ioctl+0x70/0x80
kernel: __x64_sys_ioctl+0x16/0x20
kernel: do_syscall_64+0x55/0xf0
kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
kernel: RIP: 0033:0x7f332887edd7
kernel: Code: 00 00 00 48 8b 05 c1 80 2b 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff
ff ff c3 66 2e 0f 1f 84
kernel: RSP: 002b:00007fff129c0928 EFLAGS: 00003246 ORIG_RAX: 0000000000000010
kernel: RAX: ffffffffffffffda RBX: 000000000000000e RCX: 00007f332887edd7
kernel: RDX: 00007fff129c0960 RSI: 00000000c06864a2 RDI: 000000000000000e
kernel: RBP: 00007fff129c0960 R08: 0000000000000000 R09: 000055f90fb2e570
kernel: R10: 00007fff129c0b00 R11: 0000000000003246 R12: 00000000c06864a2
kernel: R13: 000000000000000e R14: 000055f90ea93770 R15: 000055f90e8a3af0
kernel: ---[ end trace 1f4e17b459c3e35d ]---
I bisected this to:
c81350c31d0d20661a0aa839b79182bcb0e7a45d is the first bad commit
commit c81350c31d0d20661a0aa839b79182bcb0e7a45d
Author: Satendra Singh Thakur <satendra.t at samsung.com>
Date: Thu May 3 11:19:32 2018 +0530
drm/atomic: Handling the case when setting old crtc for plane
[ Upstream commit fc2a69f3903dfd97cd47f593e642b47918c949df ]
In the func drm_atomic_set_crtc_for_plane, with the current code,
if crtc of the plane_state and crtc passed as argument to the func
are same, entire func will executed in vein.
It will get state of crtc and clear and set the bits in plane_mask.
All these steps are not required for same old crtc.
Ideally, we should do nothing in this case, this patch handles the same,
and causes the program to return without doing anything in such scenario.
Signed-off-by: Satendra Singh Thakur <satendra.t at samsung.com>
Cc: Madhur Verma <madhur.verma at samsung.com>
Cc: Hemanshu Srivastava <hemanshu.s at samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
Link:
https://patchwork.freedesktop.org/patch/msgid/1525326572-25854-1-git-send-email-satendra.t@samsung.com
Signed-off-by: Sasha Levin <alexander.levin at microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
:040000 040000 3417076ff5f24a0c378d744e5cade5dd4c6fb184
995e08ea110cdaa338636a08b1d3d50ea50ab398 M drivers
---
drivers/gpu/drm/drm_atomic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1091,7 +1091,9 @@ drm_atomic_set_crtc_for_plane(struct drm
{
struct drm_plane *plane = plane_state->plane;
struct drm_crtc_state *crtc_state;
-
+ /* Nothing to do for same crtc*/
+ if (plane_state->crtc == crtc)
+ return 0;
if (plane_state->crtc) {
crtc_state = drm_atomic_get_crtc_state(plane_state->state,
plane_state->crtc);
Above patch adds an early exit to drm_atomic_set_crtc_for_plane() (for no good
reason?) and breaks my system.
Reverting this patch makes all newer kernels work again with my system (tested
up to 4.18.5).
I would not mind if this patch got reverted upstream as well.
Kind Regards
Karsten Hohmeier
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180904/51061713/attachment.html>
More information about the intel-gfx-bugs
mailing list