linux-kernel - [bisected] drm i915 hangs on heavy io load

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2841410.AEaCaTYTzS@al>
Date:	Mon, 05 Nov 2012 21:29:53 +0100
From:	Lekensteyn <lekensteyn@...il.com>
To:	Dave Airlie <airlied@...il.com>
Cc:	Norbert Preining <preining@...ic.at>,
	Chris Wilson <chris@...is-wilson.co.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: [bisected] drm i915 hangs on heavy io load

On Sunday 04 November 2012 16:08:47 Dave Airlie wrote:
> On Sun, Nov 4, 2012 at 10:44 AM, Norbert Preining <preining@...ic.at> wrote:

> > On Di, 30 Okt 2012, Dave Airlie wrote:
> >> I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6
> >> final to 3.7-rc1 or maybe -rc2.
> > 
> > Sorry for my ignorance ... I did on master branch
> > 
> >         $ git checkout v3.7-rc1
> >         ...
> >         $ git bisect start drivers/gpu/drm/i915
> >         $ git bisect bad
> >         $ git bisect good v3.6
> >         Bisecting: 121 revisions left to test after this (roughly 7 steps)
> >         [25c5b2665fe4cc5a93edd29b62e7c05c15dddd26] drm/i915: implement new
> >         set_mode code flow $
> > 
> > after that I am back somewhere around
> > 
> >         3.6.0-rc2
> > 
> > ???
> > 
> > Am I doing something wrong? I thought I am bisecting between 3.6 and
> > 3.7.-rc2? How can I go back to 3.6.0-rc2?
> 
> Yeah thats fine, bisecting works by going to where commits were
> originally committed, so drm-intel-next was 3.6.0-rc2 at some point
> was only merged into Linus later.

As I mentioned on https://bugs.freedesktop.org/show_bug.cgi?id=55984, I also 
hit this bug. The first time was on branch drm-intel-next-2012-09-20 on Daniel 
Vetters drm-intel git.

I guess it has something to do with low memory. To reproduce the bug on my 
laptop with 8GB RAM and a i5-460M, I did:

1. Boot (I use KDE)
3. Start glxspheres (from http://virtualgl.org/, but glxgears might work too, 
not tested)
2. Copy a 1.2 GiB Linux source tree to /dev/shm and /tmp (both tmpfs), 5 
times. This uses 6GiB of RAM. I used this bash script:
#!/bin/bash
for i in /tmp/hang-l1 /tmp/hang-l2 /tmp/hang-l3 \
/dev/shm/hang-l1 /dev/shm/hang-l2; do
        cp -ra ~/Linux-src/linux "$i" &
done; wait
3. When the copy is almost done, watch the machine become sluggish and 
eventually print the "[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer 
elapsed... GPU hung" message to the kernel log. Until the machine is rebooted, 
all OpenGL applications will fail to load.

On kernels where it was working fine, there is no lag when the copy is almost 
finished.

504c7267a1e84b157cbd7e9c1b805e1bc0c2c846 is the first bad commit
commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
Author: Chris Wilson <chris@...is-wilson.co.uk>
Date:   Thu Aug 23 13:12:52 2012 +0100

    drm/i915: Use cpu relocations if the object is in the GTT but not mappable
    
    This prevents the case of unbinding the object in order to process the
    relocations through the GTT and then rebinding it only to then proceed
    to use cpu relocations as the object is now in the CPU write domain. By
    choosing to use cpu relocations up front, we can therefore avoid the
    rebind penalty.
    
    Signed-off-by: Chris Wilson <chris@...is-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@...ll.ch>

:040000 040000 090ed3d52b4f3210b988877f747b6ff86e123385 
1d48be89ded4777a543b693db833de64877059c4 M      drivers

Regards,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/