<div dir="ltr"><div><div><div><div><div>Sorry for misspelling your name, Russell, wasn't on purpose. </div>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. </div>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. </div>I just can say for sure that the above code does circumvent all the MMU faults I am getting with Ubuntu MATE at 1024x768. </div>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. </div>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; } }<div><div><div><div> </div></div></div></div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Nov 3, 2017 at 11:29 AM, Russell King - ARM Linux <<a href="mailto:linux@armlinux.org.uk" target="_blank">linux@armlinux.org.uk</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Nov 03, 2017 at 10:45:04AM +0000, Luís Mendes wrote: > Hi Russel, "Russell" ;) <div><div class="h5"> > 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; > } > > > > > > > > > > > > </div></div>> * 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. <div class="HOEnZb"><div class="h5"> -- RMK's Patch system: <a href="http://www.armlinux.org.uk/developer/patches/" rel="noreferrer" target="_blank">http://www.armlinux.org.uk/developer/patches/</a> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to <a href="http://speedtest.net" rel="noreferrer" target="_blank">speedtest.net</a>: 8.21Mbps down 510kbps up </div></div></blockquote></div> </div></div>