Bug 24218

Created attachment 29943 [details]
dmesg

dmesg.log

Created attachment 29944 [details]
lspci -nnxx

lspci -nnxx

Please try the latest bits from drm-next.  You don't appear to have the r6xx/r7xx vram/aperture size clipping patch.

Ok, I tried using zen-stable:
http://git.zen-sources.org/?p=zen-stable.git;a=summary which pulled drm-next 15
hours ago. But I still get the same screen. How old is this patch? More than 15
hours?

Does it work with a non-zen kernel?

(In reply to comment #5)
> Does it work with a non-zen kernel?
> 

Alex, can you give me a link to the commit? Maybe if it's not too big I can apply the patch to 2.6.32-rc1. Otherwise I have to wait for 2.6.32-rc2.

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=974b16e33ea626c9854f0f34fa5455a18822e159

I think it's still worth trying a non-zen kernel.

(In reply to comment #7)
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=974b16e33ea626c9854f0f34fa5455a18822e159
> 
> I think it's still worth trying a non-zen kernel.
> 

I applied this patch: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff_plain;h=974b16e33ea626c9854f0f34fa5455a18822e159 to vanilla 2.6.32-rc1 and it's still the same. Note that I'm currently using the vanilla kernel, I just tried the zen because it had a more recent drm-next pull.
Would it help if I took a picture of the screen? Although my phone's camera really sucks :)

It's probably not very useful, but I started X via gdb. It hanged there.
I opened another console via ssh and killed X, then I got this backtrace with gdb:

Program received signal SIGTERM, Terminated.
[Switching to Thread 0x7f5209bcc6f0 (LWP 1787)]
0x00007f5207112bd7 in ioctl () from /lib/libc.so.6
(gdb) bt
#0  0x00007f5207112bd7 in ioctl () from /lib/libc.so.6
#1  0x00007f520619cc83 in drmIoctl (fd=13, request=3221775460, arg=0x7fffc4fb7c60) at xf86drm.c:188
#2  0x00007f520619cf5c in drmCommandWriteRead (fd=13, drmCommandIndex=<value optimized out>, data=0x7fffc4fb7c60,
    size=<value optimized out>) at xf86drm.c:2431
#3  0x00007f5205a92259 in bo_wait (bo=0x2305d20) at radeon_bo_gem.c:214
#4  0x00007f5205a922ad in bo_map (bo=0x2305d20, write=-1073191836) at radeon_bo_gem.c:187
#5  0x00007f5205d514ee in r600_vb_get (pScrn=<value optimized out>) at /usr/include/drm/radeon_bo.h:151
#6  0x00007f5205d51544 in r600_cp_start (pScrn=0xd) at r6xx_accel.c:1227
#7  0x00007f5205d4f0ba in R600PrepareSolid (pPix=0x2326430, alu=<value optimized out>, pm=4294967295, fg=0)
    at r600_exa.c:183
#8  0x00007f520566264d in exaFillRegionSolid (pDrawable=0x2329b50, pRegion=0x23d4f50, pixel=<value optimized out>,
    planemask=<value optimized out>, alu=3, clientClipType=0) at exa_accel.c:1003
#9  0x00007f520566321a in exaPolyFillRect (pDrawable=0x2329b50, pGC=0x2328c00, nrect=1, prect=0x23d4f30) at exa_accel.c:800
#10 0x00000000004bbb1b in damagePolyFillRect (pDrawable=0x2329b50, pGC=0x2328c00, nRects=1, pRects=0x23d4f30)
    at damage.c:1404
#11 0x0000000000457ed4 in miPaintWindow (pWin=<value optimized out>, prgn=0x7fffc4fb8160, what=<value optimized out>)
    at miexpose.c:670
#12 0x0000000000458274 in miWindowExposures (pWin=0x2329b50, prgn=0x7fffc4fb8160, other_exposed=0x0) at miexpose.c:504
#13 0x000000000050bf83 in xf86XVWindowExposures (pWin=0x2329b50, reg1=0x7fffc4fb8160, reg2=<value optimized out>)
    at xf86xv.c:1054
#14 0x0000000000445bc1 in MapWindow (pWin=0x2329b50, client=<value optimized out>) at window.c:2678
#15 0x0000000000424f17 in main (argc=1, argv=<value optimized out>, envp=<value optimized out>) at main.c:254


I'm now running 2.6.32-rc3, same behavior.
Also, might be related to this other bug I'm having without KMS: http://bugs.freedesktop.org/show_bug.cgi?id=24300
Basically I get a lot of these errors:
[drm:radeon_cp_indirect] *ERROR* sending pending buffer 25

Created attachment 30113 [details]
dmesg with drm debug=1

I booted with drm debug=1
It seems X is stuck in an infinite loop?
I really hope this helps.

changed title more appropriately.

Created attachment 30114 [details]
backtrace

I got this backtrace on Mobility Radeon 2400 (m72/rv610) so looks like the issue is not rs780-specific. Starting glxgears on bare Xserver and waiting several seconds leads to either X hang or whole system freeze(no pings, no sysrq, nothing). I'm using xorg-server-1.7.0 (same behavior on 1.6.{3,4}), drm-next kernel, and mesa, libdrm, xf86-video-ati from git master.

at least your X starts, mine doesn't really... My card is also rv610 (or rv620) based iirc. I suppose without kms it works fine for you too?

Yes, works fine without KMS.

Modifying libdrm code not to retry ioctl more than 100 times, and a few seconds with kwin effects+glxgears gave thousands lines like this in dmesg:

[drm:radeon_ib_get] *ERROR* radeon: IB(9:0x0000000008191000:6090)
[drm:radeon_ib_get] *ERROR* radeon: GPU lockup detected, fail to get a IB
[drm:radeon_cs_ioctl] *ERROR* Failed to get ib !

still valid with 2.6.32-rc4 + additional drm-next patches up until 39deb2d67515086f08a672e7574716ca0d3883a5

Seems to be fixed with current zen kernel master.

Then it's not the same bug after all. I still have this problem with zen-kernel master and also with vanilla 2.6.32-rc5 + drm-next patches up to c182be37ed7cb04c344501b88b8fdb747016e6cf

I suspect this is a dupe of bug 24535.  RS880 is based on RV620.

does the patch on bug 24535#c25 help?

(In reply to comment #20)
> does the patch on bug 24535#c25 help?
> 

Unfortunately no, still the same bug.

Created attachment 30983 [details] [review]
fix rs880

I sent this patch to dri-devel last night.  It should fix the rs880 issues.

yep, it's fixed :)