[Bug 65845] New: [PNV/GM45 Bisected]glxgears segfault

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sun Jun 16 23:49:11 PDT 2013


https://bugs.freedesktop.org/show_bug.cgi?id=65845

          Priority: high
            Bug ID: 65845
                CC: xunx.fang at intel.com, yangweix.shui at intel.com
          Assignee: mika.kuoppala at intel.com
           Summary: [PNV/GM45 Bisected]glxgears segfault
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
          Severity: major
    Classification: Unclassified
                OS: Linux (All)
          Reporter: huax.lu at intel.com
          Hardware: All
            Status: NEW
           Version: unspecified
         Component: DRM/Intel
           Product: DRI

Created attachment 80931
  --> https://bugs.freedesktop.org/attachment.cgi?id=80931&action=edit
dmesg

System Environment:
--------------------------
Platform:         Pineview/GM45
Kernel:     (drm-intel-next-queued)cab8b5862acd55019fbeede6940d1a601912d6b8

Bug detailed description:
-------------------------
It segfault on Pineview and GM45 with drm-intel-next-queued kernel.It works
well on drm-intel-fixes kernel.

Bisect shows:a89cdd3cfcd66d932d4ae2617c5e89279515f14d is the first bad commit.
commit a89cdd3cfcd66d932d4ae2617c5e89279515f14d
Author:     Mika Kuoppala <mika.kuoppala at linux.intel.com>
AuthorDate: Wed Jun 12 12:35:34 2013 +0300
Commit:     Daniel Vetter <daniel.vetter at ffwll.ch>
CommitDate: Thu Jun 13 17:42:18 2013 +0200

    drm/i915: refuse to submit more batchbuffers from guilty context

    If context has recently submitted a faulty batchbuffers guilty of
    gpu hang and decides to keep submitting more crap, ban it permanently.

    Note: This is just a refinment of the existing policy to declare the
    gpu wedged when it's hanging too often. We have that in place to
    increase the odds of a system surviving gpu hang storms (and so
    getting a useful bug report with the error state).

    With this patch here we reduce the risk to take down unrelated
    applications, since especially modern compositors tend to die when
    mesa can't submit batches any more. So for the somewhat common case of
    a specific gl workload causing a gpu hang flurry we should now have
    less grumpy users since we don't take down their entire deskopt
    enviroment any more.

    v2: Store guilty ban status bool in gpu_error instead of pointers
        that might become danling before hang is declared.

    v3: Use return value for banned status instead of stashing state
        into gpu_error (Chris Wilson)

    Signed-off-by: Mika Kuoppala <mika.kuoppala at intel.com>
    Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
    [danvet: Added note to commit message to explain why we want this,
    which addresses a concern Ben raised.]
    Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>


output:
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
Segmentation fault (core dumped)


Reproduce steps:
----------------
1. xinit
2. glxgears

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20130617/863169db/attachment.html>


More information about the intel-gfx-bugs mailing list