etnaviv-gpu 134000.gpu: MMU fault status 0x00000002 on i.XM6 Quad Plus
Luís Mendes
luis.p.mendes at gmail.com
Fri Nov 3 11:43:56 UTC 2017
Sorry for misspelling your name, Russell, wasn't on purpose.
Regarding what you said, the above code is correct, it is not the
copy_to_vtemp branch that is causing the MMU faults or screen corruption,
but rather when the code of etnaviv_aquire_src(...) runs to the end,
returning vSrc.
For some reason the kernel dump wasn't capturing the correct failure
source. Possibly the MMU faults occur a bit after when another operation is
being started, I don't know.
I just can say for sure that the above code does circumvent all the MMU
faults I am getting with Ubuntu MATE at 1024x768.
I will try to add the picture_desc() helper for us to get more details
regarding the source of the MMU fault condition, will get back soon.
I've refined the code circumvent to this one:
if (clip->x2 == 1024 && clip->y2 == 24) {
syslog(LOG_ERR, "A: clip[x1=%d,y1=%d], vSrc[w=%d,h=%d],
drawable[x=%d,y=%d], src_offset[x=%d,y=%d}\n",
clip->x1, clip->y1, vSrc->width, vSrc->height, drawable->x,
drawable->y, src_offset.x, src_offset.y);
if (vSrc->height == 768) {
goto fallback;
}
}
if (clip->x2 == 1024 && clip->y2 == 27) {
syslog(LOG_ERR, "B: clip[x1=%d,y1=%d], vSrc[w=%d,h=%d],
drawable[x=%d,y=%d], src_offset[x=%d,y=%d}\n",
clip->x1, clip->y1, vSrc->width, vSrc->height, drawable->x,
drawable->y, src_offset.x, src_offset.y);
if (vSrc->height == 768) {
goto fallback;
}
}
On Fri, Nov 3, 2017 at 11:29 AM, Russell King - ARM Linux <
linux at armlinux.org.uk> wrote:
> On Fri, Nov 03, 2017 at 10:45:04AM +0000, Luís Mendes wrote:
> > Hi Russel,
>
> "Russell" ;)
>
> > I was able to identify and circumvent the root cause of the MMU faults.
> We
> > had 4 MMU faults, it seems.
> > Each one for each of these conditions:
> > Nov 3 10:26:26 picolo xf86_armada[1271]: A: clip[x1=0,y1=0],
> > vSrc[w=1024,h=768], drawable[x=0,y=0], src_offset[x=0,y=0}
> > Nov 3 10:26:26 picolo xf86_armada[1271]: A: clip[x1=0,y1=0],
> > vSrc[w=1024,h=768], drawable[x=0,y=0], src_offset[x=0,y=0}
> > Nov 3 10:26:29 picolo xf86_armada[1271]: B: clip[x1=0,y1=0],
> > vSrc[w=1024,h=768], drawable[x=0,y=0], src_offset[x=0,y=0}
> > Nov 3 10:26:32 picolo xf86_armada[1271]: B: clip[x1=0,y1=0],
> > vSrc[w=1024,h=27], drawable[x=0,y=0], src_offset[x=0,y=0}
> >
> > The modified etnaviv_render.c - etnaviv_acquire_src(...), that is able to
> > circumvent the MMU faults and generate the above log is this one (changes
> > in bold):
> > static struct etnaviv_pixmap *etnaviv_acquire_src(ScreenPtr pScreen,
> > PicturePtr pict, const BoxRec *clip, PixmapPtr *ppPixTemp,
> > xPoint *src_topleft, Bool force_vtemp)
> > {
> > struct etnaviv *etnaviv = etnaviv_get_screen_priv(pScreen);
> > struct etnaviv_pixmap *vSrc, *vTemp;
> > struct etnaviv_blend_op copy_op;
> > DrawablePtr drawable;
> > uint32_t colour;
> > xPoint src_offset;
> > int tx, ty;
> >
> > if (etnaviv_pict_solid_argb(pict, &colour)) {
> > vTemp = etnaviv_get_scratch_argb(pScreen, ppPixTemp,
> > clip->x2, clip->y2);
> > if (!vTemp)
> > return NULL;
> >
> > if (!etnaviv_fill_single(etnaviv, vTemp, clip, colour))
> > return NULL;
> >
> > src_topleft->x = 0;
> > src_topleft->y = 0;
> > return vTemp;
> > }
> >
> > drawable = pict->pDrawable;
> > vSrc = etnaviv_drawable_offset(drawable, &src_offset);
> > if (!vSrc)
> > goto fallback;
> >
> > if (vSrc->width < clip->x2 || vSrc->height < clip->y2)
> > goto fallback;
> >
> > etnaviv_set_format(vSrc, pict);
> > if (!etnaviv_src_format_valid(etnaviv, vSrc->pict_format))
> > goto fallback;
> >
> > if (!transform_is_integer_translation(pict->transform, &tx, &ty))
> > goto fallback;
> >
> > if (picture_needs_repeat(pict, src_topleft->x + tx, src_topleft->y +
> ty,
> > clip->x2, clip->y2))
> > goto fallback;
> >
> >
> >
> > src_topleft->x += drawable->x + src_offset.x + tx;
> > src_topleft->y += drawable->y + src_offset.y + ty;
> > if (force_vtemp) {
> > goto copy_to_vtemp;
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > * if (clip->x2 == 1024 && clip->y2 == 24) { syslog(LOG_ERR, "A:
> > clip[x1=%d,y1=%d], vSrc[w=%d,h=%d], drawable[x=%d,y=%d],
> > src_offset[x=%d,y=%d}\n", clip->x1, clip->y1, vSrc->width,
> > vSrc->height, drawable->x, drawable->y, src_offset.x, src_offset.y);
> > goto fallback; } if (clip->x2 == 1024 && clip->y2 == 27) {
> > syslog(LOG_ERR, "B: clip[x1=%d,y1=%d], vSrc[w=%d,h=%d],
> > drawable[x=%d,y=%d], src_offset[x=%d,y=%d}\n", clip->x1,
> > clip->y1, vSrc->width, vSrc->height, drawable->x, drawable->y,
> > src_offset.x, src_offset.y); goto fallback; }*
> > return vSrc;
> > ...
>
> I'm not sure if the above is what you wanted to send - but I don't read
> email using a mailer that understands HTML, so the above is what I saw.
> "bold" doesn't work for the plain text part of emails, nor do colours!
>
> It looks like you added your debugging to the fall-through path, where
> we use the provided source picture/drawable. Is that the path that's
> giving the problems - I thought the faults were coming from the
> etnaviv_render() call from this function, which implies that we need
> to be taking the "copy_to_vtemp" branch of the if() statement above.
>
> Note, it's worth using the picture_desc() helper to print the details
> of the PicturePtr - this includes the basic details of the picture,
> and the underlying drawable. Also, please include the src_topleft
> coordinates - I think you'll find one of those will be 0,-24.
>
> I think the question is why we're ending up with the source top-left
> being 0,-24.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps
> up
> According to speedtest.net: 8.21Mbps down 510kbps up
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/etnaviv/attachments/20171103/df467a35/attachment.html>
More information about the etnaviv
mailing list