Comment # 14
on bug 60929
from Torsten Kaiser
Created attachment 84467 [details] apitrace from hanging startup of OpenRA I'm seeing the same problem with the mono game OpenRA from http://open-ra.org/ on an RV730 PRO [Radeon HD 4650] with mesa-9.2-rc1 (but early mesa versions showed the same behaviour). With Gentoo I'm able to switch the R600_LLVM via useflag, but as soon as I'm using a mesa version with this enabled OpenRA will no longer start. It will just display a black window, the loading symbols never apear. Running apitrace gives (full apitrace as attachment): 10 glXChooseVisual(dpy = 0x15fbef0, [snip]) = &{visual = 0x1661f58, [snip]} 11 glXCreateContext(dpy = 0x15fbef0, vis = &{visual = 0x1661f58, [snip]) = 0x16734e0 12 glXMakeCurrent(dpy = 0x15fbef0, drawable = 20971535, ctx = 0x16734e0) = True 43 glXMakeCurrent(dpy = 0x15fbef0, drawable = 20971535, ctx = 0x16734e0) = True Trying gdb it seems one of the mono threads get stuck in radeon_drm_cs_emit_ioctl(), the other 7 threads look like mono internal things relating to its garbage collector. strace gives: socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 7 connect(7, {sa_family=AF_LOCAL, sun_path=@"/tmp/.X11-unix/X0"}, 20) = 0 [snip] open("/dev/dri/card0", O_RDWR|O_CLOEXEC) = 9 [snip] ioctl(9, 0xc010640b, 0x7fffeb471ea0) = 0 ioctl(9, 0xc00c6469, 0x7fffeb471ec0) = 0 ioctl(9, 0xc020645d, 0x7fffeb471d10) = 0 ioctl(9, 0xc020645d, 0x7fffeb471b10) = 0 ioctl(9, 0xc020645e, 0x7fffeb471b20) = 0 mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0x112992000) = 0x7f921dfe9000 ioctl(9, 0xc020645d, 0x7fffeb471b20) = 0 ioctl(9, 0xc020645e, 0x7fffeb471b30) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0x1129a2000) = 0x7f921dfe8000 ioctl(9, VIDIOC_INT_RESET, 0x24460b0) = 0 ioctl(9, 0xc020645d, 0x7fffeb471db0) = 0 Then some more interactions with fd=7 until it gets stuck with: futex(0x984280, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...> At that point only kill -9 helps. Do you have anything I should try or any info I should provide?
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
