Bug#616559: BUG: soft lockup - CPU#1 stuck for 63s! [upowerd:7967]
# regression
severity 616559 important
retitle 616559 i915: [865G] soft lockup in intel_crt_load_detect after some idle time
tags 616559 + patch upstream
quit
Hi,
mihkel wrote:
> Hi. Log files in /var/log gets loaded with messages seen below (CPU#1
> stuck for 63s!), when my computer is supposed to be idle - meaning
> computer in not used for 15 minutes and monitor is off. But instead
> fans keep spinning like wild and log files growing.
[...]
> [26707.796750] Call Trace:
> [26707.796762] [<e90d6fb0>] ? intel_crt_load_detect+0x1f0/0x260 [i915]
> [26707.796774] [<e90d7295>] ? intel_crt_detect+0x275/0x2c4 [i915]
> [26707.796785] [<e8f70cef>] ? status_show+0x0/0x2f [drm]
> [26707.796795] [<e8f70d03>] ? status_show+0x14/0x2f [drm]
> [26707.796800] [<c11c390a>] ? dev_attr_show+0x16/0x32
> [26707.796805] [<c10fc020>] ? sysfs_read_file+0x8c/0xf5
> [26707.796810] [<c10fbf94>] ? sysfs_read_file+0x0/0xf5
> [26707.796815] [<c10ba3aa>] ? vfs_read+0x7c/0xd6
> [26707.796819] [<c10b8a34>] ? do_sys_open+0xb5/0xbe
> [26707.796823] [<c10ba497>] ? sys_read+0x3c/0x60
> [26707.796828] [<c1002f9f>] ? sysenter_do_call+0x12/0x28
> [26707.796833] [<c1280000>] ? init_scattered_cpuid_features+0x31/0xb6
> [26775.997590] BUG: soft lockup - CPU#1 stuck for 61s! [upowerd:7967]
Thanks again. This is said to be fixed by the attached patch, which
comes from Intel's drm-intel-testing branch[1]. That branch does not
feed directly into linux-next but patches there tend to end up in the
drm tree eventually.
The bug is said to be a regression introduced in 2.6.30-rc8. Does
that match your observations?
If you get a chance to test the patch against 3.0.y or 3.2.y, that
would be very helpful.
Hope that helps,
Jonathan
[1] git://people.freedesktop.org/~danvet/drm-intel
From: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri, 20 Apr 2012 21:03:36 +0200
Subject: drm/i915: fixup load-detect on enabled, but not active pipe
commit e95c8438ea1c56c254f0607c8fb6bca7f463c744 upstream.
Somehow we have a fast-path that tries to avoid going through
the load-detect code when the encode already has a crtc associated.
But this fails horribly when the crtc is off. The load detect pipe
itself manages this case well (and also does not forget to restore the
dpms state), so just rip out this special case.
The issue seems to go back all the way to the commit that originally
introduced load-detection on the vga output:
commit e4a5d54f924ea5ce2913d9d0687d034004816465
Author: Ma Ling <ling.ma@intel.com>
Date: Tue May 26 11:31:00 2009 +0800
drm/i915: Add support for VGA load detection (pre-945).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43020
Reported-by: Jean Delvare <khali@linux-fr.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
drivers/gpu/drm/i915/intel_crt.c | 29 +++++++++++------------------
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index fee0ad02c6d0..f94a75e3051c 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -429,8 +429,8 @@ intel_crt_detect(struct drm_connector *connector, bool force)
{
struct drm_device *dev = connector->dev;
struct intel_crt *crt = intel_attached_crt(connector);
- struct drm_crtc *crtc;
enum drm_connector_status status;
+ struct intel_load_detect_pipe tmp;
if (I915_HAS_HOTPLUG(dev)) {
if (intel_crt_detect_hotplug(connector)) {
@@ -449,23 +449,16 @@ intel_crt_detect(struct drm_connector *connector, bool force)
return connector->status;
/* for pre-945g platforms use load detect */
- crtc = crt->base.base.crtc;
- if (crtc && crtc->enabled) {
- status = intel_crt_load_detect(crt);
- } else {
- struct intel_load_detect_pipe tmp;
-
- if (intel_get_load_detect_pipe(&crt->base, connector, NULL,
- &tmp)) {
- if (intel_crt_detect_ddc(connector))
- status = connector_status_connected;
- else
- status = intel_crt_load_detect(crt);
- intel_release_load_detect_pipe(&crt->base, connector,
- &tmp);
- } else
- status = connector_status_unknown;
- }
+ if (intel_get_load_detect_pipe(&crt->base, connector, NULL,
+ &tmp)) {
+ if (intel_crt_detect_ddc(connector))
+ status = connector_status_connected;
+ else
+ status = intel_crt_load_detect(crt);
+ intel_release_load_detect_pipe(&crt->base, connector,
+ &tmp);
+ } else
+ status = connector_status_unknown;
return status;
}
--
1.7.10
Reply to: