Bug 16911 - xserver EXA optimization causes nv31 to crash
Summary: xserver EXA optimization causes nv31 to crash
Status: RESOLVED DUPLICATE of bug 16908
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-30 16:03 UTC by Stuart Bennett
Modified: 2008-07-31 02:01 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Kernel log (34.13 KB, text/plain)
2008-07-30 16:03 UTC, Stuart Bennett
no flags Details
Xorg log (71.46 KB, text/plain)
2008-07-30 16:05 UTC, Stuart Bennett
no flags Details

Description Stuart Bennett 2008-07-30 16:03:44 UTC
Created attachment 18015 [details]
Kernel log

Following the commit of a3afa6f2fb80489f7b6a88d12def09281d32ed94 "EXA: Optimize GXcopy tiled fills." to the xserver, the nouveau driver (git HEAD of both ddx and drm) will crash on certain webpages, with

[drm] PGRAPH_ERROR - nSource: LIMIT_COLOR, nStatus: PROTECTION_FAULT
[drm] PGRAPH_ERROR - Ch 1/6 Class 0x009f Mthd 0x0308 Data 0x00000003:0x00f304f8

in the kernel log and a fifo lockup in the ddx log -- both attached. A simple reproducible case is using Firefox (2.0.0.16) on http://people.freedesktop.org/~stuart/pgraph_limit_color/crash.html
Going back to the previous xserver commit "EXA: Replace open coded CopyArea logic with GC op call.", the page does not cause the driver error, nor a crash.

black.png used in the page was simply created in the GIMP using a new image and a bucket fill. I suspect the size of the background image is a factor, as tests using a 200x200 PNG did not crash.
Comment 1 Stuart Bennett 2008-07-30 16:05:02 UTC
Created attachment 18016 [details]
Xorg log
Comment 2 Stephane Marchesin 2008-07-30 18:21:36 UTC
Michel, I would think the following changes are required

                                                                                                                 -width = min(pBox[i].x2 - dstX, width * 2);                                                                                                +width = min(pBox[i].x2 - dstX, min(width * 2, tileWidth));

-height = min(pBox[i].y2 - dstY, height * 2);
+height = min(pBox[i].y2 - dstY, min(height * 2, tileHeight));

That doesn't solve our issue though.
Comment 3 Stephane Marchesin 2008-07-30 18:27:23 UTC
Scrap my last comment, I'm too tired. Don't scrap the bug though :)
Comment 4 Stephane Marchesin 2008-07-30 18:57:14 UTC
So, there seems to be some issue with the first width/height computation ; something like this helps:

-int width = min(pBox[i].x2 - pBox[i].x1, tileWidth);
-int height = min(pBox[i].y2 - pBox[i].y1, tileHeight);

+int width = min(pBox[i].x2 - pBox[i].x1 - tileWidth, tileWidth);
+int height = min(pBox[i].y2 - pBox[i].y1 - tileHeight, tileHeight);

Otherwise you start the 2nd copy (first one in the while loop) with the full tile size, and this can be bigger than the total size.
Comment 5 Stuart Bennett 2008-07-30 19:04:15 UTC
Some things tried as detailed in 
http://people.freedesktop.org/~marcheu/irclogs/nouveau-2008-07-31

Last attempt replacing the width and height defintions/instantiations with:
int width = min(pBox[i].x2 - pBox[i].x1 - tileWidth, tileWidth);
int height = min(pBox[i].y2 - pBox[i].y1 - tileHeight, tileHeight);

fixed the test case, but lead to other problems shortly after -- xorg log with the arguments to *pExaScr->info->Copy() printed at http://people.freedesktop.org/~stuart/Xorg.0.log.old-big.txt shows some huge negative widths and heights being passed, before an endless succession of calls with height=0.
Comment 6 Michel Dänzer 2008-07-31 02:01:47 UTC
I think this is a duplicate, please reopen otherwise.

*** This bug has been marked as a duplicate of bug 16908 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.