Every time I try to open a specific JPEG image in Firefox 24 on my Gentoo machine, my X server crashes and I have to start over from login. I got the following error message in Xorg.0.log.old: Fatal server error: [ 5116.361] (EE) (EE) BUG: triggered 'if (f[f_idx])' [ 5116.361] (EE) BUG: /var/tmp/portage/x11-base/xorg-server-1.14.3-r2/work/xorg-server-1.14.3/os/log.c:464 in pnprintf() [ 5116.361] (EE) Unsupported printf directive '#' [ 5116.361] (EE) [ 5116.362] (EE) Backtrace: [ 5116.362] (EE) 0: /usr/bin/X (xorg_backtrace+0x36) [0x58adc6] [ 5116.362] (EE) 1: /usr/bin/X (LogVMessageVerbSigSafe+0x818) [0x596558] [ 5116.362] (EE) 2: /usr/bin/X (FatalError+0xcb) [0x59677b] [ 5116.362] (EE) 3: /usr/lib64/libglamor.so.0 (0x7fd1cc56d000+0x26d57) [0x7fd1cc593d57] [ 5116.362] (EE) 4: /usr/lib64/libglamor.so.0 (0x7fd1cc56d000+0x26eb0) [0x7fd1cc593eb0] [ 5116.362] (EE) 5: /usr/lib64/libglamor.so.0 (glamor_create_pixmap+0x2d7) [0x7fd1cc5717f7] [ 5116.362] (EE) 6: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7fd1cba12000+0x4d5d4) [0x7fd1cba5f5d4] [ 5116.362] (EE) 7: /usr/bin/X (0x400000+0x36c6f) [0x436c6f] [ 5116.362] (EE) 8: /usr/bin/X (0x400000+0x3b3d6) [0x43b3d6] [ 5116.362] (EE) 9: /usr/bin/X (0x400000+0x29dca) [0x429dca] [ 5116.362] (EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x32ccc246c5] [ 5116.362] (EE) 11: /usr/bin/X (0x400000+0x2a111) [0x42a111] [ 5116.362] (EE) [ 5116.362] destination is framebuffer incomplete: unsupported [%#x] I saw the printf problem is described bug #69573 and is already fixed in git, so I applied the fixed the statement with a patch locally and tried again. Here's the error message from Xorg.0.log.old with fixed printf directive: [ 6840.056] (EE) destination is framebuffer incomplete: unsupported [8cdd] Hardware: - AMD/ATI Radeon HD 7770 GHz Edition (Cape Verde XT) Software: - xorg-server 1.14.3 - mesa 9.2.1 - xf86-video-ati 7.2.0 - glamor 0.5.1 - libdrm 2.4.47
I'm using Firefox on KDE/KWin 4.11.2 and kernel 3.6.11.
Could you try the git version glamor? And if it still has this bug, could you use gdb to get a complete back trace information? Thanks.
I updated to mesa 9.2.2 and tried the git version of glamor, but the problem remains. Here's some output from the gdb session with back trace information: (gdb) break glamor_fbo.c:215 Breakpoint 1 at 0x7f1f909d408f: file /var/tmp/portage/x11-libs/glamor-9999/work/glamor-9999/src/glamor_fbo.c, line 215. (gdb) c Continuing. Breakpoint 1, glamor_pixmap_ensure_fb (fbo=fbo@entry=0x30305b0) at /var/tmp/portage/x11-libs/glamor-9999/work/glamor-9999/src/glamor_fbo.c:215 215 /var/tmp/portage/x11-libs/glamor-9999/work/glamor-9999/src/glamor_fbo.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt full #0 glamor_pixmap_ensure_fb (fbo=fbo@entry=0x30305b0) at /var/tmp/portage/x11-libs/glamor-9999/work/glamor-9999/src/glamor_fbo.c:215 str = 0x7f1f909ddac8 "unsupported" status = 36061 #1 0x00007f1f909d420d in glamor_create_fbo_from_tex (glamor_priv=glamor_priv@entry=0x1d79fa0, w=w@entry=6864, h=h@entry=9779, format=format@entry=6408, tex=7857, flag=flag@entry=0) at /var/tmp/portage/x11-libs/glamor-9999/work/glamor-9999/src/glamor_fbo.c:248 fbo = 0x30305b0 #2 0x00007f1f909d48b7 in glamor_create_fbo (glamor_priv=glamor_priv@entry=0x1d79fa0, w=w@entry=6864, h=h@entry=9779, format=format@entry=6408, flag=flag@entry=0) at /var/tmp/portage/x11-libs/glamor-9999/work/glamor-9999/src/glamor_fbo.c:377 fbo = <optimized out> tex = <optimized out> cache_flag = <optimized out> #3 0x00007f1f909b3a80 in glamor_create_pixmap (screen=screen@entry=0x1cc9060, w=w@entry=6864, h=h@entry=9779, depth=depth@entry=24, usage=usage@entry=0) at /var/tmp/portage/x11-libs/glamor-9999/work/glamor-9999/src/glamor.c:175 pixmap = 0x348aab0 type = GLAMOR_TEXTURE_ONLY pixmap_priv = 0x3496f80 glamor_priv = 0x1d79fa0 fbo = <optimized out> pitch = <optimized out> format = 6408 #4 0x00007f1f8fea26e7 in radeon_glamor_create_pixmap (screen=0x1cc9060, w=6864, h=9779, depth=24, usage=0) at /var/tmp/portage/x11-drivers/xf86-video-ati-7.2.0/work/xf86-video-ati-7.2.0/src/radeon_glamor.c:177 scrn = 0x1c0b0b0 priv = <optimized out> pixmap = <optimized out> new_pixmap = 0x0 #5 0x000000000043440b in ProcCreatePixmap (client=0x27d38a0) at /var/tmp/portage/x11-base/xorg-server-1.14.3-r2/work/xorg-server-1.14.3/dix/dispatch.c:1391 pMap = <optimized out> pDraw = 0x235a210 stuff = 0x349bf30 pDepth = <optimized out> i = <optimized out> rc = <optimized out> #6 0x00000000004389db in Dispatch () at /var/tmp/portage/x11-base/xorg-server-1.14.3-r2/work/xorg-server-1.14.3/dix/dispatch.c:432 clientReady = 0x250ca70 result = 0 client = 0x27d38a0 nready = 0 icheck = 0x80d170 <checkForInput> start_tick = 1180 #7 0x0000000000428334 in main (argc=10, argv=0x7fffceca54e8, envp=<optimized out>) at /var/tmp/portage/x11-base/xorg-server-1.14.3-r2/work/xorg-server-1.14.3/dix/main.c:298 i = <optimized out> alwaysCheckForInput = {0, 1}
(In reply to comment #3) > I updated to mesa 9.2.2 and tried the git version of glamor, but the problem > remains. > > Here's some output from the gdb session with back trace information: > > (gdb) break glamor_fbo.c:215 > Breakpoint 1 at 0x7f1f909d408f: file > /var/tmp/portage/x11-libs/glamor-9999/work/glamor-9999/src/glamor_fbo.c, > line 215. > (gdb) c > Continuing. > > Breakpoint 1, glamor_pixmap_ensure_fb (fbo=fbo@entry=0x30305b0) > at > /var/tmp/portage/x11-libs/glamor-9999/work/glamor-9999/src/glamor_fbo.c:215 > 215 > /var/tmp/portage/x11-libs/glamor-9999/work/glamor-9999/src/glamor_fbo.c: > Datei oder Verzeichnis nicht gefunden. > (gdb) bt full > #0 glamor_pixmap_ensure_fb (fbo=fbo@entry=0x30305b0) at > /var/tmp/portage/x11-libs/glamor-9999/work/glamor-9999/src/glamor_fbo.c:215 > str = 0x7f1f909ddac8 "unsupported" > status = 36061 > #1 0x00007f1f909d420d in glamor_create_fbo_from_tex > (glamor_priv=glamor_priv@entry=0x1d79fa0, w=w@entry=6864, h=h@entry=9779, > format=format@entry=6408, tex=7857, flag=flag@entry=0) at > /var/tmp/portage/x11-libs/glamor-9999/work/glamor-9999/src/glamor_fbo.c:248 > fbo = 0x30305b0 > #2 0x00007f1f909d48b7 in glamor_create_fbo > (glamor_priv=glamor_priv@entry=0x1d79fa0, w=w@entry=6864, h=h@entry=9779, > format=format@entry=6408, flag=flag@entry=0) at > /var/tmp/portage/x11-libs/glamor-9999/work/glamor-9999/src/glamor_fbo.c:377 > fbo = <optimized out> > tex = <optimized out> > cache_flag = <optimized out> > #3 0x00007f1f909b3a80 in glamor_create_pixmap > (screen=screen@entry=0x1cc9060, w=w@entry=6864, h=h@entry=9779, > depth=depth@entry=24, > usage=usage@entry=0) at > /var/tmp/portage/x11-libs/glamor-9999/work/glamor-9999/src/glamor.c:175 > pixmap = 0x348aab0 > type = GLAMOR_TEXTURE_ONLY > pixmap_priv = 0x3496f80 > glamor_priv = 0x1d79fa0 > fbo = <optimized out> > pitch = <optimized out> > format = 6408 > #4 0x00007f1f8fea26e7 in radeon_glamor_create_pixmap (screen=0x1cc9060, > w=6864, h=9779, depth=24, usage=0) > at > /var/tmp/portage/x11-drivers/xf86-video-ati-7.2.0/work/xf86-video-ati-7.2.0/ > src/radeon_glamor.c:177 > scrn = 0x1c0b0b0 > priv = <optimized out> > pixmap = <optimized out> > new_pixmap = 0x0 > #5 0x000000000043440b in ProcCreatePixmap (client=0x27d38a0) > at > /var/tmp/portage/x11-base/xorg-server-1.14.3-r2/work/xorg-server-1.14.3/dix/ > dispatch.c:1391 > pMap = <optimized out> > pDraw = 0x235a210 > stuff = 0x349bf30 > pDepth = <optimized out> > i = <optimized out> > rc = <optimized out> > #6 0x00000000004389db in Dispatch () at > /var/tmp/portage/x11-base/xorg-server-1.14.3-r2/work/xorg-server-1.14.3/dix/ > dispatch.c:432 > clientReady = 0x250ca70 > result = 0 > client = 0x27d38a0 > nready = 0 > icheck = 0x80d170 <checkForInput> > start_tick = 1180 > #7 0x0000000000428334 in main (argc=10, argv=0x7fffceca54e8, > envp=<optimized out>) > at > /var/tmp/portage/x11-base/xorg-server-1.14.3-r2/work/xorg-server-1.14.3/dix/ > main.c:298 > i = <optimized out> > alwaysCheckForInput = {0, 1} Thanks for the information. Based on the above bt info, I think this may not be a glamor bug, but a driver layer bug. Glamor try to allocate a fbo with 6864x9779 texture and finally failed to get a valid fbo. I remember that mesa only support up to 8kx8k texture. And glamor will not try to create pixmap larger than that. It seems that the driver report it can support larger pixmap, but fail to create such a fbo. CC to Michel, what do you think?
(In reply to comment #4) > Glamor try to allocate a fbo with 6864x9779 texture and finally failed to get > a valid fbo. I remember that mesa only support up to 8kx8k texture. Actually, the current limit is 16K AFAICT. > And glamor will not try to create pixmap larger than that. It seems that the > driver report it can support larger pixmap, but fail to create such a fbo. I suspect the FBO allocation fails because there is not enough VRAM to fit the large pixmap. I'm not sure there's any guarantee in OpenGL that one can actually use a texture of maximum size in all dimensions? (Especially considering 3D textures) If there isn't, I'm afraid glamor needs to deal with this and try smaller sizes.
Just adding that I'm seeing the same bug here. From Xorg log: "destination is framebuffer incomplete: unsupported [8cdd]" video card: [AMD/ATI] Tahiti XT [Radeon HD 7970/R9 280X] Software: - xorg-server 1.14.3 - mesa 9.2.1 - xf86-video-ati 7.2.0 - glamor 0.5.1 - libdrm 2.4.0 (?) I'm running into the same issue trying to view large images (wallpapers for my triple head setup). Repeated crashes back to the login prompt. The most recent one was 17574x11413 Another one is 20052x4115 So I think the 16k limit sounds about right. The rest seem to load fine. I just loaded a 14928x3528 one without any problem.
Actually I just had it happen again with a 10000x7514 image. This is INCREDIBLY FRUSTRATING. It blows away my entire desktop session. It's to the point where I'm scared to view ANY image because it might crash my whole desktop.
I'm seeing this bug as well (stack detailed below) and as I haven't seen a testcase posted, I can reliably trigger this bug with http://imgur.com/a/CmkkS/ (with JavaScript enabled/not going to the way smaller noscript Version). In Xorg.0.log I'm just seeing: > [ 16877.997] (EE) > Fatal server error: > [ 16877.997] (EE) destination is framebuffer incomplete: unsupported [8cdd] > [ 16877.997] (EE) > [ 16877.997] (EE) > Please consult the The X.Org Foundation support > [...] > [ 16878.008] (EE) Server terminated with error (1). Closing log file. dmesg shows: > [16840.431020] radeon_gem_object_create:69 alloc size 354Mb bigger than 256Mb limit > [16840.463561] radeon_gem_object_create:69 alloc size 354Mb bigger than 256Mb limit > [16840.463598] radeon_gem_object_create:69 alloc size 354Mb bigger than 256Mb limit > [16885.770507] radeon_gem_object_create:69 alloc size 354Mb bigger than 256Mb limit > [16885.792190] radeon_gem_object_create:69 alloc size 354Mb bigger than 256Mb limit > [16885.792215] radeon_gem_object_create:69 alloc size 354Mb bigger than 256Mb limit Stack: GPU: "PITCAIRN" (ChipID = 0x6819) Linux: 3.12.1 libdrm: 2.4.49 LLVM: SVN:trunk/r195435 libclc: Git:master/9844fd6a18 Mesa: Git:master/aad2511c6d GLAMOR: Git:master/b418b13126 DDX: Git:master/d571d6af70 Let me know if you need further information.
(In reply to comment #8) > I'm seeing this bug as well (stack detailed below) and as I haven't seen a > testcase posted, I can reliably trigger this bug with > http://imgur.com/a/CmkkS/ (with JavaScript enabled/not going to the way > smaller noscript Version). > > In Xorg.0.log I'm just seeing: > > [ 16877.997] (EE) > > Fatal server error: > > [ 16877.997] (EE) destination is framebuffer incomplete: unsupported [8cdd] > > [ 16877.997] (EE) > > [ 16877.997] (EE) > > Please consult the The X.Org Foundation support > > [...] > > [ 16878.008] (EE) Server terminated with error (1). Closing log file. > > dmesg shows: > > [16840.431020] radeon_gem_object_create:69 alloc size 354Mb bigger than 256Mb limit > > [16840.463561] radeon_gem_object_create:69 alloc size 354Mb bigger than 256Mb limit > > [16840.463598] radeon_gem_object_create:69 alloc size 354Mb bigger than 256Mb limit > > [16885.770507] radeon_gem_object_create:69 alloc size 354Mb bigger than 256Mb limit > > [16885.792190] radeon_gem_object_create:69 alloc size 354Mb bigger than 256Mb limit > > [16885.792215] radeon_gem_object_create:69 alloc size 354Mb bigger than 256Mb limit This is a hint that radeon driver can't allocate bigger than 256Mb texture. According to Michel's comment, now mesa could support upto 16K*16K texture. That's may be the root cause, as glamor may think the driver support texture size larger than 8K*8K (64*4Mb = 256Mb) which is not true for radeon. So it trigger this bug. I think radeon need to fix this inconsistence configuration. If the driver report max texture size as 16K then, it should support to allocate upto 1Gb texture. Otherwise, it should report max texture size as 8K, then glamor will use tile texture to represent larger pixmap. > > Stack: > GPU: "PITCAIRN" (ChipID = 0x6819) > Linux: 3.12.1 > libdrm: 2.4.49 > LLVM: SVN:trunk/r195435 > libclc: Git:master/9844fd6a18 > Mesa: Git:master/aad2511c6d > GLAMOR: Git:master/b418b13126 > DDX: Git:master/d571d6af70 > > Let me know if you need further information.
(In reply to comment #9) > This is a hint that radeon driver can't allocate bigger than 256Mb texture. FWIW, the limit depends on the amount of VRAM and the size of the GTT aperture. > I think radeon need to fix this inconsistence configuration. If the driver > report max texture size as 16K then, it should support to allocate upto 1Gb > texture. Otherwise, it should report max texture size as 8K, then glamor > will use tile texture to represent larger pixmap. If you consider things like texture formats with 32 bit components, 3D textures etc., the driver would have to advertise very conservative limits to guarantee the limits can be exhausted in all dimensions at the same time. But there is nothing whatsoever preventing e.g. a 16384x32x32 3D texture from working. That's what the maximum sizes advertised by OpenGL are for. P.S. Even if you don't agree, glamor needs to handle problems like this more gracefully than just bailing with FatalError, e.g. by dropping X11 draw operations on the floor. See bug 72093 for another example.
I get the same BUG: triggered 'if (f[f_idx])' using xdmcp to throw a desktop from my Raspberry Pi (running Raspian) at my Win7 64 bit Lenovo X201 laptop running a fresh Cygwin/X install. Device Manager simply reports the display adapter as Intel(R) HD Graphics. Nothing very challenging there I wouldn't think. Works fine on my older Lenovo T410 with an older Cygwin/X install. Here's my XWin.0.log: Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.14.4.0 OS: CYGWIN_NT-6.1 X201-PC 1.7.25(0.270/5/3) 2013-08-31 20:37 x86_64 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601](Win64) Package: version 1.14.4-1 built 2013-11-11 XWin was started with the following command line: /usr/bin/XWin -query 192.168.1.20 -nodecoration -lesspointer ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1280 h 800 winInitializeScreenDefaults - native DPI x 96 y 96 [ 641.694] Initializing built-in extension Generic Event Extension [ 641.694] Initializing built-in extension SHAPE [ 641.694] Initializing built-in extension MIT-SHM [ 641.694] Initializing built-in extension XInputExtension [ 641.694] Initializing built-in extension XTEST [ 641.694] Initializing built-in extension BIG-REQUESTS [ 641.694] Initializing built-in extension SYNC [ 641.694] Initializing built-in extension XKEYBOARD [ 641.694] Initializing built-in extension XC-MISC [ 641.694] Initializing built-in extension XINERAMA [ 641.694] Initializing built-in extension XFIXES [ 641.694] Initializing built-in extension XFree86-Bigfont [ 641.694] Initializing built-in extension RENDER [ 641.694] Initializing built-in extension RANDR [ 641.694] Initializing built-in extension COMPOSITE [ 641.694] Initializing built-in extension DAMAGE [ 641.694] Initializing built-in extension MIT-SCREEN-SAVER [ 641.694] Initializing built-in extension DOUBLE-BUFFER [ 641.694] Initializing built-in extension RECORD [ 641.694] Initializing built-in extension DPMS [ 641.694] Initializing built-in extension X-Resource [ 641.694] Initializing built-in extension GLX [ 641.694] (II) xorg.conf is not supported [ 641.694] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [ 641.694] LoadPreferences: /home/X201/.XWinrc not found [ 641.694] LoadPreferences: Loading /etc/X11/system.XWinrc [ 641.694] LoadPreferences: Done parsing the configuration file... [ 641.710] winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD [ 641.710] winDetectSupportedEngines - Windows NT, allowing PrimaryDD [ 641.710] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL [ 641.710] winDetectSupportedEngines - Returning, supported engines 0000001f [ 641.710] winSetEngine - Using Shadow DirectDraw NonLocking [ 641.710] winScreenInit - Using Windows display depth of 32 bits per pixel [ 641.725] winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff [ 641.741] MIT-SHM extension disabled due to lack of kernel support [ 641.741] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [ 641.756] (EE) AIGLX: No native OpenGL in modes with a root window [ 641.756] (II) AIGLX: enabled GLX_EXT_texture_from_pixmap [ 641.756] (II) AIGLX: Loaded and initialized swrast [ 641.756] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 641.897] winPointerWarpCursor - Discarding first warp: 640 385 [ 641.897] (--) 5 mouse buttons found [ 641.897] (--) Setting autorepeat to delay=500, rate=31 [ 641.897] (--) Windows keyboard layout: "00000809" (00000809) "United Kingdom", type 7 [ 641.897] (--) Found matching XKB configuration "English (United Kingdom)" [ 641.897] (--) Model = "pc105" Layout = "gb" Variant = "none" Options = "none" [ 641.897] Rules = "base" Model = "pc105" Layout = "gb" Variant = "none" Options = "none" [ 641.959] winBlockHandler - pthread_mutex_unlock() [ 642.006] (EE) Fatal server error: [ 642.006] (EE) (EE) BUG: triggered 'if (f[f_idx])' [ 642.006] (EE) BUG: /wip/cygport-git/xorg-server/xorg-server-1.14.4-1/src/xserver-cygwin-1.14.4-1/os/log.c:467 in pnprintf() [ 642.006] (EE) Unsupported printf directive '*' [ 643.207] (EE) Install xorg-server-debuginfo to get symbol table info for backtraces Attempting backtrace on pid 4112 [ 645.095] (EE) ==================== GDB Backtrace ============ GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special) This GDB was configured as "x86_64-pc-cygwin". ==================== Backtrace ================ Thread 6 (Thread 4112.0x109c): #0 0x0000000076d20591 in (EE) ntdll!DbgBreakPoint () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll No symbol table info available. #1 0x0000000076dc7f48 in ntdll!DbgUiRemoteBreakin () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll No symbol table info available. #2 0x00000000000000(EE) 00 in ?? () No symbol table info available. Thread 5 (Thread 4112.0x13e4): #0 0x0000000076d2131a in ntdll!ZwReadFile () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll No symbol table info available. #1 0x000007fefcb51a7a in ReadFile () from /cygdriv(EE) e/c/Windows/system32/KERNELBASE.dll No symbol table info available. #2 0x0000000000000008 in ?? () No symbol table info available. #3 0x0000000002991470 in ?? () No symbol table info available. #4 0x000000000034f8e0 in ?? () No symbol table info availa(EE) ble. #5 0x000007fefc33d8b0 in ?? () from /cygdrive/c/Windows/System32/mswsock.dll No symbol table info available. #6 0x0000000004abaa10 in ?? () No symbol table info available. #7 0x0000000004abaabb in ?? () No symbol table info available. #8 0x000000(EE) 0000000001 in ?? () No symbol table info available. #9 0x0000000000000000 in ?? () No symbol table info available. Thread 4 (Thread 4112.0x72c): #0 0x0000000076be9e6a in USER32!SfmDxSetSwapChainStats () from /cygdrive/c/Windows/system32/USER32.dll N(EE) o symbol table info available. #1 0x0000000076be615e in USER32!GetMessageA () from /cygdrive/c/Windows/system32/USER32.dll No symbol table info available. #2 0x0000000000000000 in ?? () No symbol table info available. Thread 3 (Thread 4112.0x1460): [ 645.095] (EE) #0 0x0000000076d2186a in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll No symbol table info available. #1 0x0000000076ceb037 in ntdll!TpIsTimerSet () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll No symbol table info (EE) available. #2 0x0000000000000000 in ?? () No symbol table info available. Thread 2 (Thread 4112.0x14b0): #0 0x0000000076d2131a in ntdll!ZwReadFile () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll No symbol table info available. #1 0x000007fefcb51a7a (EE) in ReadFile () from /cygdrive/c/Windows/system32/KERNELBASE.dll No symbol table info available. #2 0x000000000022ce00 in ?? () No symbol table info available. #3 0x000007fefcb5133c in SetEvent () from /cygdrive/c/Windows/system32/KERNELBASE.dll No(EE) symbol table info available. #4 0x00000001801e1c40 in sigq () from /usr/bin/cygwin1.dll No symbol table info available. #5 0x0000000000000005 in ?? () No symbol table info available. #6 0x0000000001f3aa30 in ?? () No symbol table info available. #7 0(EE) x0000000001f3aae0 in ?? () No symbol table info available. #8 0x00000000000000b0 in ?? () No symbol table info available. #9 0x0000000000000000 in ?? () No symbol table info available. Thread 1 (Thread 4112.0x1084): #0 0x0000000076d2186a in ntdll!ZwWa(EE) itForMultipleObjects () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll No symbol table info available. #1 0x000007fefcb51430 in KERNELBASE!GetCurrentProcess () from /cygdrive/c/Windows/system32/KERNELBASE.dll No symbol table info available. #2 0x0000(EE) 000000229e00 in ?? () No symbol table info available. #3 0x0000000000000000 in ?? () No symbol table info available. ==================== Backtrace End ============ [ 645.095] XDMCP fatal error: Session failed %*.*s [ 645.095] (EE) Server terminated with error (1). Closing log file.
(In reply to comment #10) > (In reply to comment #9) > > This is a hint that radeon driver can't allocate bigger than 256Mb texture. > > FWIW, the limit depends on the amount of VRAM and the size of the GTT > aperture. > > > > I think radeon need to fix this inconsistence configuration. If the driver > > report max texture size as 16K then, it should support to allocate upto 1Gb > > texture. Otherwise, it should report max texture size as 8K, then glamor > > will use tile texture to represent larger pixmap. > > If you consider things like texture formats with 32 bit components, 3D > textures etc., the driver would have to advertise very conservative limits > to guarantee the limits can be exhausted in all dimensions at the same time. > But there is nothing whatsoever preventing e.g. a 16384x32x32 3D texture > from working. That's what the maximum sizes advertised by OpenGL are for. > > > P.S. Even if you don't agree, glamor needs to handle problems like this more > gracefully than just bailing with FatalError, e.g. by dropping X11 draw > operations on the floor. See bug 72093 for another example. One thing you are definitely right, glamor should not break the xserver for this type of error. Maybe just simply fallback to software rendering path. I will fix that when I have some time. Thanks.
(In reply to comment #11) > I get the same BUG: triggered 'if (f[f_idx])' [...] That symptom may be similar, but it's definitely not the same bug. Please file your own report.
Maybe a better example than 3D textures is texture arrays: How well does e.g. a texture array of 512 layers of 8192x8192 work with the i965 driver? :)
This bug persists with a current stack: GPU: "PITCAIRN" (ChipID = 0x6819) Linux: 3.13.0 libdrm: 2.4.52 LLVM: SVN:trunk/r200074 libclc: Git:master/d9a654573a Mesa: Git:master/10dc994e09 GLAMOR: Git:master/f4bb57f025 DDX: Git:master/8de6f7b2f4 dmesg (though now on line 62) and Xorg.0.log show the same output with the image from comment 8. Could there be at least some guard against the crash as Michel suggested? It's really getting scary out there on the internet, when each click can mean you've lost all unsaved work. If you need anything else, please let me know.
Created attachment 93740 [details] [review] patch
(In reply to comment #15) > This bug persists with a current stack: > GPU: "PITCAIRN" (ChipID = 0x6819) > Linux: 3.13.0 > libdrm: 2.4.52 > LLVM: SVN:trunk/r200074 > libclc: Git:master/d9a654573a > Mesa: Git:master/10dc994e09 > GLAMOR: Git:master/f4bb57f025 > DDX: Git:master/8de6f7b2f4 > > dmesg (though now on line 62) and Xorg.0.log show the same output with the > image from comment 8. Could there be at least some guard against the crash > as Michel suggested? It's really getting scary out there on the internet, > when each click can mean you've lost all unsaved work. > > If you need anything else, please let me know. Could you try the patch I just submitted above? Thanks. It is not tested as I don't have a environment in hand.
(In reply to comment #16) > Created attachment 93740 [details] [review] [review] > patch The warning log message might be noisy, but other than that, the patch looks good to me, thanks. BTW, I previously forgot about proxy textures, which is the OpenGL mechanism for probing whether a texture of certain dimensions can actually be used.
(In reply to comment #17) > Could you try the patch I just submitted above? Thanks. It is not tested as > I don't have a environment in hand. Thanks for the patch. I just did a quick test of it with the latest glamor code from git: When I tried to display the image in Firefox that I mentioned in the bug description xserver crashes with the following message in Xorg.0.log: [ 372.490] (WW) glamor: Failed to create fbo, unsupported [ 372.498] (WW) glamor: Failed to create fbo, unsupported [ 372.499] (EE) [ 372.499] (EE) Backtrace: [ 372.499] (EE) 0: /usr/bin/X (OsLookupColor+0x139) [0x5d3909] [ 372.500] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x3b35a10b0f] [ 372.500] (EE) 2: /usr/lib64/libglamor.so.0 (glamor_poly_segment_nf+0x74d) [0x7f77652eb09d] [ 372.501] (EE) 3: /usr/lib64/libglamor.so.0 (glamor_poly_segment_nf+0x1044) [0x7f77652ebe04] [ 372.502] (EE) 4: /usr/lib64/libglamor.so.0 (glamor_poly_segment_nf+0x1f35) [0x7f77652ed805] [ 372.503] (EE) 5: /usr/lib64/libglamor.so.0 (glamor_poly_lines_nf+0x69f) [0x7f77652d827f] [ 372.503] (EE) 6: /usr/lib64/libglamor.so.0 (glamor_poly_lines_nf+0x742) [0x7f77652d8a22] [ 372.504] (EE) 7: /usr/bin/X (DamageRegionAppend+0x973) [0x53f1a3] [ 372.504] (EE) 8: /usr/bin/X (dixDestroyPixmap+0x1441) [0x43b3e1] [ 372.504] (EE) 9: /usr/bin/X (SendErrorToClient+0x38e) [0x43d77e] [ 372.504] (EE) 10: /usr/bin/X (remove_fs_handlers+0x42a) [0x441c7a] [ 372.505] (EE) 11: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x3b34e24bf5] [ 372.505] (EE) 12: /usr/bin/X (_start+0x29) [0x42a891] [ 372.506] (EE) 13: ? (?+0x29) [0x29] [ 372.506] (EE) [ 372.506] (EE) Segmentation fault at address 0x0 [ 372.506] (EE) Fatal server error: [ 372.506] (EE) Caught signal 11 (Segmentation fault). Server aborting There are messages in syslog, too: Feb 10 10:10:23 - kernel: [ 372.534759] radeon_gem_object_create:62 alloc size 258Mb bigger than 256Mb limit Feb 10 10:10:23 - kernel: [ 372.535188] radeon_gem_object_create:62 alloc size 258Mb bigger than 256Mb limit Feb 10 10:10:23 - kernel: [ 372.535259] radeon_gem_object_create:62 alloc size 258Mb bigger than 256Mb limit Feb 10 10:10:23 - kernel: [ 372.535706] radeon_gem_object_create:62 alloc size 258Mb bigger than 256Mb limit Feb 10 10:10:23 - kernel: [ 372.543252] radeon_gem_object_create:62 alloc size 258Mb bigger than 256Mb limit Feb 10 10:10:23 - kernel: [ 372.543316] radeon_gem_object_create:62 alloc size 258Mb bigger than 256Mb limit
Created attachment 93747 [details] [review] patch v2
(In reply to comment #19) > (In reply to comment #17) > > Could you try the patch I just submitted above? Thanks. It is not tested as > > I don't have a environment in hand. > > Thanks for the patch. I just did a quick test of it with the latest glamor > code from git: When I tried to display the image in Firefox that I mentioned > in the bug description xserver crashes with the following message in > Xorg.0.log: > > [ 372.490] (WW) glamor: Failed to create fbo, unsupported > [ 372.498] (WW) glamor: Failed to create fbo, unsupported > [ 372.499] (EE) > [ 372.499] (EE) Backtrace: > [ 372.499] (EE) 0: /usr/bin/X (OsLookupColor+0x139) [0x5d3909] > [ 372.500] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x3b35a10b0f] > [ 372.500] (EE) 2: /usr/lib64/libglamor.so.0 > (glamor_poly_segment_nf+0x74d) [0x7f77652eb09d] > [ 372.501] (EE) 3: /usr/lib64/libglamor.so.0 > (glamor_poly_segment_nf+0x1044) [0x7f77652ebe04] > [ 372.502] (EE) 4: /usr/lib64/libglamor.so.0 > (glamor_poly_segment_nf+0x1f35) [0x7f77652ed805] > [ 372.503] (EE) 5: /usr/lib64/libglamor.so.0 (glamor_poly_lines_nf+0x69f) > [0x7f77652d827f] > [ 372.503] (EE) 6: /usr/lib64/libglamor.so.0 (glamor_poly_lines_nf+0x742) > [0x7f77652d8a22] > [ 372.504] (EE) 7: /usr/bin/X (DamageRegionAppend+0x973) [0x53f1a3] > [ 372.504] (EE) 8: /usr/bin/X (dixDestroyPixmap+0x1441) [0x43b3e1] > [ 372.504] (EE) 9: /usr/bin/X (SendErrorToClient+0x38e) [0x43d77e] > [ 372.504] (EE) 10: /usr/bin/X (remove_fs_handlers+0x42a) [0x441c7a] > [ 372.505] (EE) 11: /lib64/libc.so.6 (__libc_start_main+0xf5) > [0x3b34e24bf5] > [ 372.505] (EE) 12: /usr/bin/X (_start+0x29) [0x42a891] > [ 372.506] (EE) 13: ? (?+0x29) [0x29] > [ 372.506] (EE) > [ 372.506] (EE) Segmentation fault at address 0x0 > [ 372.506] (EE) > Fatal server error: > [ 372.506] (EE) Caught signal 11 (Segmentation fault). Server aborting > > There are messages in syslog, too: > > Feb 10 10:10:23 - kernel: [ 372.534759] radeon_gem_object_create:62 alloc > size 258Mb bigger than 256Mb limit > Feb 10 10:10:23 - kernel: [ 372.535188] radeon_gem_object_create:62 alloc > size 258Mb bigger than 256Mb limit > Feb 10 10:10:23 - kernel: [ 372.535259] radeon_gem_object_create:62 alloc > size 258Mb bigger than 256Mb limit > Feb 10 10:10:23 - kernel: [ 372.535706] radeon_gem_object_create:62 alloc > size 258Mb bigger than 256Mb limit > Feb 10 10:10:23 - kernel: [ 372.543252] radeon_gem_object_create:62 alloc > size 258Mb bigger than 256Mb limit > Feb 10 10:10:23 - kernel: [ 372.543316] radeon_gem_object_create:62 alloc > size 258Mb bigger than 256Mb limit Not sure whether it is a large pixmap related bug. could you try the patch v2 which will not use the texture tiling? thanks.
I tried v1 again with mesa and xf86-video-ati from git and everything works fine now: The image shows fine. No messages in Xorg.0.log or syslog. (In reply to comment #21) > Not sure whether it is a large pixmap related bug. could you try the patch > v2 which will not use the texture tiling? thanks. I will try v2 soon.
(In reply to comment #22) > I tried v1 again with mesa and xf86-video-ati from git and everything works > fine now: The image shows fine. No messages in Xorg.0.log or syslog. > I am confused. In comment 19, you reported that patch v1 cause xserver crashed. Now, it seems that patch v1 works fine? > (In reply to comment #21) > > Not sure whether it is a large pixmap related bug. could you try the patch > > v2 which will not use the texture tiling? thanks. > > I will try v2 soon.
(In reply to comment #23) > I am confused. In comment 19, you reported that patch v1 cause xserver > crashed. > Now, it seems that patch v1 works fine? I'm sorry, I hope I can clarify it: When testing v1 the first time I was using old versions of mesa (9.2.5) and xf86-video-ati (7.3.0). Then, I did a second test with recent versions from git and it worked fine. I'm running with patch v1 at the moment and haven't tested patch v2 yet.
(In reply to comment #24) > (In reply to comment #23) > > I am confused. In comment 19, you reported that patch v1 cause xserver > > crashed. > > Now, it seems that patch v1 works fine? > > I'm sorry, I hope I can clarify it: When testing v1 the first time I was > using old versions of mesa (9.2.5) and xf86-video-ati (7.3.0). Then, I did a > second test with recent versions from git and it worked fine. > > I'm running with patch v1 at the moment and haven't tested patch v2 yet. Thanks for the clarification. So, the patch v1 should work fine with latest mesa and latest ati ddx driver, right? If so, I will push v1 to master branch.
Okay, this is embarrassing: obviously the update for the second test made my xserver switch to the software rasterizer and I can't confirm that v1 is working at the moment. I'm sorry for the noise and the confusion. I will report back when I've _really_ tested v2.
(In reply to comment #26) > Okay, this is embarrassing: obviously the update for the second test made my > xserver switch to the software rasterizer and I can't confirm that v1 is > working at the moment. I'm sorry for the noise and the confusion. I will > report back when I've _really_ tested v2. Got it, thanks for the feedback. Then I will wait for your next update when you get the result for both v1 and v2 patch and make sure the glamor acceleration is enabled. Thanks.
(In reply to comment #20) > Created attachment 93747 [details] [review] > patch v2 I've tested this patch with a fully updated stack (see below) and I can now view the image from comment 8. Dmesg and the Xorg.0.log get spammed with error messages though. Dmesg shows the known line "radeon_gem_object_create:62 alloc size 354Mb bigger than 256Mb limit" while Xorg.0.log now has multiple instances of "(WW) glamor: Failed to create fbo, unsupported". Stack: GPU: "PITCAIRN" (ChipID = 0x6819) Linux: 3.13.0 libdrm: 2.4.52 LLVM: SVN:trunk/r201068 libclc: Git:master/d9a654573a Mesa: Git:master/40dd777b33 GLAMOR: Git:master/e734e1b621 + the patch from attachment 93747 [details] [review] DDX: Git:master/8de6f7b2f4 You can have my Tested-by: Kai Wasserbäch <kai@dev.carbon-project.org> for your patch.
I went back to Mesa 9.2.5 and xf86-video-ati 7.3.0 because I wasn't able to set up a working stack from git. I kept GLAMOR from git with patch v2 applied. xserver doesn't crash when I am viewing the image in Firefox and I get warning messages in Xorg.0.log and syslog. So, I can confirm glamor from git with patch v2 (attachment 93747 [details] [review]) is working for me now, too. (I double checked for glamor this time.) The crash I experienced in my earlier test was probably related to a linking issue of Mesa and LLVM (bug 70410). I can't reproduce it anymore after recompiling.
(In reply to comment #18) > (In reply to comment #16) > > Created attachment 93740 [details] [review] [review] [review] > > patch > > The warning log message might be noisy, but other than that, the patch looks > good to me, thanks. Right, that might be a little bit noisy. I will change to use glamor_fallback. > > > BTW, I previously forgot about proxy textures, which is the OpenGL mechanism > for probing whether a texture of certain dimensions can actually be used.
I just pushed the patch v2 to master branch, please help to test it and if everything is ok, please close this bug. Thanks. (In reply to comment #0) > Every time I try to open a specific JPEG image in Firefox 24 on my Gentoo > machine, my X server crashes and I have to start over from login. > > I got the following error message in Xorg.0.log.old: > > Fatal server error: > [ 5116.361] (EE) (EE) BUG: triggered 'if (f[f_idx])' > [ 5116.361] (EE) BUG: > /var/tmp/portage/x11-base/xorg-server-1.14.3-r2/work/xorg-server-1.14.3/os/ > log.c:464 in pnprintf() > [ 5116.361] (EE) Unsupported printf directive '#' > [ 5116.361] (EE) > [ 5116.362] (EE) Backtrace: > [ 5116.362] (EE) 0: /usr/bin/X (xorg_backtrace+0x36) [0x58adc6] > [ 5116.362] (EE) 1: /usr/bin/X (LogVMessageVerbSigSafe+0x818) [0x596558] > [ 5116.362] (EE) 2: /usr/bin/X (FatalError+0xcb) [0x59677b] > [ 5116.362] (EE) 3: /usr/lib64/libglamor.so.0 (0x7fd1cc56d000+0x26d57) > [0x7fd1cc593d57] > [ 5116.362] (EE) 4: /usr/lib64/libglamor.so.0 (0x7fd1cc56d000+0x26eb0) > [0x7fd1cc593eb0] > [ 5116.362] (EE) 5: /usr/lib64/libglamor.so.0 (glamor_create_pixmap+0x2d7) > [0x7fd1cc5717f7] > [ 5116.362] (EE) 6: /usr/lib64/xorg/modules/drivers/radeon_drv.so > (0x7fd1cba12000+0x4d5d4) [0x7fd1cba5f5d4] > [ 5116.362] (EE) 7: /usr/bin/X (0x400000+0x36c6f) [0x436c6f] > [ 5116.362] (EE) 8: /usr/bin/X (0x400000+0x3b3d6) [0x43b3d6] > [ 5116.362] (EE) 9: /usr/bin/X (0x400000+0x29dca) [0x429dca] > [ 5116.362] (EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf5) > [0x32ccc246c5] > [ 5116.362] (EE) 11: /usr/bin/X (0x400000+0x2a111) [0x42a111] > [ 5116.362] (EE) > [ 5116.362] destination is framebuffer incomplete: unsupported [%#x] > > I saw the printf problem is described bug #69573 and is already fixed in > git, so I applied the fixed the statement with a patch locally and tried > again. Here's the error message from Xorg.0.log.old with fixed printf > directive: > > [ 6840.056] (EE) destination is framebuffer incomplete: unsupported [8cdd] > > Hardware: > - AMD/ATI Radeon HD 7770 GHz Edition (Cape Verde XT) > > Software: > - xorg-server 1.14.3 > - mesa 9.2.1 > - xf86-video-ati 7.2.0 > - glamor 0.5.1 > - libdrm 2.4.47
I randomly hit what appears to be this bug, so I tried the patch. to test I went to google.com and searched 10000x10000 image and selected one by the name of Kings Dream, I'll have to track down the URL if required as I cant get it without X locking up. Before the patch X would die and I could login again, now it locks up, and I have to login to my desktop with my laptop to reboot it. Hardware: - [AMD/ATI] Cape Verde PRO [Radeon HD 7750] Software: - xorg-server 1.15.0 - mesa 10.0.3 - xf86-video-ati 7.3.0 - glamor 0.6.0 with patch applied - libdrm 2.4.52 from dmesg: [ 329.050365] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 329.050655] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 329.050715] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 329.240662] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 329.240739] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 329.240764] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 331.000281] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 331.000500] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 331.000530] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 331.424336] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 331.426850] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 331.426883] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 332.411985] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 332.413471] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 332.413504] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 358.971213] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 358.971662] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit [ 358.971687] radeon_gem_object_create:62 alloc size 385Mb bigger than 256Mb limit from xorg.log: [ 329.119] (WW) glamor: Failed to create fbo, unsupported [ 329.309] (WW) glamor: Failed to create fbo, unsupported [ 331.070] (WW) glamor: Failed to create fbo, unsupported [ 331.497] (WW) glamor: Failed to create fbo, unsupported [ 332.484] (WW) glamor: Failed to create fbo, unsupported [ 359.063] (WW) glamor: Failed to create fbo, unsupported (EE) [mi] EQ overflowing. Additional events will be discarded until existing events are processed. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x42) [0x598de2] (EE) 1: /usr/bin/X (mieqEnqueue+0x22b) [0x578c0b] (EE) 2: /usr/bin/X (0x400000+0x51032) [0x451032] (EE) 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f475738e000+0x6bf4) [0x7f4757394bf4] (EE) 4: /usr/bin/X (0x400000+0x7b1b8) [0x47b1b8] (EE) 5: /usr/bin/X (0x400000+0xa550f) [0x4a550f] (EE) 6: /lib64/libpthread.so.0 (0x7f4762525000+0x10ed0) [0x7f4762535ed0] (EE) 7: /lib64/libpthread.so.0 (pthread_cond_wait+0xcc) [0x7f4762531f3c] (EE) 8: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c00cb) [0x7f475d5540cb] (EE) 9: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c06a4) [0x7f475d5546a4] (EE) 10: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3a46d9) [0x7f475d5386d9] (EE) 11: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x186f54) [0x7f475d31af54] (EE) 12: /usr/lib64/libglamor.so.0 (glamor_block_handler+0x3d) [0x7f475fbdc63d] (EE) 13: /usr/bin/X (_CallCallbacks+0x34) [0x4413b4] (EE) 14: /usr/bin/X (FlushAllOutput+0x2b) [0x59c60b] (EE) 15: /usr/bin/X (0x400000+0x3bc3b) [0x43bc3b] (EE) 16: /usr/bin/X (0x400000+0x3ffad) [0x43ffad] (EE) 17: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f476117ec15] (EE) 18: /usr/bin/X (0x400000+0x2a551) [0x42a551] (EE) (EE) [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack. (EE) [mi] mieq is *NOT* the cause. It is a victim. (EE) [mi] EQ overflow continuing. 100 events have been dropped. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x42) [0x598de2] (EE) 1: /usr/bin/X (0x400000+0x51032) [0x451032] (EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f475738e000+0x6bf4) [0x7f4757394bf4] (EE) 3: /usr/bin/X (0x400000+0x7b1b8) [0x47b1b8] (EE) 4: /usr/bin/X (0x400000+0xa550f) [0x4a550f] (EE) 5: /lib64/libpthread.so.0 (0x7f4762525000+0x10ed0) [0x7f4762535ed0] (EE) 6: /lib64/libpthread.so.0 (pthread_cond_wait+0xcc) [0x7f4762531f3c] (EE) 7: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c00cb) [0x7f475d5540cb] (EE) 8: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c06a4) [0x7f475d5546a4] (EE) 9: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3a46d9) [0x7f475d5386d9] (EE) 10: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x186f54) [0x7f475d31af54] (EE) 11: /usr/lib64/libglamor.so.0 (glamor_block_handler+0x3d) [0x7f475fbdc63d] (EE) 12: /usr/bin/X (_CallCallbacks+0x34) [0x4413b4] (EE) 13: /usr/bin/X (FlushAllOutput+0x2b) [0x59c60b] (EE) 14: /usr/bin/X (0x400000+0x3bc3b) [0x43bc3b] (EE) 15: /usr/bin/X (0x400000+0x3ffad) [0x43ffad] (EE) 16: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f476117ec15] (EE) 17: /usr/bin/X (0x400000+0x2a551) [0x42a551] (EE) (EE) [mi] EQ overflow continuing. 200 events have been dropped. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x42) [0x598de2] (EE) 1: /usr/bin/X (0x400000+0x51032) [0x451032] (EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f475738e000+0x6bf4) [0x7f4757394bf4] (EE) 3: /usr/bin/X (0x400000+0x7b1b8) [0x47b1b8] (EE) 4: /usr/bin/X (0x400000+0xa550f) [0x4a550f] (EE) 5: /lib64/libpthread.so.0 (0x7f4762525000+0x10ed0) [0x7f4762535ed0] (EE) 6: /lib64/libpthread.so.0 (pthread_cond_wait+0xcc) [0x7f4762531f3c] (EE) 7: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c00cb) [0x7f475d5540cb] (EE) 8: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c06a4) [0x7f475d5546a4] (EE) 9: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3a46d9) [0x7f475d5386d9] (EE) 10: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x186f54) [0x7f475d31af54] (EE) 11: /usr/lib64/libglamor.so.0 (glamor_block_handler+0x3d) [0x7f475fbdc63d] (EE) 12: /usr/bin/X (_CallCallbacks+0x34) [0x4413b4] (EE) 13: /usr/bin/X (FlushAllOutput+0x2b) [0x59c60b] (EE) 14: /usr/bin/X (0x400000+0x3bc3b) [0x43bc3b] (EE) 15: /usr/bin/X (0x400000+0x3ffad) [0x43ffad] (EE) 16: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f476117ec15] (EE) 17: /usr/bin/X (0x400000+0x2a551) [0x42a551] (EE) (EE) [mi] EQ overflow continuing. 300 events have been dropped. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x42) [0x598de2] (EE) 1: /usr/bin/X (0x400000+0x51032) [0x451032] (EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f475738e000+0x6bf4) [0x7f4757394bf4] (EE) 3: /usr/bin/X (0x400000+0x7b1b8) [0x47b1b8] (EE) 4: /usr/bin/X (0x400000+0xa550f) [0x4a550f] (EE) 5: /lib64/libpthread.so.0 (0x7f4762525000+0x10ed0) [0x7f4762535ed0] (EE) 6: /lib64/libpthread.so.0 (pthread_cond_wait+0xcc) [0x7f4762531f3c] (EE) 7: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c00cb) [0x7f475d5540cb] (EE) 8: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c06a4) [0x7f475d5546a4] (EE) 9: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3a46d9) [0x7f475d5386d9] (EE) 10: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x186f54) [0x7f475d31af54] (EE) 11: /usr/lib64/libglamor.so.0 (glamor_block_handler+0x3d) [0x7f475fbdc63d] (EE) 12: /usr/bin/X (_CallCallbacks+0x34) [0x4413b4] (EE) 13: /usr/bin/X (FlushAllOutput+0x2b) [0x59c60b] (EE) 14: /usr/bin/X (0x400000+0x3bc3b) [0x43bc3b] (EE) 15: /usr/bin/X (0x400000+0x3ffad) [0x43ffad] (EE) 16: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f476117ec15] (EE) 17: /usr/bin/X (0x400000+0x2a551) [0x42a551] (EE) (EE) [mi] EQ overflow continuing. 400 events have been dropped. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x42) [0x598de2] (EE) 1: /usr/bin/X (0x400000+0x51032) [0x451032] (EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f475738e000+0x6bf4) [0x7f4757394bf4] (EE) 3: /usr/bin/X (0x400000+0x7b1b8) [0x47b1b8] (EE) 4: /usr/bin/X (0x400000+0xa550f) [0x4a550f] (EE) 5: /lib64/libpthread.so.0 (0x7f4762525000+0x10ed0) [0x7f4762535ed0] (EE) 6: /lib64/libpthread.so.0 (pthread_cond_wait+0xcc) [0x7f4762531f3c] (EE) 7: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c00cb) [0x7f475d5540cb] (EE) 8: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c06a4) [0x7f475d5546a4] (EE) 9: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3a46d9) [0x7f475d5386d9] (EE) 10: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x186f54) [0x7f475d31af54] (EE) 11: /usr/lib64/libglamor.so.0 (glamor_block_handler+0x3d) [0x7f475fbdc63d] (EE) 12: /usr/bin/X (_CallCallbacks+0x34) [0x4413b4] (EE) 13: /usr/bin/X (FlushAllOutput+0x2b) [0x59c60b] (EE) 14: /usr/bin/X (0x400000+0x3bc3b) [0x43bc3b] (EE) 15: /usr/bin/X (0x400000+0x3ffad) [0x43ffad] (EE) 16: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f476117ec15] (EE) 17: /usr/bin/X (0x400000+0x2a551) [0x42a551] (EE) (EE) [mi] EQ overflow continuing. 500 events have been dropped. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x42) [0x598de2] (EE) 1: /usr/bin/X (0x400000+0x51032) [0x451032] (EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f475738e000+0x6bf4) [0x7f4757394bf4] (EE) 3: /usr/bin/X (0x400000+0x7b1b8) [0x47b1b8] (EE) 4: /usr/bin/X (0x400000+0xa550f) [0x4a550f] (EE) 5: /lib64/libpthread.so.0 (0x7f4762525000+0x10ed0) [0x7f4762535ed0] (EE) 6: /lib64/libpthread.so.0 (pthread_cond_wait+0xcc) [0x7f4762531f3c] (EE) 7: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c00cb) [0x7f475d5540cb] (EE) 8: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c06a4) [0x7f475d5546a4] (EE) 9: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3a46d9) [0x7f475d5386d9] (EE) 10: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x186f54) [0x7f475d31af54] (EE) 11: /usr/lib64/libglamor.so.0 (glamor_block_handler+0x3d) [0x7f475fbdc63d] (EE) 12: /usr/bin/X (_CallCallbacks+0x34) [0x4413b4] (EE) 13: /usr/bin/X (FlushAllOutput+0x2b) [0x59c60b] (EE) 14: /usr/bin/X (0x400000+0x3bc3b) [0x43bc3b] (EE) 15: /usr/bin/X (0x400000+0x3ffad) [0x43ffad] (EE) 16: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f476117ec15] (EE) 17: /usr/bin/X (0x400000+0x2a551) [0x42a551] (EE) (EE) [mi] EQ overflow continuing. 600 events have been dropped. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x42) [0x598de2] (EE) 1: /usr/bin/X (0x400000+0x51032) [0x451032] (EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f475738e000+0x6bf4) [0x7f4757394bf4] (EE) 3: /usr/bin/X (0x400000+0x7b1b8) [0x47b1b8] (EE) 4: /usr/bin/X (0x400000+0xa550f) [0x4a550f] (EE) 5: /lib64/libpthread.so.0 (0x7f4762525000+0x10ed0) [0x7f4762535ed0] (EE) 6: /lib64/libpthread.so.0 (pthread_cond_wait+0xcc) [0x7f4762531f3c] (EE) 7: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c00cb) [0x7f475d5540cb] (EE) 8: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c06a4) [0x7f475d5546a4] (EE) 9: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3a46d9) [0x7f475d5386d9] (EE) 10: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x186f54) [0x7f475d31af54] (EE) 11: /usr/lib64/libglamor.so.0 (glamor_block_handler+0x3d) [0x7f475fbdc63d] (EE) 12: /usr/bin/X (_CallCallbacks+0x34) [0x4413b4] (EE) 13: /usr/bin/X (FlushAllOutput+0x2b) [0x59c60b] (EE) 14: /usr/bin/X (0x400000+0x3bc3b) [0x43bc3b] (EE) 15: /usr/bin/X (0x400000+0x3ffad) [0x43ffad] (EE) 16: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f476117ec15] (EE) 17: /usr/bin/X (0x400000+0x2a551) [0x42a551] (EE) (EE) [mi] EQ overflow continuing. 700 events have been dropped. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x42) [0x598de2] (EE) 1: /usr/bin/X (0x400000+0x51032) [0x451032] (EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f475738e000+0x6bf4) [0x7f4757394bf4] (EE) 3: /usr/bin/X (0x400000+0x7b1b8) [0x47b1b8] (EE) 4: /usr/bin/X (0x400000+0xa550f) [0x4a550f] (EE) 5: /lib64/libpthread.so.0 (0x7f4762525000+0x10ed0) [0x7f4762535ed0] (EE) 6: /lib64/libpthread.so.0 (pthread_cond_wait+0xcc) [0x7f4762531f3c] (EE) 7: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c00cb) [0x7f475d5540cb] (EE) 8: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c06a4) [0x7f475d5546a4] (EE) 9: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3a46d9) [0x7f475d5386d9] (EE) 10: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x186f54) [0x7f475d31af54] (EE) 11: /usr/lib64/libglamor.so.0 (glamor_block_handler+0x3d) [0x7f475fbdc63d] (EE) 12: /usr/bin/X (_CallCallbacks+0x34) [0x4413b4] (EE) 13: /usr/bin/X (FlushAllOutput+0x2b) [0x59c60b] (EE) 14: /usr/bin/X (0x400000+0x3bc3b) [0x43bc3b] (EE) 15: /usr/bin/X (0x400000+0x3ffad) [0x43ffad] (EE) 16: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f476117ec15] (EE) 17: /usr/bin/X (0x400000+0x2a551) [0x42a551] (EE) (EE) [mi] EQ overflow continuing. 800 events have been dropped. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x42) [0x598de2] (EE) 1: /usr/bin/X (0x400000+0x51032) [0x451032] (EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f475738e000+0x6bf4) [0x7f4757394bf4] (EE) 3: /usr/bin/X (0x400000+0x7b1b8) [0x47b1b8] (EE) 4: /usr/bin/X (0x400000+0xa550f) [0x4a550f] (EE) 5: /lib64/libpthread.so.0 (0x7f4762525000+0x10ed0) [0x7f4762535ed0] (EE) 6: /lib64/libpthread.so.0 (pthread_cond_wait+0xcc) [0x7f4762531f3c] (EE) 7: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c00cb) [0x7f475d5540cb] (EE) 8: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c06a4) [0x7f475d5546a4] (EE) 9: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3a46d9) [0x7f475d5386d9] (EE) 10: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x186f54) [0x7f475d31af54] (EE) 11: /usr/lib64/libglamor.so.0 (glamor_block_handler+0x3d) [0x7f475fbdc63d] (EE) 12: /usr/bin/X (_CallCallbacks+0x34) [0x4413b4] (EE) 13: /usr/bin/X (FlushAllOutput+0x2b) [0x59c60b] (EE) 14: /usr/bin/X (0x400000+0x3bc3b) [0x43bc3b] (EE) 15: /usr/bin/X (0x400000+0x3ffad) [0x43ffad] (EE) 16: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f476117ec15] (EE) 17: /usr/bin/X (0x400000+0x2a551) [0x42a551] (EE) (EE) [mi] EQ overflow continuing. 900 events have been dropped. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x42) [0x598de2] (EE) 1: /usr/bin/X (0x400000+0x51032) [0x451032] (EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f475738e000+0x6bf4) [0x7f4757394bf4] (EE) 3: /usr/bin/X (0x400000+0x7b1b8) [0x47b1b8] (EE) 4: /usr/bin/X (0x400000+0xa550f) [0x4a550f] (EE) 5: /lib64/libpthread.so.0 (0x7f4762525000+0x10ed0) [0x7f4762535ed0] (EE) 6: /lib64/libpthread.so.0 (pthread_cond_wait+0xcc) [0x7f4762531f3c] (EE) 7: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c00cb) [0x7f475d5540cb] (EE) 8: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c06a4) [0x7f475d5546a4] (EE) 9: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3a46d9) [0x7f475d5386d9] (EE) 10: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x186f54) [0x7f475d31af54] (EE) 11: /usr/lib64/libglamor.so.0 (glamor_block_handler+0x3d) [0x7f475fbdc63d] (EE) 12: /usr/bin/X (_CallCallbacks+0x34) [0x4413b4] (EE) 13: /usr/bin/X (FlushAllOutput+0x2b) [0x59c60b] (EE) 14: /usr/bin/X (0x400000+0x3bc3b) [0x43bc3b] (EE) 15: /usr/bin/X (0x400000+0x3ffad) [0x43ffad] (EE) 16: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f476117ec15] (EE) 17: /usr/bin/X (0x400000+0x2a551) [0x42a551] (EE) (EE) [mi] EQ overflow continuing. 1000 events have been dropped. (EE) [mi] No further overflow reports will be reported until the clog is cleared. (EE) (EE) Backtrace: (EE) 0: /usr/bin/X (xorg_backtrace+0x42) [0x598de2] (EE) 1: /usr/bin/X (0x400000+0x51032) [0x451032] (EE) 2: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f475738e000+0x6bf4) [0x7f4757394bf4] (EE) 3: /usr/bin/X (0x400000+0x7b1b8) [0x47b1b8] (EE) 4: /usr/bin/X (0x400000+0xa550f) [0x4a550f] (EE) 5: /lib64/libpthread.so.0 (0x7f4762525000+0x10ed0) [0x7f4762535ed0] (EE) 6: /lib64/libpthread.so.0 (pthread_cond_wait+0xcc) [0x7f4762531f3c] (EE) 7: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c00cb) [0x7f475d5540cb] (EE) 8: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3c06a4) [0x7f475d5546a4] (EE) 9: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x3a46d9) [0x7f475d5386d9] (EE) 10: /usr/lib64/dri/radeonsi_dri.so (0x7f475d194000+0x186f54) [0x7f475d31af54] (EE) 11: /usr/lib64/libglamor.so.0 (glamor_block_handler+0x3d) [0x7f475fbdc63d] (EE) 12: /usr/bin/X (_CallCallbacks+0x34) [0x4413b4] (EE) 13: /usr/bin/X (FlushAllOutput+0x2b) [0x59c60b] (EE) 14: /usr/bin/X (0x400000+0x3bc3b) [0x43bc3b] (EE) 15: /usr/bin/X (0x400000+0x3ffad) [0x43ffad] (EE) 16: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f476117ec15] (EE) 17: /usr/bin/X (0x400000+0x2a551) [0x42a551]
The url that caused the above was: http://webpages.charter.net/snowsmann/kings%20dream.jpg Just in case, save anything you want to keep before trying it.
In reply to comment 32 and comment 33: I can open that picture just fine with the patch applied. The result is the same as described in comment 28. The only differnces between the setups I can see are: - different GPU - different version of Mesa (and probably LLVM?) Maybe try a more recent version of Mesa (and LLVM)?
(In reply to comment #34) > In reply to comment 32 and comment 33: > I can open that picture just fine with the patch applied. The result is the > same as described in comment 28. The only differnces between the setups I > can see are: > - different GPU > - different version of Mesa (and probably LLVM?) > > Maybe try a more recent version of Mesa (and LLVM)? mesa 10.0.3 and llvm 3.4 are the latest non-git versions available to me at the moment, so I'll look into what options I have. Thank you
The fix has landed, resolving per comment #29. If someone still has issues, please file a new report.
just got a crash on X-server with attempting to load a big image in firefox: embedded, on html site -> "View Image" -> crash [ 3741.017575] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3741.018407] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3741.018435] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3741.018438] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3741.023988] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3741.024002] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3741.024010] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3741.024012] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.889766] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.890786] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.890831] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.890834] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.890982] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.890994] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.891029] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.891032] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.919906] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.919915] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.919932] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.919934] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.920082] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.920096] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.920106] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3742.920108] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3743.189248] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3743.189343] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3743.189362] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3743.189365] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3743.189509] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3743.189522] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3743.189534] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3743.189536] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3753.746171] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3753.752240] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3753.752290] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3753.752293] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3753.752806] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3753.752817] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3753.752825] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit [ 3753.752828] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit applied "patch v2" to glamor 0.6.0-r1 (in the Gentoo Portage-Tree) and X doesn't crash anymore before that I wanted to try out glamor-9999 (latest upstream) but unfortunately it didn't load with [ 3434.583] (II) Loading /usr/lib64/xorg/modules/drivers/radeon_drv.so [ 3434.583] (EE) Failed to load /usr/lib64/xorg/modules/drivers/radeon_drv.so: /usr/lib64/libglamor.so.0: undefined symbol: fbCopyPlane
libglamor.so.0: undefined symbol: fbCopyPlane that is an issue triggered by the Gentoo hardened toolchain, ... anyways: when using upstream glamor - the graphics drivers/stack seems to hardlock, the messages from upstream glamor: Jul 21 17:09:43 morpheus kernel: [11355.805556] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:09:43 morpheus kernel: [11355.806543] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:09:43 morpheus kernel: [11355.806590] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:09:43 morpheus kernel: [11355.806593] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:09:43 morpheus kernel: [11355.806686] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:09:43 morpheus kernel: [11355.806694] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:09:43 morpheus kernel: [11355.806708] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:09:43 morpheus kernel: [11355.806710] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit and glamor 0.6.0-r1 (gentoo in-tree) are the same Jul 21 17:14:25 morpheus kernel: [ 187.087695] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:14:25 morpheus kernel: [ 187.088426] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:14:25 morpheus kernel: [ 187.088449] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:14:25 morpheus kernel: [ 187.088452] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:14:25 morpheus kernel: [ 187.089505] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:14:25 morpheus kernel: [ 187.089514] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:14:25 morpheus kernel: [ 187.089521] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:14:25 morpheus kernel: [ 187.089523] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:14:28 morpheus kernel: [ 190.234703] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:14:28 morpheus kernel: [ 190.235844] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:14:28 morpheus kernel: [ 190.235875] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:14:28 morpheus kernel: [ 190.235878] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit Jul 21 17:14:28 morpheus kernel: [ 190.236018] radeon_gem_object_create:62 alloc size 289Mb bigger than 256Mb limit but with upstream glamor X isn't usable Hardware: VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao XT [Radeon R9 270X] Software: X.Org X Server 1.16.99.1, Release Date: 2014-07-17 (latest upstream from git) mesa (latest upstream from git) xf86-video-ati (latest upstream from git) glamor 0.6.0-r1 + patch v2 - running fine + error messages glamor (latest upstream from git) - X/graphics stack locking up (no additional kernel error messages available) libdrm (latest upstream from git) Re-Open ?
new bug filed at: https://bugs.freedesktop.org/show_bug.cgi?id=81612
*** Bug 84492 has been marked as a duplicate of this bug. ***
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.