Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: <gregkh@linuxfoundation.org>
To: <mario.kleiner.de@gmail.com>, <airlied@redhat.com>,
	<daniel.vetter@ffwll.ch>, <gregkh@linuxfoundation.org>,
	<vbabka@suse.cz>
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "drm: Fix drm_vblank_pre/post_modeset regression from Linux 4.4" has been added to the 4.4-stable tree
Date: Tue, 01 Mar 2016 21:24:43 +0000	[thread overview]
Message-ID: <1456867480240245@kroah.com> (raw)


This is a note to let you know that I've just added the patch titled

    drm: Fix drm_vblank_pre/post_modeset regression from Linux 4.4

to the 4.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     drm-fix-drm_vblank_pre-post_modeset-regression-from-linux-4.4.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>From c61934ed9a0e3911a9935df26858726a7ec35ec0 Mon Sep 17 00:00:00 2001
From: Mario Kleiner <mario.kleiner.de@gmail.com>
Date: Fri, 12 Feb 2016 20:30:29 +0100
Subject: drm: Fix drm_vblank_pre/post_modeset regression from Linux 4.4

From: Mario Kleiner <mario.kleiner.de@gmail.com>

commit c61934ed9a0e3911a9935df26858726a7ec35ec0 upstream.

Changes to drm_update_vblank_count() in Linux 4.4 broke the
behaviour of the pre/post modeset functions as the new update
code doesn't deal with hw vblank counter resets inbetween calls
to drm_vblank_pre_modeset an drm_vblank_post_modeset, as it
should.

This causes mistreatment of such hw counter resets as counter
wraparound, and thereby large forward jumps of the software
vblank counter which in turn cause vblank event dispatching
and vblank waits to fail/hang --> userspace clients hang.

This symptom was reported on radeon-kms to cause a infinite
hang of KDE Plasma 5 shell's login procedure, preventing users
from logging in.

Fix this by detecting when drm_update_vblank_count() is called
inside a pre->post modeset interval. If so, clamp valid vblank
increments to the safe values 0 and 1, pretty much restoring
the update behavior of the old update code of Linux 4.3 and
earlier. Also reset the last recorded hw vblank count at call
to drm_vblank_post_modeset() to be safe against hw that after
modesetting, dpms on etc. only fires its first vblank irq after
drm_vblank_post_modeset() was already called.

Reported-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Vlastimil Babka <vbabka@suse.cz>
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/drm_irq.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -222,6 +222,21 @@ static void drm_update_vblank_count(stru
 	}
 
 	/*
+	 * Within a drm_vblank_pre_modeset - drm_vblank_post_modeset
+	 * interval? If so then vblank irqs keep running and it will likely
+	 * happen that the hardware vblank counter is not trustworthy as it
+	 * might reset at some point in that interval and vblank timestamps
+	 * are not trustworthy either in that interval. Iow. this can result
+	 * in a bogus diff >> 1 which must be avoided as it would cause
+	 * random large forward jumps of the software vblank counter.
+	 */
+	if (diff > 1 && (vblank->inmodeset & 0x2)) {
+		DRM_DEBUG_VBL("clamping vblank bump to 1 on crtc %u: diffr=%u"
+			      " due to pre-modeset.\n", pipe, diff);
+		diff = 1;
+	}
+
+	/*
 	 * FIMXE: Need to replace this hack with proper seqlocks.
 	 *
 	 * Restrict the bump of the software vblank counter to a safe maximum
@@ -1575,6 +1590,7 @@ void drm_vblank_post_modeset(struct drm_
 	if (vblank->inmodeset) {
 		spin_lock_irqsave(&dev->vbl_lock, irqflags);
 		dev->vblank_disable_allowed = true;
+		drm_reset_vblank_timestamp(dev, pipe);
 		spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
 
 		if (vblank->inmodeset & 0x2)


Patches currently in stable-queue which might be from mario.kleiner.de@gmail.com are

queue-4.4/drm-prevent-vblank-counter-bumps-1-with-active-vblank-clients.-v2.patch
queue-4.4/drm-fix-treatment-of-drm_vblank_offdelay-in-drm_vblank_on-v2.patch
queue-4.4/drm-nouveau-display-enable-vblank-irqs-after-display-engine-is-on-again.patch
queue-4.4/drm-fix-drm_vblank_pre-post_modeset-regression-from-linux-4.4.patch
queue-4.4/drm-radeon-don-t-hang-in-radeon_flip_work_func-on-disabled-crtc.-v2.patch
queue-4.4/drm-no-op-redundant-calls-to-drm_vblank_off-v2.patch
queue-4.4/drm-amdgpu-don-t-hang-in-amdgpu_flip_work_func-on-disabled-crtc.patch

                 reply	other threads:[~2016-03-01 21:24 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1456867480240245@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=airlied@redhat.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=mario.kleiner.de@gmail.com \
    --cc=stable-commits@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox