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.