Summary: | [BDW-U Bisected]System hang while running "xrandr --output eDP1 --off" | ||
---|---|---|---|
Product: | DRI | Reporter: | Guo Jinxian <jinxianx.guo> |
Component: | DRM/Intel | Assignee: | Daniel Vetter <daniel> |
Status: | CLOSED WORKSFORME | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
Severity: | normal | ||
Priority: | highest | CC: | intel-gfx-bugs, matthew.d.roper |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Guo Jinxian
2014-07-18 08:57:06 UTC
2ff8fde1ea0992dfd735dce94f8cae2aacff8e5c is the first bad commit commit 2ff8fde1ea0992dfd735dce94f8cae2aacff8e5c Author: Matt Roper <matthew.d.roper@intel.com> AuthorDate: Tue Jul 8 07:50:07 2014 -0700 Commit: Daniel Vetter <daniel.vetter@ffwll.ch> CommitDate: Wed Jul 9 13:52:03 2014 +0200 drm/i915: Make use of intel_fb_obj() (v2) This should hopefully simplify the display code slightly and also solves at least one mistake in intel_pipe_set_base() where to_intel_framebuffer(fb)->obj is referenced during local variable initialization, before 'if (!fb)' gets checked. Potential uses of this macro were identified via the following Coccinelle patch: @@ expression E; @@ * to_intel_framebuffer(E)->obj @@ expression E; identifier I; @@ I = to_intel_framebuffer(E); ... * I->obj v2: Rewrite some NULL tests in terms of the obj rather than the fb. Also add a WARN() if trying to pageflip with a disabled primary plane. [Suggested by Chris Wilson] Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> :040000 040000 a6d9ad40b7000439f553f6cf5c79abcc4466c585 e29153507c0bcc115b03568e4b87bde21319030c M drivers The bad commit unable to revert git revert 2ff8fde1ea0992dfd735dce94f8cae2aacff8e5c error: could not revert 2ff8fde... drm/i915: Make use of intel_fb_obj() (v2) hint: after resolving the conflicts, mark the corrected paths hint: with 'git add <paths>' or 'git rm <paths>' hint: and commit the result with 'git commit' I'm surprised that this commit would trigger a regression since it was intended to have little/no functional change (aside from one potential NULL dereference which was plugged by this patch). You indicate that the bug appears on only a single device...does it happen every single time you run the xrandr command on that platform, or is the problem only seen occasionally? I'll have to look more closely when I have some free time tomorrow, but the fact that you don't see the same problem on other similar devices makes me wonder whether I've introduced a race condition somewhere that you only get (un)lucky enough to hit on that one device. I don't suppose there's any way to get a serial console on this device so you can see the kernel dump? (In reply to comment #2) > I'm surprised that this commit would trigger a regression since it was > intended to have little/no functional change (aside from one potential NULL > dereference which was plugged by this patch). > > You indicate that the bug appears on only a single device...does it happen > every single time you run the xrandr command on that platform, or is the > problem only seen occasionally? I'll have to look more closely when I have > some free time tomorrow, but the fact that you don't see the same problem on > other similar devices makes me wonder whether I've introduced a race > condition somewhere that you only get (un)lucky enough to hit on that one > device. > > I don't suppose there's any way to get a serial console on this device so > you can see the kernel dump? The failure unable to reproduce now. Let's write this off as a mystery bug and hope it doesn't come back. |
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.