Package: release.debian.org Severity: normal Tags: jessie User: release.debian....@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 <b...@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 <torva...@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 <jvpe...@web.de> +Acked-by: Alexander Deucher <alexander.deuc...@amd.com> +Cc: Dave Airlie <airl...@gmail.com> +Signed-off-by: Linus Torvalds <torva...@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.henriq...@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 <ander...@codepoet.org> +Acked-by: Christian König <christian.koe...@amd.com> +Cc: Nicolai Hähnle <nicolai.haeh...@amd.com> +Signed-off-by: Luis Henriques <luis.henriq...@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 <gre...@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 <to...@cybernetics.com> +Cc: Du, Changbin <changbin...@intel.com> +Signed-off-by: Greg Kroah-Hartman <gre...@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)
