Bug#820403: jessie-pu: package linux/3.16.7-ckt25-2
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian.org@packages.debian.org
Usertags: pu
The recent point release (8.4) introduced several regressions in
src:linux. In particular bug #819881 (radeon crasher) is affecting a
fair number of users. Bug #820176 (usb crasher) was also reported
several times and there is a second crash bug in radeon which had many
reports upstream.
All three regressions are caused by single commits that have been reverted
in the next 3.16.7-ckt update; two were also reverted upstream. I would
like to apply those reversions through jessie-updates rather than
waiting for the next point release or security update.
As I haven't done this before (so far as I can remember, anyway),
please let me know whether I have to do anything different compared to
an upload that's destined for the next point release.
The debdiff is below, with changes to generated files
debian/config.defines.dump, debian/control.md5sum and debian/rules.gen
omitted.
Ben.
diff -Nru linux-3.16.7-ckt25/debian/changelog linux-3.16.7-ckt25/debian/changelog
--- linux-3.16.7-ckt25/debian/changelog 2016-03-06 22:19:35.000000000 +0000
+++ linux-3.16.7-ckt25/debian/changelog 2016-04-07 22:34:44.000000000 +0100
@@ -1,3 +1,14 @@
+linux (3.16.7-ckt25-2) jessie-updates; urgency=medium
+
+ * Revert "drm/radeon: hold reference to fences in radeon_sa_bo_new"
+ (Closes: #819881)
+ * Revert "drm/radeon: call hpd_irq_event on resume", reported to cause
+ regressions (crash/hang) on some systems
+ * Revert "usb: hub: do not clear BOS field during reset device"
+ (Closes: #820176)
+
+ -- Ben Hutchings <ben@decadent.org.uk> Thu, 07 Apr 2016 22:34:43 +0100
+
linux (3.16.7-ckt25-1) jessie; urgency=medium
* New upstream stable update:
diff -Nru linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-call-hpd_irq_event-on-resume.patch linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-call-hpd_irq_event-on-resume.patch
--- linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-call-hpd_irq_event-on-resume.patch 1970-01-01 01:00:00.000000000 +0100
+++ linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-call-hpd_irq_event-on-resume.patch 2016-04-07 22:33:40.000000000 +0100
@@ -0,0 +1,42 @@
+From: Linus Torvalds <torvalds@linux-foundation.org>
+Date: Mon, 7 Mar 2016 13:15:09 -0800
+Subject: Revert "drm/radeon: call hpd_irq_event on resume"
+Origin: https://git.kernel.org/linus/256faedcfd646161477d47a1a78c32a562d2e845
+
+This reverts commit dbb17a21c131eca94eb31136eee9a7fe5aff00d9.
+
+It turns out that commit can cause problems for systems with multiple
+GPUs, and causes X to hang on at least a HP Pavilion dv7 with hybrid
+graphics.
+
+This got noticed originally in 4.4.4, where this patch had already
+gotten back-ported, but 4.5-rc7 was verified to have the same problem.
+
+Alexander Deucher says:
+ "It looks like you have a muxed system so I suspect what's happening is
+ that one of the display is being reported as connected for both the
+ IGP and the dGPU and then the desktop environment gets confused or
+ there some sort problem in the detect functions since the mux is not
+ switched to the dGPU. I don't see an easy fix unless Dave has any
+ ideas. I'd say just revert for now"
+
+Reported-by: Jörg-Volker Peetz <jvpeetz@web.de>
+Acked-by: Alexander Deucher <Alexander.Deucher@amd.com>
+Cc: Dave Airlie <airlied@gmail.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+---
+ drivers/gpu/drm/radeon/radeon_device.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
+index f7296ca6510c..ca470fb17aa4 100644
+--- a/drivers/gpu/drm/radeon/radeon_device.c
++++ b/drivers/gpu/drm/radeon/radeon_device.c
+@@ -1649,7 +1649,6 @@ int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon)
+ }
+
+ drm_kms_helper_poll_enable(dev);
+- drm_helper_hpd_irq_event(dev);
+
+ /* set the power state here in case we are a PX system or headless */
+ if ((rdev->pm.pm_method == PM_METHOD_DPM) && rdev->pm.dpm_enabled)
diff -Nru linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-hold-reference-to-fences-in-radeon.patch linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-hold-reference-to-fences-in-radeon.patch
--- linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-hold-reference-to-fences-in-radeon.patch 1970-01-01 01:00:00.000000000 +0100
+++ linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-drm-radeon-hold-reference-to-fences-in-radeon.patch 2016-04-07 22:33:40.000000000 +0100
@@ -0,0 +1,39 @@
+From: Luis Henriques <luis.henriques@canonical.com>
+Date: Wed, 9 Mar 2016 13:58:27 +0000
+Subject: Revert "drm/radeon: hold reference to fences in radeon_sa_bo_new"
+Origin: http://kernel.ubuntu.com/git/ubuntu/linux.git/commit?id=f80be5a9b1ccf679415676f761bc9efdc3ad13b5
+
+This reverts commit 73187980dfefe5198aadcfdf0a377e461eed2bfa, which was
+commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb upstream.
+
+This patch was triggering a Oops in stable kernel 3.10.99. Christian
+agrees that the patch is correct but "assumes that radeon_fence_unref()
+can safely take NULL as the fence which is not the case for older
+kernels."
+
+Reported-by: Erik Andersen <andersen@codepoet.org>
+Acked-by: Christian König <christian.koenig@amd.com>
+Cc: Nicolai Hähnle <nicolai.haehnle@amd.com>
+Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
+---
+ drivers/gpu/drm/radeon/radeon_sa.c | 5 -----
+ 1 file changed, 5 deletions(-)
+
+diff --git a/drivers/gpu/drm/radeon/radeon_sa.c b/drivers/gpu/drm/radeon/radeon_sa.c
+index 15fd57296081..adcf3e2f07da 100644
+--- a/drivers/gpu/drm/radeon/radeon_sa.c
++++ b/drivers/gpu/drm/radeon/radeon_sa.c
+@@ -349,13 +349,8 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
+ /* see if we can skip over some allocations */
+ } while (radeon_sa_bo_next_hole(sa_manager, fences, tries));
+
+- for (i = 0; i < RADEON_NUM_RINGS; ++i)
+- radeon_fence_ref(fences[i]);
+-
+ spin_unlock(&sa_manager->wq.lock);
+ r = radeon_fence_wait_any(rdev, fences, false);
+- for (i = 0; i < RADEON_NUM_RINGS; ++i)
+- radeon_fence_unref(&fences[i]);
+ spin_lock(&sa_manager->wq.lock);
+ /* if we have nothing to wait for block */
+ if (r == -ENOENT) {
diff -Nru linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-usb-hub-do-not-clear-bos-field-during-reset-d.patch linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-usb-hub-do-not-clear-bos-field-during-reset-d.patch
--- linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-usb-hub-do-not-clear-bos-field-during-reset-d.patch 1970-01-01 01:00:00.000000000 +0100
+++ linux-3.16.7-ckt25/debian/patches/bugfix/all/revert-usb-hub-do-not-clear-bos-field-during-reset-d.patch 2016-04-07 22:34:06.000000000 +0100
@@ -0,0 +1,61 @@
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Sat, 20 Feb 2016 14:19:34 -0800
+Subject: Revert "usb: hub: do not clear BOS field during reset device"
+Origin: https://git.kernel.org/linus/e5bdfd50d6f76077bf8441d130c606229e100d40
+
+This reverts commit d8f00cd685f5c8e0def8593e520a7fef12c22407.
+
+Tony writes:
+
+This upstream commit is causing an oops:
+d8f00cd685f5 ("usb: hub: do not clear BOS field during reset device")
+
+This patch has already been included in several -stable kernels. Here
+are the affected kernels:
+4.5.0-rc4 (current git)
+4.4.2
+4.3.6 (currently in review)
+4.1.18
+3.18.27
+3.14.61
+
+How to reproduce the problem:
+Boot kernel with slub debugging enabled (otherwise memory corruption
+will cause random oopses later instead of immediately)
+Plug in USB 3.0 disk to xhci USB 3.0 port
+dd if=/dev/sdc of=/dev/null bs=65536
+(where /dev/sdc is the USB 3.0 disk)
+Unplug USB cable while dd is still going
+Oops is immediate:
+
+Reported-by: Tony Battersby <tonyb@cybernetics.com>
+Cc: Du, Changbin <changbin.du@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/core/hub.c | 8 +++-----
+ 1 file changed, 3 insertions(+), 5 deletions(-)
+
+--- a/drivers/usb/core/hub.c
++++ b/drivers/usb/core/hub.c
+@@ -5387,6 +5387,7 @@ static int usb_reset_and_verify_device(s
+ }
+
+ bos = udev->bos;
++ udev->bos = NULL;
+
+ for (i = 0; i < SET_CONFIG_TRIES; ++i) {
+
+@@ -5479,11 +5480,8 @@ done:
+ usb_set_usb2_hardware_lpm(udev, 1);
+ usb_unlocked_enable_lpm(udev);
+ usb_enable_ltm(udev);
+- /* release the new BOS descriptor allocated by hub_port_init() */
+- if (udev->bos != bos) {
+- usb_release_bos_descriptor(udev);
+- udev->bos = bos;
+- }
++ usb_release_bos_descriptor(udev);
++ udev->bos = bos;
+ return 0;
+
+ re_enumerate:
diff -Nru linux-3.16.7-ckt25/debian/patches/series linux-3.16.7-ckt25/debian/patches/series
--- linux-3.16.7-ckt25/debian/patches/series 2016-03-06 22:04:43.000000000 +0000
+++ linux-3.16.7-ckt25/debian/patches/series 2016-04-07 22:34:06.000000000 +0100
@@ -656,3 +656,6 @@
bugfix/all/ip_vti-ip6_vti-do-not-touch-skb-mark-on-xmit.patch
bugfix/all/xfrm-override-skb-mark-with-tunnel-parm.i_key-in-xfr.patch
bugfix/all/ip_vti-ip6_vti-preserve-skb-mark-after-rcv_cb-call.patch
+bugfix/all/revert-drm-radeon-hold-reference-to-fences-in-radeon.patch
+bugfix/all/revert-drm-radeon-call-hpd_irq_event-on-resume.patch
+bugfix/all/revert-usb-hub-do-not-clear-bos-field-during-reset-d.patch
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Reply to: