| Summary: | Xorg busy loop in RADEONCPGetBuffer using UMS | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Raúl <rasasi78> | ||||
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||
| Severity: | normal | ||||||
| Priority: | medium | CC: | bugzilla1 | ||||
| Version: | unspecified | ||||||
| Hardware: | Other | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
This is s symptom of a GPU lockup. None of the fences ever come up so none of the command buffers can be freed and the driver keeps trying to get one. You might try kms. Hi: Thanks for the anwer. I did try KMS, unfortunately in may case, neither 2.6.32 nor 2.6.33 are usable. I guess I'll have to wait for 2.6.34 makes into Debian, whenever it is. Regards, I always end up forgetting to comment something, gah! I'd like to point out that I've been using 2.6.33 (UMS) and switched off KDE desktop effects. I find my system somewhat more stable know, but I'll cross my fingers. HTH, Hello: I haven't seen this problem on Linux 2.6.34 for a while, hence I'm closing. Thanks. Hi, For me this is most definitely not fixed in 2.6.34 (I'm _not_ using KMS yet). I can easily reproduce this on three different mainboards with (--) PCI:*(0:1:5:0) 1002:9710:1043:83a2 ATI Technologies Inc rev 0, Mem @ 0xd0000000/268435456, 0xfe8f0000/65536, 0xfe700000/1048576, I/O @ 0x0000c000/256 xorg-server_1.8.1-1 libdrm_2.4.20-2 xserver-xorg-video-ati_6.13.0-2 linux-2.6.34 and many earlier versions, in particular linux-2.6.31.x and linux-2.6.33.x. To reproduce, a single 2D-app suffices: % DISPLAY=:0 /usr/lib/xscreensaver/galaxy -root will cause the lock up after at most 2 minutes. Regards, Wolfram. Created attachment 36406 [details] [review] Proposed fix for buffer leak It looks like some sort of buffer leak, not like a GPU lockup. This patch fixes the problem for me in an hour of testing. (Maybe the patch is not optimal.) good catch. I've committed your patch: 801e83227a59a29eea425ea612083bbf2b536c30 |
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.
Hello: Debian sid graphics stack Xserver 1.7.6.901 (almost rc2) radeon driver 6.13.0 libdrm2 2.4.18 mesa 7.7.1 linux 2.6.32.9 (+ some patches) [0] Video card model: VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3600 Series I went away from keyboard, screensave bumped in, when I returned Xorg was unusable. I remotely opened an ssh session where I could get this backtrace: #0 0x00007f2809d0a4a7 in ioctl () from /lib/libc.so.6 #1 0x00007f28080b578d in drmDMA (fd=11, request=0x7fff08102f40) at ../xf86drm.c:1293 #2 0x00007f2807bc0f3b in RADEONCPGetBuffer (pScrn=0x10f7430) at ../../src/radeon_accel.c:696 #3 0x00007f2807c66bd8 in r600_cp_start (pScrn=0xb) at ../../src/r6xx_accel.c:1222 #4 0x00007f2807c63845 in R600PrepareSolid (pPix=<value optimized out>, alu=<value optimized out>, pm=<value optimized out>, fg=<value optimized out>) at ../../src/r600_exa.c:332 #5 0x00007f2807152635 in exaFillRegionSolid (pDrawable=0x3ec2b930, pRegion=0x166b4ad0, pixel=<value optimized out>, planemask=<value optimized out>, alu=3, clientClipType=0) at ../../exa/exa_accel.c:1020 #6 0x00007f280715321a in exaPolyFillRect (pDrawable=0x3ec2b930, pGC=0xa868c00, nrect=4096, prect=0x6044bb0) at ../../exa/exa_accel.c:811 #7 0x00007f280715098b in exaPolyPoint (pDrawable=0x3ec2b930, pGC=0xa868c00, mode=0, npt=4096, ppt=0x39855a8) at ../../exa/exa_accel.c:632 #8 0x00000000004dc387 in damagePolyPoint (pDrawable=0x3ec2b930, pGC=0xa868c00, mode=<value optimized out>, npt=4096, ppt=0x39815ac) at ../../../miext/damage/damage.c:1038 #9 0x0000000000446796 in ProcPolyPoint (client=0x2088b60) at ../../dix/dispatch.c:1806 #10 0x0000000000448d44 in Dispatch () at ../../dix/dispatch.c:439 #11 0x0000000000425c1a in main (argc=8, argv=0x7d8228, envp=<value optimized out>) at ../../dix/main.c:285 Then I sequentially break at function finish: Run till exit from #0 0x00007f2809d0a4a7 in ioctl () from /lib/libc.so.6 drmDMA (fd=11, request=0x7fff08102f40) at ../xf86drm.c:1294 1294 ../xf86drm.c: No existe el fichero o el directorio. in ../xf86drm.c Run till exit from #0 drmDMA (fd=11, request=0x7fff08102f40) at ../xf86drm.c:1294 RADEONCPGetBuffer (pScrn=0x10f7430) at ../../src/radeon_accel.c:697 697 ../../src/radeon_accel.c: No existe el fichero o el directorio. in ../../src/radeon_accel.c Value returned is $3 = -16 Run till exit from #0 RADEONCPGetBuffer (pScrn=0x10f7430) at ../../src/radeon_accel.c:697 (This took too long and I manually break) Program received signal SIGINT, Interrupt. 0x00007f2809d0a4a7 in ioctl () from /lib/libc.so.6 I guess this mean that RADEONCPGetBuffer goes into an infinite loop for some reason I don't understand. I'm afraid there's not a predictable way to reproduce this, I'll watch for this. As sidenote it may be worth to mention that I enabled the "EXANoDownloadFromScreen" option, ie disable hook, to mitigate a screen corruption issue (reported as well) Feel free to request more information. HTH, [0] http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_2.6.32-9/changelog