David Dawes
dawes****@XFree*****
2003年 8月 15日 (金) 11:23:53 JST
On Thu, Aug 14, 2003 at 09:55:37PM -0400, David Dawes wrote:
>On Thu, Aug 14, 2003 at 04:17:41PM -0700, Mark Vojkovich wrote:
>>On Thu, 14 Aug 2003, David Dawes wrote:
>>
>>> >
>>> > XAACacheTile() should have never been called if no slots existed.
>>> >MaxCacheableTileWidth and MaxCacheableTileHeight should have been
>>> >consulted at some point.
>>>
>>> OK, we need to see what those values are at this point. XAAPaintWindow(),
>>> where the crash is apparently happening, does have a test for them, so
>>> maybe there's getting set incorrectly somewhere.
>>>
>>> if(infoRec->UsingPixmapCache &&
>>> infoRec->FillCacheBltRects && !NoCache &&
>>> ((what == PW_BORDER) ||
>>> (pPix->drawable.height != pWin->drawable.height) ||
>>> (pPix->drawable.width != pWin->drawable.width)) &&
>>> (pPix->drawable.height <= infoRec->MaxCacheableTileHeight) &&
>>> (pPix->drawable.width <= infoRec->MaxCacheableTileWidth)) {
>>>
>>> XAACacheInfoPtr pCache =
>>> (*infoRec->CacheTile)(infoRec->pScrn, pPix);
>>> (*infoRec->FillCacheBltRects)(infoRec->pScrn, GXcopy, ~0,
>>> nBox, pBox, xorg, yorg, pCache);
>>> return;
>>> }
>>>
>>> This check assumes that if there are no 256x256 slots there won't
>>> be any 512x512 slots. I'm not 100% sure if it can ever happen that
>>> there are 512x512 slots but no 256x256 slots. If the debugging
>>> could be extended to print both infoRec->MaxCacheableTileHeight
>>> and Num512, it should clarify if this is the problem or not.
>>
>> It's expected that if there are 512x512 slots there will be
>>smaller slots. The logic that sets up the slots in XAAInitPixmapCache
>>is supposed to ensure that.
>
>I played around a little with some unusual cases. If the memory is very
>fragmented, I can find a case where there are 4 512x512 slots and no
>256x256 slots. The trick here is to have enough boxes for 4 512 slots
>and lots of 128 slots, but none for any 256 slots to get allocated in
>the first round. If there are enough 128x128 slots, the target for
>512x512 slots will remain at 4 and none of them get split into 256x256
>slots.
>
>A case that gives this result is 4 512x512 boxes and 70 250x250 boxes:
>
>128: 32, 256: 0, 512: 4, partial: 288
>max cacheable: 512x512
Here's a patch that should catch this type of case. Let us know if this
is enough to fix the crash.
David
-------------- next part --------------
Index: xaaPCache.c
===================================================================
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/xaa/xaaPCache.c,v
retrieving revision 1.30
diff -u -r1.30 xaaPCache.c
--- xaaPCache.c 25 Sep 2000 23:56:14 -0000 1.30
+++ xaaPCache.c 15 Aug 2003 02:18:24 -0000
@@ -763,6 +763,7 @@
1) Don't take up more than half the memory.
2) Don't bother if you can't get at least four.
3) Don't make more than MAX_512.
+ 4) Don't have any of there are no 256x256s.
256x256 -
1) Don't take up more than a quarter of the memory enless there
@@ -785,6 +786,13 @@
if(!Target512) Target256 = ntotal >> 3;
else Target256 = ntotal >> 4;
if(Target256 < 4) Target256 = 0;
+
+ if(Num512 && !Num256) {
+ while(Num512 && Num256 < Target256) {
+ SubdivideList(&List512, &List256);
+ Num256 += 4; Num512--;
+ }
+ }
if(!Num512) { /* no room */
} else if((Num512 < 4) || (!Target512)) {