| Summary: | [bisected piketon] changing resolution cause ut2004 to hang, with VGA and compiz enabled | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | fangxun <xunx.fang> | ||||||||
| Component: | DRM/Intel | Assignee: | Chris Wilson <chris> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | high | CC: | bo.b.wang, jbarnes | ||||||||
| Version: | unspecified | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux (All) | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
|
Description
fangxun
2010-12-09 23:35:34 UTC
You're doing better than me, I'm hitting the glx DrawableGone crash in the xserver first... Can you please do a 'echo t > /proc/sysrq-trigger' and grab the dmesg? Do you see a similar hang with just changing the resolution using xrandr? Created attachment 41052 [details]
dmesg with 'echo t > /proc/sysrq-trigger'
I don't see a similar hang with just changing the resolution using xrandr.
It was a long shot. Lots of silly processes adding to the noise, we only managed to capture that compiz was idle (in poll()) and not what X was doing. Though it should be safe to conclude that ut2004 itself had finised. I think I uncovered a related bug on drm-intel-next, where we are waiting for an IRQ with interrupts disabled during modesetting. The only question is how much of the fix is also applicable to -fixes and how on it might relate to this bug/bisection? How widespread is the regression? Have you seen similar failures on the other stable platforms? (After reverting the PIPE_CONTROL removal) Do you see a similar failure on drm-intel-next (which in theory has the related bug fix)? Tested on 965gm and capella with stable kernel(drm-intel-fixes), I don't see similar failures. Tested on pikteton with unstable kernel(drm-intel-next) that after reverting the PIPE_CONTROL removal, similar failure happens. BTW, use drm-intel-next(8d5203ca62539c6ab36a5bc2402c2de1de460e30) that before reverting the PIPE_CONTROL removal, similar failure also happens. Thanks, what's the display connected to the piketon? Any DP? I've not reproduced this so far on any platform, the closest to piketon I have is Arrandale+LVDS. And I don't see it on SNB either. ;-) VGA connected on piketon. I see the similar failures on SNB with VGA connected. But with DP connected, it works fine both on piketon and SNB. * scratches head. I've got a VGA panel hooked up to the SNB as well. The bisection simply makes no sense, can I ask you to double check? Even just to confirm that a revert of 1b39d6f3 fixes ut2004. Confirm that the revert fixes ut2004. Any chance this is related to: commit 541cc966915b6756e54c20eebe60ae957afdb537 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Dec 6 11:24:07 2010 +0000 drm: Don't try and disable an encoder that was never enabled Prevents code that assumes that the encoder is active when asked to be disabled from dying a horrible death. Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com> i.e. does reverting that (which has been identified to cause other modesetting failures) help? After revert 541cc966915b6756e54c20eebe60ae957afdb537, the failures still happens. Chris, do you need access this machine? I'm still no wiser as to why a change on what should be an unused code path (for this system) would be causing this regression. Nevertheless there have been the usual bug fixes, and in particular the uninterruptible modesetting fix. Retest with latest code, it still happens on piketon and SNB. (In reply to comment #19) > Retest with latest code, it still happens on piketon and SNB. Does Jesse's modesetting checks detect anything amiss? Can you update the dmesg (with drm.debug=0xe) and include one for the SNB? I'm still at a loss as to the cause here - this code should not even be touched for your non-DP system configuration! :| Created attachment 44643 [details]
ut2004.txt is dmesg infomation with drm.debug=0xe on sugarbay
So this is probably the cause of the SNB behaviour: [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 94239, at 94239], missed IRQ? I suspect the SNB has a comppletely different bug to piketon and should be filed separately. Bo, please file a separate bug for SNB. (In reply to comment #23) > Bo, please file a separate bug for SNB. I have reported a new Bug.Bug number: 35535 *crosses fingers* Is this fixed by: commit 31acbcc408f412d1ba73765b846c38642be553c3 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Apr 17 06:38:35 2011 +0100 drm/i915/dp: Be paranoid in case we disable a DP before it is attached Given that the hardware may be left in a random condition by the BIOS, it is conceivable that we then attempt to clear the DP_PIPEB_SELECT bit without us ever enabling/attaching the DP encoder to a pipe. Thus causing a NULL deference when we attempt to wait for a vblank on that crtc. Reported-and-tested-by: Bryan Christ <bryan.christ@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36314 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36456 Reported-and-tested-by: Bo Wang <bo.b.wang@intel.com> Cc: stable@kernel.org Signed-off-by: Keith Packard <keithp@keithp.com> Tested on piketon and huronriver, no issue happens. I need more testing to confirm this. Closing. Verified with drm-intel-next commit da3cc9202697a44057c1bd3ad685689375f1fe0c and drm-intel-fixes commit 2fb4e61d9471867677c97bf11dba8f1e9dfa7f7c. Closing old verified+fixed. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.