On Mon, Oct 17, 2011 at 18:15, Eric Anholt wrote:
> On Mon, 17 Oct 2011 13:37:54 -0200, Paulo Zanoni
> wrote:
> > 2011/10/13 Eric Anholt :
> > > ---
> > >
> > > I kept reviewing the B-Spec on systems with weird issues and
> > > hand-decoding each interesting register (for example, is everything
On Mon, Oct 17, 2011 at 20:41, Keith Packard wrote:
> On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov
> wrote:
>
> > From what I've checked, the other return error value in this context
> could
> > be -EREMOTEIO, which could be caused by transmission error so it should
> be
> > retried.
>
> O
Idle the GPU before doing any unmaps. We know if VT-d is in use through
an exported variable from iommu code.
This should avoid a known HW issue.
Signed-off-by: Ben Widawsky
---
drivers/char/agp/intel-gtt.c| 28
drivers/gpu/drm/i915/i915_gem_gtt.c | 30 +
[Description from: Daniel Vetter]
I've just discussed this quickly with Chris on irc and it's probably
best to just kill the list_empty early bailout. gpu_idle isn't a
fastpath, so who cares. One candidate where we emit commands to the ring
without adding anything onto these lists is e.g. pageflip.
From: David Woodhouse
We really don't want this to work in the general case; device drivers
*shouldn't* care whether they are behind an IOMMU or not. But the
integrated graphics is a special case, because the IOMMU and the GTT are
all kind of smashed into one and generally horrifically buggy, so
From: David Woodhouse
To work around a hardware issue, we have to submit IOTLB flushes while
the graphics engine is idle. The graphics driver will (we hope) go to
great lengths to ensure that it gets that right on the affected
chipset(s)... so let's not screw it over by deferring the unmap and
do
I think Daniel caved in and agrees that making the idle cause the GPU to
be uninterruptible was the correct approach. So this patch is pretty
much the same as v3, except it has David's new global to determine the
IOMMU status. In other words, disregard v4.
For the series:
Tested-by: Ben Widawsky
On Mon, 17 Oct 2011 13:03:02 -0400, Adam Jackson wrote:
> [drm:drm_mode_debug_printmodeline], Modeline 28:"" 0 154000 1920 1968 2000
> 2080 1200 1203 1209 1235 0x0 0x9
> [drm:intel_dp_mode_fixup], Display port link bw 0a lane count 2 clock
> 27
Ok, nice to see that you've actually tested a
On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov wrote:
> From what I've checked, the other return error value in this context could
> be -EREMOTEIO, which could be caused by transmission error so it should be
> retried.
Oh, there's -ENOMEM, -EINVAL and probably a few others down in the
bowels
Hi,
Unfortunately I won't be at the next graphics call, but below is a list
of the bugs we've forwarded upstream from Ubuntu Oneiric for your
reference.
A few of these are blocked waiting for feedback from the reporter; not
sure what to do with those. Several of the GPU lockup bugs likely are
du
On Mon, 2011-10-17 at 08:53 -0700, Jesse Barnes wrote:
> Sorry Keith, should have cc'd you on the other two replies to this
> thread as well.
>
> This one is mainly increasing the size of the DPCD array we use so that
> we read all the cap bytes instead of just the first 8. This makes some
> sin
On Mon, Oct 17, 2011 at 18:41, Keith Packard wrote:
> On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov <
> eugeni.dodo...@intel.com> wrote:
>
> > + if (ret == -ENXIO) {
> > + DRM_DEBUG_KMS("drm: skipping non-existent adapter
> %s\n",
> > +
On Mon, Oct 17, 2011 at 10:20:09PM +0200, Dieter Mummenschanz wrote:
> ok now I got your patch from git and will give it a try asap. Meanwhile
> the intel_iommu=off (with rc6 enabled) switch seems to make the system
> somehow more stable. the gpu hangs don't appear that often but they
> still occur
On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov
wrote:
> + if (ret == -ENXIO) {
> + DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
> + adapter->name);
> + break;
> + }
This seems goo
This adds a hint on where the call trace originated from with a helper
macro GUESS_ORIGIN. As its name says, it is more of a guess, but still, it
seems to be quite accurate on most of the traces.
The results of the heuristics are printed at the end of the decoding:
...
0x00062fe8: 0x
On Mon, 17 Oct 2011 13:37:54 -0200, Paulo Zanoni wrote:
> 2011/10/13 Eric Anholt :
> > ---
> >
> > I kept reviewing the B-Spec on systems with weird issues and
> > hand-decoding each interesting register (for example, is everything
> > still sane after resume?), so here's a tool to do so automatic
2011/10/14 Chris Wilson :
> I'm a little more dubious over the value of this patch. The extra
> information is nice, but the patch doesn't impact much upon the
> readibility of the code. It seems like this should have the potential to
> clarify quite a bit of the logic and make it more consistent,
On Mon, Oct 17, 2011 at 06:01:56PM +0200, Dieter Mummenschanz wrote:
> Hi Daniel,
>
> ok I did a git clone git://anongit.freedesktop.org/libva (hope this is the
> right one?) and in the libva checkout I issued:
>
> git pull git://freedesktop.org/~danvet/libva-intel for-dieter
> warning: no com
On Tue, 2011-10-11 at 10:45 -0700, Jesse Barnes wrote:
> At the point where we check, we can't do much about the failure, but it
> can aid debugging. Note that the auto-train override bit will be reset
> as part of normal mode setting with this patch if a pipe ever does get
> stuck, but that's con
On Fri, 2011-10-14 at 23:13 -0700, Keith Packard wrote:
> On Fri, 14 Oct 2011 12:43:50 -0400, Adam Jackson wrote:
>
> > These were just working around the math being wrong.
>
> One wonders whether this might break some machines which are currently
> working. Should we emit an error or something
On Fri, 14 Oct 2011 13:33:35 -0700
Bryan Freed wrote:
> On Thu, Oct 6, 2011 at 8:09 AM, Jesse Barnes wrote:
>
> > On Wed, 5 Oct 2011 22:45:55 -0700
> > Simon Que wrote:
> >
> > > Hi,
> > >
> > > Here's a patch to introduce a DMI-based SSC frequency selection in
> > > intel_bios.c. Instead of a
On Mon, Oct 17, 2011 at 15:10, Ben Widawsky wrote:
> On Mon, Oct 17, 2011 at 02:25:01PM -0200, Eugeni Dodonov wrote:
> > This adds a hint on where the call trace originated from. This is more of
> > a guess, but still, it seems to be quite accurate on the traces I tested.
> >
> > So it appears in
On Mon, Oct 17, 2011 at 02:25:01PM -0200, Eugeni Dodonov wrote:
> This adds a hint on where the call trace originated from. This is more of
> a guess, but still, it seems to be quite accurate on the traces I tested.
>
> So it appears in the output like:
>
> ...
> 0x06c470c8: 0x780e0002: 3DST
On Fri, 14 Oct 2011 17:22:26 -0400
Adam Jackson wrote:
> According to the gen6 docs, only the DP_A port (on-CPU eDP) still uses
> the old IBX bit shift for the link training pattern setup bits.
>
> Signed-off-by: Adam Jackson
> ---
Looks good. Wish I had a test platform for this...
Reviewed-
On Fri, 2011-10-14 at 23:11 -0700, Keith Packard wrote:
> On Fri, 14 Oct 2011 12:43:49 -0400, Adam Jackson wrote:
>
> > The previous code was confused about units, which is pretty reasonable
> > given that the units themselves are confusing.
>
> Thanks for actually figuring this out; the comment
This adds a hint on where the call trace originated from. This is more of
a guess, but still, it seems to be quite accurate on the traces I tested.
So it appears in the output like:
...
0x06c470c8: 0x780e0002: 3DSTATE_CC_STATE_POINTERS
0x06c470cc: 0x7f81:blend change 1
0x06c470d
Hi Daniel,
ok I did a git clone git://anongit.freedesktop.org/libva (hope this is the
right one?) and in the libva checkout I issued:
git pull git://freedesktop.org/~danvet/libva-intel for-dieter
warning: no common commits
remote: Counting objects: 1632, done.
remote: Compressing objects: 100%
On Thu, 22 Sep 2011 20:29:09 +0530
Jesse Barnes wrote:
> On Thu, 22 Sep 2011 09:41:01 +0100
> Chris Wilson wrote:
>
> > On Thu, 22 Sep 2011 11:15:58 +0530, Jesse Barnes
> > wrote:
> > > Read link status first, followed by the full DPCD receiver cap field
> > > rather than just the first 8 byte
On Thu, 22 Sep 2011 11:16:01 +0530
Jesse Barnes wrote:
> SPD frames are actually type 0x83, not just 0x3.
>
> Signed-off-by: Jesse Barnes
Another one for -fixes.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
__
On Thu, 22 Sep 2011 11:16:00 +0530
Jesse Barnes wrote:
> Misc fixes based on tests with an infoframe analyzer:
> - checksum *does* include header bytes
> - DIP enable & AVI infoframe are tied together in hw, so disable both
> and make sure AVI frames are enabled first
> - use every vsyn
On Mon, Oct 17, 2011 at 05:13:02PM +0200, Dieter Mummenschanz wrote:
> Hi Daniel,
>
> something is odd with your git branch - or my git command:
It's a headless git repo with just branches. Go into your existing intel
libva driver checkout, create a new branch and merge in my stuff with
git pull
2011/10/13 Eric Anholt :
> ---
>
> I kept reviewing the B-Spec on systems with weird issues and
> hand-decoding each interesting register (for example, is everything
> still sane after resume?), so here's a tool to do so automatically.
>
> tools/Makefile.am | 1 +
> tools/intel_reg_chec
Hi Daniel,
something is odd with your git branch - or my git command:
git clone git://freedesktop.org/~danvet/libva-intel for-dieter
Cloning into for-dieter...
remote: Counting objects: 1632, done.
remote: Compressing objects: 100% (447/447), done.
remote: Total 1632 (delta 1174), reused 1632 (de
On Mon, Oct 17, 2011 at 03:54:03PM +0200, Dieter Mummenschanz wrote:
> Hi Daniel,
>
> I believe I tried that already but I'll give it another shot. To avoid
> another screw up: Can I check in proc or sysfs to see, if iommu is
> really disabled? I also have pcie_aspm=force set as kernel parameter t
Hi Daniel,
I believe I tried that already but I'll give it another shot. To avoid another
screw up: Can I check in proc or sysfs to see, if iommu is really disabled? I
also have pcie_aspm=force set as kernel parameter to save some watts but it
does not seem to contribute to the gpu hangs.
---
On Mon, Oct 17, 2011 at 02:37:21PM +0200, Dieter Mummenschanz wrote:
> Hi Daniel,
>
> no problem. dmesg.log attached.
> To reproduce the hang: try to play two or more bluray streams at once
> and probably a hires wmv stream as well using mplayer-vaapi. also run a
> opengl game like Quake3 or prbo
This adds a new function intel_drm_get_valid_edid, which attempts to detect
EDID values from available devices and returns quickly in case no connection
is present. We detect non-existing devices by checking the i2c_transfer
status, and if it fails with the -ENXIO result, we know that the
i2c_algo
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.
As the advantage of such change, all the other routines which use
drm_get_edid would benefit for this timeout.
Th
Those are two identical fixes for improving EDID detection timings, which
also fix extremely slow xrandr queries in case of phantom outputs
(https://bugs.freedesktop.org/show_bug.cgi?id=41059)
The first fix is a small change to drm_edid, which prevents it from talking to
non-existent adapters by d
Hi,
I already did. Either the stream is too short or the low bitrate doesn't cause
enough rc6 state changes :-(.
Regards,
Dieter
Original-Nachricht
> Datum: Mon, 17 Oct 2011 14:13:34 +0200
> Von: Gwenole Beauchesne
> An: Daniel Vetter
> CC: Dieter Mummenschanz ,
> intel-gfx
Hi Daniel,
no problem. dmesg.log attached.
To reproduce the hang: try to play two or more bluray streams at once and
probably a hires wmv stream as well using mplayer-vaapi. also run a opengl game
like Quake3 or prboom-plus (http://prboom-plus.sourceforge.net). You'll need an
additional "pwad"
On Mon, Oct 17, 2011 at 01:58:03PM +0200, Daniel Vetter wrote:
> On Mon, Oct 17, 2011 at 01:45:28PM +0200, Dieter Mummenschanz wrote:
> > Hi Daniel,
> >
> > first of all I've seemed to screwed up my rc6 kernel parameters causing
> > rc6 to be enabled in all my previous tests even though I thought
On Mon, Oct 17, 2011 at 01:45:28PM +0200, Dieter Mummenschanz wrote:
> Hi Daniel,
>
> first of all I've seemed to screwed up my rc6 kernel parameters causing
> rc6 to be enabled in all my previous tests even though I thought it was
> disbaled. Sorry for that! Some new tests with i915_enable_rc6 de
43 matches
Mail list logo
