[Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT
Chasing wild speculation that we may be writing the wrong addresses
into the GTT for stolen objects, I would like to inspect those values.
Also to aide debugging ENOSPC issues with fragmentation, order the
object list by ascending GTT order so that holes are more easily seen.
Signed-off-by: Chris Wilson
Cc: Sedat Dilek
---
drivers/gpu/drm/i915/i915_debugfs.c | 72 -
1 file changed, 71 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 053353e4d139..30542286d019 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -423,6 +423,61 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
return 0;
}
+static int i915_gem_gtt_contents(struct seq_file *m, struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ gen6_gtt_pte_t __iomem *gtt_entries;
+ gen6_gtt_pte_t scratch_pte;
+ gen6_gtt_pte_t zero[8] = {};
+ int i, j, last_zero = 0;
+ int ret;
+
+ if (INTEL_INFO(dev)->gen < 6)
+ return 0;
+
+ ret = mutex_lock_interruptible(&dev->struct_mutex);
+ if (ret)
+ return ret;
+
+ gtt_entries = (gen6_gtt_pte_t __iomem *)dev_priv->gtt.gsm;
+ scratch_pte =
dev_priv->gtt.base.pte_encode(dev_priv->gtt.base.scratch.addr, I915_CACHE_LLC,
true);
+ for (i = 0; i < gtt_total_entries(dev_priv->gtt); i += 8) {
+ gen6_gtt_pte_t pte[8];
+ int this_zero;
+
+ for (j = 0; j < 8; j++) {
+ pte[j] = ioread32(>t_entries[i+j]);
+ if (pte[j] == scratch_pte)
+ pte[j] = 0;
+ if ((pte[j] & 1) == 0)
+ pte[j] = 0;
+ }
+
+ this_zero = memcmp(pte, zero, sizeof(pte)) == 0;
+ if (last_zero && this_zero) {
+ if (last_zero++ == 1)
+ seq_puts(m, "...\n");
+ continue;
+ }
+
+ seq_printf(m, "[%08x] %08x %08x %08x %08x %08x %08x %08x
%08x\n",
+ i, pte[0], pte[1], pte[2], pte[3], pte[4], pte[5],
pte[6], pte[7]);
+ last_zero = this_zero;
+ }
+
+ mutex_unlock(&dev->struct_mutex);
+
+ return 0;
+}
+
+static int obj_rank_by_ggtt(void *priv, struct list_head *A, struct list_head
*B)
+{
+ struct drm_i915_gem_object *a = list_entry(A, typeof(*a),
obj_exec_link);
+ struct drm_i915_gem_object *b = list_entry(B, typeof(*b),
obj_exec_link);
+
+ return i915_gem_obj_ggtt_offset(a) - i915_gem_obj_ggtt_offset(b);
+}
+
static int i915_gem_gtt_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = (struct drm_info_node *) m->private;
@@ -430,6 +485,7 @@ static int i915_gem_gtt_info(struct seq_file *m, void *data)
uintptr_t list = (uintptr_t) node->info_ent->data;
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_object *obj;
+ struct list_head sorted;
size_t total_obj_size, total_gtt_size;
int count, ret;
@@ -437,11 +493,22 @@ static int i915_gem_gtt_info(struct seq_file *m, void
*data)
if (ret)
return ret;
+ INIT_LIST_HEAD(&sorted);
+
total_obj_size = total_gtt_size = count = 0;
list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) {
if (list == PINNED_LIST && obj->pin_count == 0)
continue;
+ list_add(&obj->obj_exec_link, &sorted);
+ }
+
+ list_sort(NULL, &sorted, obj_rank_by_ggtt);
+
+ while (!list_empty(&sorted)) {
+ obj = list_first_entry(&sorted, typeof(*obj), obj_exec_link);
+ list_del_init(&obj->obj_exec_link);
+
seq_puts(m, " ");
describe_obj(m, obj);
seq_putc(m, '\n');
@@ -455,7 +522,10 @@ static int i915_gem_gtt_info(struct seq_file *m, void
*data)
seq_printf(m, "Total %d objects, %zu bytes, %zu GTT size\n",
count, total_obj_size, total_gtt_size);
- return 0;
+ if (list == PINNED_LIST)
+ return 0;
+
+ return i915_gem_gtt_contents(m, dev);
}
static int i915_gem_pageflip_info(struct seq_file *m, void *data)
--
1.8.4.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT
On Sun, Sep 01, 2013 at 03:59:00PM +0200, Sedat Dilek wrote:
> Hi Chris,
>
> is this going into any drm-intel GIT tree?
> I found it useful and saw it in your kernel-tree [1].
>
> - Sedat -
>
> [1]
> http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?id=bf91098a1232db771feac66f88720c181ef61967
It can already be accomplished with the intel_gtt tool in the
intel-gpu-tools suite.
>
> On Wed, Aug 14, 2013 at 1:35 PM, Chris Wilson
> wrote:
> > Chasing wild speculation that we may be writing the wrong addresses
> > into the GTT for stolen objects, I would like to inspect those values.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Sedat Dilek
> > ---
> >
> > Sedak, can you please apply this patch and then attach the contents of
> > /sys/kernel/debug/dri/0/i915_gem_gtt with the broken display?
> >
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 47
> > -
> > 1 file changed, 46 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 10d864c..4edf65a 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -390,6 +390,51 @@ static int i915_gem_object_info(struct seq_file *m,
> > void* data)
> > return 0;
> > }
> >
> > +static int i915_gem_gtt_contents(struct seq_file *m, struct drm_device
> > *dev)
> > +{
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + gen6_gtt_pte_t __iomem *gtt_entries;
> > + gen6_gtt_pte_t scratch_pte;
> > + gen6_gtt_pte_t zero[8] = {};
> > + int i, j, last_zero = 0;
> > + int ret;
> > +
> > + if (INTEL_INFO(dev)->gen < 6)
> > + return 0;
> > +
> > + ret = mutex_lock_interruptible(&dev->struct_mutex);
> > + if (ret)
> > + return ret;
> > +
> > + gtt_entries = (gen6_gtt_pte_t __iomem *)dev_priv->gtt.gsm;
> > + scratch_pte =
> > dev_priv->gtt.base.pte_encode(dev_priv->gtt.base.scratch.addr,
> > I915_CACHE_LLC);
> > + for (i = 0; i < gtt_total_entries(dev_priv->gtt); i += 8) {
> > + gen6_gtt_pte_t pte[8];
> > + int this_zero;
> > +
> > + for (j = 0; j < 8; j++) {
> > + pte[j] = ioread32(>t_entries[i+j]);
> > + if (pte[j] == scratch_pte)
> > + pte[j] = 0;
> > + }
> > +
> > + this_zero = memcmp(pte, zero, sizeof(pte)) == 0;
> > + if (last_zero && this_zero) {
> > + if (last_zero++ == 1)
> > + seq_puts(m, "...\n");
> > + continue;
> > + }
> > +
> > + seq_printf(m, "[%08x] %08x %08x %08x %08x %08x %08x %08x
> > %08x\n",
> > + i, pte[0], pte[1], pte[2], pte[3], pte[4],
> > pte[5], pte[6], pte[7]);
> > + last_zero = this_zero;
> > + }
> > +
> > + mutex_unlock(&dev->struct_mutex);
> > +
> > + return 0;
> > +}
> > +
> > static int i915_gem_gtt_info(struct seq_file *m, void *data)
> > {
> > struct drm_info_node *node = (struct drm_info_node *) m->private;
> > @@ -422,7 +467,7 @@ static int i915_gem_gtt_info(struct seq_file *m, void
> > *data)
> > seq_printf(m, "Total %d objects, %zu bytes, %zu GTT size\n",
> >count, total_obj_size, total_gtt_size);
> >
> > - return 0;
> > + return i915_gem_gtt_contents(m, dev);
> > }
> >
> > static int i915_gem_pageflip_info(struct seq_file *m, void *data)
> > --
> > 1.8.4.rc2
> >
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT
Hi Chris,
is this going into any drm-intel GIT tree?
I found it useful and saw it in your kernel-tree [1].
- Sedat -
[1]
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?id=bf91098a1232db771feac66f88720c181ef61967
On Wed, Aug 14, 2013 at 1:35 PM, Chris Wilson wrote:
> Chasing wild speculation that we may be writing the wrong addresses
> into the GTT for stolen objects, I would like to inspect those values.
>
> Signed-off-by: Chris Wilson
> Cc: Sedat Dilek
> ---
>
> Sedak, can you please apply this patch and then attach the contents of
> /sys/kernel/debug/dri/0/i915_gem_gtt with the broken display?
>
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 47
> -
> 1 file changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 10d864c..4edf65a 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -390,6 +390,51 @@ static int i915_gem_object_info(struct seq_file *m,
> void* data)
> return 0;
> }
>
> +static int i915_gem_gtt_contents(struct seq_file *m, struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + gen6_gtt_pte_t __iomem *gtt_entries;
> + gen6_gtt_pte_t scratch_pte;
> + gen6_gtt_pte_t zero[8] = {};
> + int i, j, last_zero = 0;
> + int ret;
> +
> + if (INTEL_INFO(dev)->gen < 6)
> + return 0;
> +
> + ret = mutex_lock_interruptible(&dev->struct_mutex);
> + if (ret)
> + return ret;
> +
> + gtt_entries = (gen6_gtt_pte_t __iomem *)dev_priv->gtt.gsm;
> + scratch_pte =
> dev_priv->gtt.base.pte_encode(dev_priv->gtt.base.scratch.addr,
> I915_CACHE_LLC);
> + for (i = 0; i < gtt_total_entries(dev_priv->gtt); i += 8) {
> + gen6_gtt_pte_t pte[8];
> + int this_zero;
> +
> + for (j = 0; j < 8; j++) {
> + pte[j] = ioread32(>t_entries[i+j]);
> + if (pte[j] == scratch_pte)
> + pte[j] = 0;
> + }
> +
> + this_zero = memcmp(pte, zero, sizeof(pte)) == 0;
> + if (last_zero && this_zero) {
> + if (last_zero++ == 1)
> + seq_puts(m, "...\n");
> + continue;
> + }
> +
> + seq_printf(m, "[%08x] %08x %08x %08x %08x %08x %08x %08x
> %08x\n",
> + i, pte[0], pte[1], pte[2], pte[3], pte[4], pte[5],
> pte[6], pte[7]);
> + last_zero = this_zero;
> + }
> +
> + mutex_unlock(&dev->struct_mutex);
> +
> + return 0;
> +}
> +
> static int i915_gem_gtt_info(struct seq_file *m, void *data)
> {
> struct drm_info_node *node = (struct drm_info_node *) m->private;
> @@ -422,7 +467,7 @@ static int i915_gem_gtt_info(struct seq_file *m, void
> *data)
> seq_printf(m, "Total %d objects, %zu bytes, %zu GTT size\n",
>count, total_obj_size, total_gtt_size);
>
> - return 0;
> + return i915_gem_gtt_contents(m, dev);
> }
>
> static int i915_gem_pageflip_info(struct seq_file *m, void *data)
> --
> 1.8.4.rc2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT
On Fri, Aug 16, 2013 at 10:34 AM, Sedat Dilek wrote: > On Fri, Aug 16, 2013 at 9:39 AM, Chris Wilson > wrote: >> On Fri, Aug 16, 2013 at 09:24:01AM +0200, Sedat Dilek wrote: >>> On Thu, Aug 15, 2013 at 12:13 PM, Chris Wilson >>> wrote: >>> > I've just pushed a (cairo-based!) tool to intel-gpu-tools, >>> > intel_framebuffer_dump, that should also confirm everything we've found >>> > so far - i.e. that we read and write consistently through the GTT into >>> > stolen memory. Which just leaves the step between memory and the >>> > display. >>> >>> Thanks. >>> This still forces me to upgrade to a higher cairo version, not sure >>> which to which more depends this will lead. >>> >>> So, the root-cause for my issue is not intel-gfx related? >>> BIOS? Quirk needed? >>> Other areas? >> >> No, I am pretty sure it is our evil hardware tormenting us. Daniel made >> one suggestion to remove the rmw from DISPBASE i.e. revert >> >> commit 446f254566ea8911c9e19c7bc8a162fc0e53cf31 >> Author: Armin Reese >> Date: Fri Mar 30 16:20:16 2012 -0700 >> >> drm/i915: Mask reserved bits in display/sprite address registers >> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h >> b/drivers/gpu/drm/i915/i915_reg.h >> index e2690ec..56ac7df 100644 >> --- a/drivers/gpu/drm/i915/i915_reg.h >> +++ b/drivers/gpu/drm/i915/i915_reg.h >> @@ -3370,8 +3370,7 @@ >> #define DISP_BASEADDR_MASK (0xf000) >> #define I915_LO_DISPBASE(val) (val & ~DISP_BASEADDR_MASK) >> #define I915_HI_DISPBASE(val) (val & DISP_BASEADDR_MASK) >> -#define I915_MODIFY_DISPBASE(reg, gfx_addr) \ >> - (I915_WRITE((reg), (gfx_addr) | >> I915_LO_DISPBASE(I915_READ(reg >> +#define I915_MODIFY_DISPBASE(reg, gfx_addr) I915_WRITE((reg), (gfx_addr)) >> >> /* VBIOS flags */ >> #define SWF00 (dev_priv->info->display_mmio_offset + >> 0x71410) >> >> >> which avoids invoking suspiciously racy behaviour. > > Only that line or the complete commit? > The complete commit cannot be cleanly reverted. > I have tested... 1. Linux v3.11-rc as base 2. d-i-n (up to commit 89296cd1af88b0c8cec6a4806db6db236729decc, on top of 1) 3. with the attached patch (on top of 2) NO, this did not help here. - Sedat - 0001-drm-i915-Partly-revert-446f254566ea8911c9e19c7bc8a16.patch Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT
On Fri, Aug 16, 2013 at 9:39 AM, Chris Wilson wrote: > On Fri, Aug 16, 2013 at 09:24:01AM +0200, Sedat Dilek wrote: >> On Thu, Aug 15, 2013 at 12:13 PM, Chris Wilson >> wrote: >> > I've just pushed a (cairo-based!) tool to intel-gpu-tools, >> > intel_framebuffer_dump, that should also confirm everything we've found >> > so far - i.e. that we read and write consistently through the GTT into >> > stolen memory. Which just leaves the step between memory and the >> > display. >> >> Thanks. >> This still forces me to upgrade to a higher cairo version, not sure >> which to which more depends this will lead. >> >> So, the root-cause for my issue is not intel-gfx related? >> BIOS? Quirk needed? >> Other areas? > > No, I am pretty sure it is our evil hardware tormenting us. Daniel made > one suggestion to remove the rmw from DISPBASE i.e. revert > > commit 446f254566ea8911c9e19c7bc8a162fc0e53cf31 > Author: Armin Reese > Date: Fri Mar 30 16:20:16 2012 -0700 > > drm/i915: Mask reserved bits in display/sprite address registers > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index e2690ec..56ac7df 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -3370,8 +3370,7 @@ > #define DISP_BASEADDR_MASK (0xf000) > #define I915_LO_DISPBASE(val) (val & ~DISP_BASEADDR_MASK) > #define I915_HI_DISPBASE(val) (val & DISP_BASEADDR_MASK) > -#define I915_MODIFY_DISPBASE(reg, gfx_addr) \ > - (I915_WRITE((reg), (gfx_addr) | > I915_LO_DISPBASE(I915_READ(reg > +#define I915_MODIFY_DISPBASE(reg, gfx_addr) I915_WRITE((reg), (gfx_addr)) > > /* VBIOS flags */ > #define SWF00 (dev_priv->info->display_mmio_offset + > 0x71410) > > > which avoids invoking suspiciously racy behaviour. Only that line or the complete commit? The complete commit cannot be cleanly reverted. - Sedat - ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT
On Fri, Aug 16, 2013 at 09:24:01AM +0200, Sedat Dilek wrote: > On Thu, Aug 15, 2013 at 12:13 PM, Chris Wilson > wrote: > > I've just pushed a (cairo-based!) tool to intel-gpu-tools, > > intel_framebuffer_dump, that should also confirm everything we've found > > so far - i.e. that we read and write consistently through the GTT into > > stolen memory. Which just leaves the step between memory and the > > display. > > Thanks. > This still forces me to upgrade to a higher cairo version, not sure > which to which more depends this will lead. > > So, the root-cause for my issue is not intel-gfx related? > BIOS? Quirk needed? > Other areas? No, I am pretty sure it is our evil hardware tormenting us. Daniel made one suggestion to remove the rmw from DISPBASE i.e. revert commit 446f254566ea8911c9e19c7bc8a162fc0e53cf31 Author: Armin Reese Date: Fri Mar 30 16:20:16 2012 -0700 drm/i915: Mask reserved bits in display/sprite address registers diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index e2690ec..56ac7df 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3370,8 +3370,7 @@ #define DISP_BASEADDR_MASK (0xf000) #define I915_LO_DISPBASE(val) (val & ~DISP_BASEADDR_MASK) #define I915_HI_DISPBASE(val) (val & DISP_BASEADDR_MASK) -#define I915_MODIFY_DISPBASE(reg, gfx_addr) \ - (I915_WRITE((reg), (gfx_addr) | I915_LO_DISPBASE(I915_READ(reg +#define I915_MODIFY_DISPBASE(reg, gfx_addr) I915_WRITE((reg), (gfx_addr)) /* VBIOS flags */ #define SWF00 (dev_priv->info->display_mmio_offset + 0x71410) which avoids invoking suspiciously racy behaviour. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT
On Thu, Aug 15, 2013 at 12:13 PM, Chris Wilson wrote: > I've just pushed a (cairo-based!) tool to intel-gpu-tools, > intel_framebuffer_dump, that should also confirm everything we've found > so far - i.e. that we read and write consistently through the GTT into > stolen memory. Which just leaves the step between memory and the > display. Thanks. This still forces me to upgrade to a higher cairo version, not sure which to which more depends this will lead. So, the root-cause for my issue is not intel-gfx related? BIOS? Quirk needed? Other areas? ( I have seen some mm/soft-dirty fixes in mainline... Is CONFIG_MEM_SOFT_DIRTY=y an option to play with? Or how to interpret this snooped/LLC dirty outputs I had sent? ) - Sedat - P.S.: Commits in recent mainline: mm: save soft-dirty bits on file pages mm: save soft-dirty bits on swapped pages ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT
On Wed, Aug 14, 2013 at 3:44 PM, Chris Wilson wrote: > On Wed, Aug 14, 2013 at 03:02:37PM +0200, Sedat Dilek wrote: >> On Wed, Aug 14, 2013 at 3:01 PM, Sedat Dilek wrote: >> > On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson >> > wrote: >> >> On Wed, Aug 14, 2013 at 02:31:24PM +0200, Sedat Dilek wrote: >> >>> Requested output and dmesg files attached. >> >>> ( Should I attach the one with "BROKEN" display - I mean w/o doing a >> >>> re-login and display "REPAIRED"? ) >> >> >> >> Yes please. >> > >> > Attached tarball contains: >> > >> > 130413 Aug 14 14:52 >> > dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_0-before-relogin-lightdm-unity2d_VT-1.txt >> > 145973 Aug 14 14:53 >> > dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_1-before-relogin-lightdm-unity2d_X.txt >> > 199199 Aug 14 14:55 >> > dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_2_after-relogin-lightdm-unity2d_X.txt >> > >> > 79398 Aug 14 14:53 >> > i915_gem_gtt_drm-debug-6_1-before-relogin-lightdm-unity2d_X.txt >> > 108374 Aug 14 14:55 >> > i915_gem_gtt_drm-debug-6_2_after-relogin-lightdm-unity2d_X.txt > > The PTE values do correspond with the stolen addresses for the > framebuffer. So I am resonably confident that the driver is > self-consistent at least. DSPSURF points to the right location in the > GGTT and those entries point to the right location in stolen. The > display on the other hand seems to be continuing to read from GGTT > offset 0, and so the real framebuffer appears offset by a few lines. > > How about trying https://patchwork.kernel.org/patch/2841934/ ? The same screen corruption (see also attached tarball). - Sedat - for-ickle-3.tar.xz Description: Binary data for-ickle-3.tar.xz.sha256sum Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT
On Wed, Aug 14, 2013 at 03:02:37PM +0200, Sedat Dilek wrote: > On Wed, Aug 14, 2013 at 3:01 PM, Sedat Dilek wrote: > > On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson > > wrote: > >> On Wed, Aug 14, 2013 at 02:31:24PM +0200, Sedat Dilek wrote: > >>> Requested output and dmesg files attached. > >>> ( Should I attach the one with "BROKEN" display - I mean w/o doing a > >>> re-login and display "REPAIRED"? ) > >> > >> Yes please. > > > > Attached tarball contains: > > > > 130413 Aug 14 14:52 > > dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_0-before-relogin-lightdm-unity2d_VT-1.txt > > 145973 Aug 14 14:53 > > dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_1-before-relogin-lightdm-unity2d_X.txt > > 199199 Aug 14 14:55 > > dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_2_after-relogin-lightdm-unity2d_X.txt > > > > 79398 Aug 14 14:53 > > i915_gem_gtt_drm-debug-6_1-before-relogin-lightdm-unity2d_X.txt > > 108374 Aug 14 14:55 > > i915_gem_gtt_drm-debug-6_2_after-relogin-lightdm-unity2d_X.txt The PTE values do correspond with the stolen addresses for the framebuffer. So I am resonably confident that the driver is self-consistent at least. DSPSURF points to the right location in the GGTT and those entries point to the right location in stolen. The display on the other hand seems to be continuing to read from GGTT offset 0, and so the real framebuffer appears offset by a few lines. How about trying https://patchwork.kernel.org/patch/2841934/ ? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT
On Wed, Aug 14, 2013 at 3:02 PM, Sedat Dilek wrote: > On Wed, Aug 14, 2013 at 3:01 PM, Sedat Dilek wrote: >> On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson >> wrote: >>> On Wed, Aug 14, 2013 at 02:31:24PM +0200, Sedat Dilek wrote: Requested output and dmesg files attached. ( Should I attach the one with "BROKEN" display - I mean w/o doing a re-login and display "REPAIRED"? ) >>> >>> Yes please. >> >> Attached tarball contains: >> >> 130413 Aug 14 14:52 >> dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_0-before-relogin-lightdm-unity2d_VT-1.txt >> 145973 Aug 14 14:53 >> dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_1-before-relogin-lightdm-unity2d_X.txt >> 199199 Aug 14 14:55 >> dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_2_after-relogin-lightdm-unity2d_X.txt >> >> 79398 Aug 14 14:53 >> i915_gem_gtt_drm-debug-6_1-before-relogin-lightdm-unity2d_X.txt >> 108374 Aug 14 14:55 >> i915_gem_gtt_drm-debug-6_2_after-relogin-lightdm-unity2d_X.txt >> >> > > The real attachment. > A new tarball with... 1. booting into text-mode (no graphical mode, no X) 2. start lightdm service (upstart) 3. start unity-2d session and logout (re-enter lightdm greeter screen) - Sedat - for-ickle-2.tar.xz Description: Binary data for-ickle-2.tar.xz.sha256sum Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT
On Wed, Aug 14, 2013 at 3:01 PM, Sedat Dilek wrote: > On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson > wrote: >> On Wed, Aug 14, 2013 at 02:31:24PM +0200, Sedat Dilek wrote: >>> Requested output and dmesg files attached. >>> ( Should I attach the one with "BROKEN" display - I mean w/o doing a >>> re-login and display "REPAIRED"? ) >> >> Yes please. > > Attached tarball contains: > > 130413 Aug 14 14:52 > dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_0-before-relogin-lightdm-unity2d_VT-1.txt > 145973 Aug 14 14:53 > dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_1-before-relogin-lightdm-unity2d_X.txt > 199199 Aug 14 14:55 > dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_2_after-relogin-lightdm-unity2d_X.txt > > 79398 Aug 14 14:53 > i915_gem_gtt_drm-debug-6_1-before-relogin-lightdm-unity2d_X.txt > 108374 Aug 14 14:55 > i915_gem_gtt_drm-debug-6_2_after-relogin-lightdm-unity2d_X.txt > > The real attachment. - Sedat - for-ickle.tar.xz.sha256sum Description: Binary data for-ickle.tar.xz Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT
On Wed, Aug 14, 2013 at 2:52 PM, Chris Wilson wrote: > On Wed, Aug 14, 2013 at 02:31:24PM +0200, Sedat Dilek wrote: >> Requested output and dmesg files attached. >> ( Should I attach the one with "BROKEN" display - I mean w/o doing a >> re-login and display "REPAIRED"? ) > > Yes please. Attached tarball contains: 130413 Aug 14 14:52 dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_0-before-relogin-lightdm-unity2d_VT-1.txt 145973 Aug 14 14:53 dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_1-before-relogin-lightdm-unity2d_X.txt 199199 Aug 14 14:55 dmesg_3.11.0-rc5-next20130814-1-iniza-small_drm-debug-6_2_after-relogin-lightdm-unity2d_X.txt 79398 Aug 14 14:53 i915_gem_gtt_drm-debug-6_1-before-relogin-lightdm-unity2d_X.txt 108374 Aug 14 14:55 i915_gem_gtt_drm-debug-6_2_after-relogin-lightdm-unity2d_X.txt - Sedat - ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT
On Wed, Aug 14, 2013 at 02:31:24PM +0200, Sedat Dilek wrote: > Requested output and dmesg files attached. > ( Should I attach the one with "BROKEN" display - I mean w/o doing a > re-login and display "REPAIRED"? ) Yes please. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT
On Wed, Aug 14, 2013 at 1:35 PM, Chris Wilson wrote:
> Chasing wild speculation that we may be writing the wrong addresses
> into the GTT for stolen objects, I would like to inspect those values.
>
> Signed-off-by: Chris Wilson
> Cc: Sedat Dilek
> ---
>
> Sedak, can you please apply this patch and then attach the contents of
> /sys/kernel/debug/dri/0/i915_gem_gtt with the broken display?
>
Compiling... next-20130814 with drm-intel-nightly (up to commit
d93f59e86ae93066969fa8ae2a6c9ccc7fc4728d) plus this patch.
How do you want your Doner-Kebap? (Going into the city...)
- Sedat -
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 47
> -
> 1 file changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 10d864c..4edf65a 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -390,6 +390,51 @@ static int i915_gem_object_info(struct seq_file *m,
> void* data)
> return 0;
> }
>
> +static int i915_gem_gtt_contents(struct seq_file *m, struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + gen6_gtt_pte_t __iomem *gtt_entries;
> + gen6_gtt_pte_t scratch_pte;
> + gen6_gtt_pte_t zero[8] = {};
> + int i, j, last_zero = 0;
> + int ret;
> +
> + if (INTEL_INFO(dev)->gen < 6)
> + return 0;
> +
> + ret = mutex_lock_interruptible(&dev->struct_mutex);
> + if (ret)
> + return ret;
> +
> + gtt_entries = (gen6_gtt_pte_t __iomem *)dev_priv->gtt.gsm;
> + scratch_pte =
> dev_priv->gtt.base.pte_encode(dev_priv->gtt.base.scratch.addr,
> I915_CACHE_LLC);
> + for (i = 0; i < gtt_total_entries(dev_priv->gtt); i += 8) {
> + gen6_gtt_pte_t pte[8];
> + int this_zero;
> +
> + for (j = 0; j < 8; j++) {
> + pte[j] = ioread32(>t_entries[i+j]);
> + if (pte[j] == scratch_pte)
> + pte[j] = 0;
> + }
> +
> + this_zero = memcmp(pte, zero, sizeof(pte)) == 0;
> + if (last_zero && this_zero) {
> + if (last_zero++ == 1)
> + seq_puts(m, "...\n");
> + continue;
> + }
> +
> + seq_printf(m, "[%08x] %08x %08x %08x %08x %08x %08x %08x
> %08x\n",
> + i, pte[0], pte[1], pte[2], pte[3], pte[4], pte[5],
> pte[6], pte[7]);
> + last_zero = this_zero;
> + }
> +
> + mutex_unlock(&dev->struct_mutex);
> +
> + return 0;
> +}
> +
> static int i915_gem_gtt_info(struct seq_file *m, void *data)
> {
> struct drm_info_node *node = (struct drm_info_node *) m->private;
> @@ -422,7 +467,7 @@ static int i915_gem_gtt_info(struct seq_file *m, void
> *data)
> seq_printf(m, "Total %d objects, %zu bytes, %zu GTT size\n",
>count, total_obj_size, total_gtt_size);
>
> - return 0;
> + return i915_gem_gtt_contents(m, dev);
> }
>
> static int i915_gem_pageflip_info(struct seq_file *m, void *data)
> --
> 1.8.4.rc2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT
Chasing wild speculation that we may be writing the wrong addresses
into the GTT for stolen objects, I would like to inspect those values.
Signed-off-by: Chris Wilson
Cc: Sedat Dilek
---
Sedak, can you please apply this patch and then attach the contents of
/sys/kernel/debug/dri/0/i915_gem_gtt with the broken display?
---
drivers/gpu/drm/i915/i915_debugfs.c | 47 -
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 10d864c..4edf65a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -390,6 +390,51 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
return 0;
}
+static int i915_gem_gtt_contents(struct seq_file *m, struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ gen6_gtt_pte_t __iomem *gtt_entries;
+ gen6_gtt_pte_t scratch_pte;
+ gen6_gtt_pte_t zero[8] = {};
+ int i, j, last_zero = 0;
+ int ret;
+
+ if (INTEL_INFO(dev)->gen < 6)
+ return 0;
+
+ ret = mutex_lock_interruptible(&dev->struct_mutex);
+ if (ret)
+ return ret;
+
+ gtt_entries = (gen6_gtt_pte_t __iomem *)dev_priv->gtt.gsm;
+ scratch_pte =
dev_priv->gtt.base.pte_encode(dev_priv->gtt.base.scratch.addr, I915_CACHE_LLC);
+ for (i = 0; i < gtt_total_entries(dev_priv->gtt); i += 8) {
+ gen6_gtt_pte_t pte[8];
+ int this_zero;
+
+ for (j = 0; j < 8; j++) {
+ pte[j] = ioread32(>t_entries[i+j]);
+ if (pte[j] == scratch_pte)
+ pte[j] = 0;
+ }
+
+ this_zero = memcmp(pte, zero, sizeof(pte)) == 0;
+ if (last_zero && this_zero) {
+ if (last_zero++ == 1)
+ seq_puts(m, "...\n");
+ continue;
+ }
+
+ seq_printf(m, "[%08x] %08x %08x %08x %08x %08x %08x %08x
%08x\n",
+ i, pte[0], pte[1], pte[2], pte[3], pte[4], pte[5],
pte[6], pte[7]);
+ last_zero = this_zero;
+ }
+
+ mutex_unlock(&dev->struct_mutex);
+
+ return 0;
+}
+
static int i915_gem_gtt_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = (struct drm_info_node *) m->private;
@@ -422,7 +467,7 @@ static int i915_gem_gtt_info(struct seq_file *m, void *data)
seq_printf(m, "Total %d objects, %zu bytes, %zu GTT size\n",
count, total_obj_size, total_gtt_size);
- return 0;
+ return i915_gem_gtt_contents(m, dev);
}
static int i915_gem_pageflip_info(struct seq_file *m, void *data)
--
1.8.4.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
