From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Thomas Richter <thor@math.tu-berlin.de>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: GPU-hang on i830
Date: Wed, 10 Sep 2014 17:00:01 +0300 [thread overview]
Message-ID: <20140910140001.GT4193@intel.com> (raw)
In-Reply-To: <5410514B.2030207@math.tu-berlin.de>
On Wed, Sep 10, 2014 at 03:25:31PM +0200, Thomas Richter wrote:
> Am 10.09.2014 14:22, schrieb Daniel Vetter:
> > On Wed, Sep 10, 2014 at 02:17:30PM +0200, Thomas Richter wrote:
> >> Hi Daniel, hi Ville,
> >>
> >> just tried the new 3.17.0+rc4 kernel, though with old userspace (i.e.
> >> xserver-xorg-video-intel is *old*, libdrm is old, mesa is old). If I do, I
> >> get a "GPU hung" from xorg.conf. The same userspace works fine on 3.15.0
> >> with patches from Ville.
> >>
> >> Is this expected behavior or should I open up a bug report (I have dmesg
> >> output and debugging output from DRI ready on this, but it's a bith
> >> lengthy.)
> > Please retest with latest drm-intel-nightly, if just merged a patch from
> > Chris to prevent gpu hangs on i830/i845. If it still blows up please
> > attach and error state captured from that kernel.
> No, not merged from a patch. This is a clean checkout of "master".
> drm-intel-nightly did not contain the watermark fixes
> the last time I checked. Error state is attached. I put Chris into CC.
The w/a batch is corrupted. 0x400-0x1000 somehow got turned into zeroes.
Both are page boundaries, so I guess trying out Chris's TLB fix would
be worth a shot.
This is the commit you want:
commit c4d69da167fa967749aeb70bc0e94a457e5d00c1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Sep 8 14:25:41 2014 +0100
drm/i915: Evict CS TLBs between batches
I just trawled through BSpec a bit and I see a clear note there that BLT
TLBs are hosed on 830/845 and we need to flush after touching PTEs so
that BLT will see the correct stuff. There's also a note that touching
PGETBL_CTL enable bit would also flush all TLBs. So I wonder if just
I915_WRITE(PGETBL_CTL, I915_READ(PGETBL_CTL)) after touching the PTEs
would be enough to eliminate this problem?
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2014-09-10 14:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-10 12:17 GPU-hang on i830 Thomas Richter
2014-09-10 12:22 ` Daniel Vetter
[not found] ` <23616_1410351737_54104279_23616_5929_1_20140910122240.GT15520@phenom.ffwll.local>
2014-09-10 13:25 ` Thomas Richter
2014-09-10 13:52 ` Chris Wilson
2014-09-10 14:00 ` Ville Syrjälä [this message]
[not found] ` <23616_1410357635_54105982_23616_6665_1_20140910140001.GT4193@intel.com>
2014-09-10 14:17 ` Thomas Richter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140910140001.GT4193@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=thor@math.tu-berlin.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.