(needs 9.1.3) r600_dri.so crashes in r600_texture_create_object (memset)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mesa |
Fix Released
|
Medium
|
|||
mesa (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
This is similar to bug #1174495 since it is mostly caused by WM, but it could actually be caused also by other applications so we need to include a proper fix in Mesa as well.
The crash trace is at http://
In freedesktop.org Bugzilla #61182, Eugene Shalygin (eugene-shalygin) wrote : | #1 |
In freedesktop.org Bugzilla #61182, Eugene Shalygin (eugene-shalygin) wrote : | #2 |
This happens only when kwin starts for the first time. There are no crashes at next runs.
In freedesktop.org Bugzilla #61182, Eugene Shalygin (eugene-shalygin) wrote : | #3 |
Same crash with the same backtrace using mesa 9.1 and kernel 3.8
In freedesktop.org Bugzilla #61182, Eugene Shalygin (eugene-shalygin) wrote : | #4 |
With "glamor" as acceleration method, these crashes are much more rare
In freedesktop.org Bugzilla #61182, Knut-tidemann (knut-tidemann) wrote : | #5 |
I can confirm a very similar crash:
#5 0x00007fb122be859b in __memset_sse2 () from /usr/lib/libc.so.6
#6 0x00007fb072bd0a5f in r600_texture_
#7 0x00007fb072bd0d37 in r600_texture_create () from /usr/lib/
#8 0x00007fb072be3145 in dri2_allocate_
#9 0x00007fb072be1c65 in dri_st_
#10 0x00007fb072be1e9e in dri_set_tex_buffer2 () from /usr/lib/
#11 0x00007fb122fd94b3 in ?? () from /usr/lib/
(I don't have debug symbols for kwin, and mesa was compiled in release mode).
Mesa 9.2-devel (git-4154ac0)
Kernel 3.8.0.
KDE 4.10.
I get the crash when first logging in, but I also get it every time I unlock the screen after locking it from the 'K-menu'.
The crash only occurs if compositing is on.
In freedesktop.org Bugzilla #61182, Knut-tidemann (knut-tidemann) wrote : | #6 |
I forgot to add:
My card is a Radeon HD 5670
In freedesktop.org Bugzilla #61182, Eugene Shalygin (eugene-shalygin) wrote : | #7 |
The same crash happens time to time when maximizing application windows
In freedesktop.org Bugzilla #61182, Eugene Shalygin (eugene-shalygin) wrote : | #8 |
it is quite interesting to note that the crash happens only using 1920x1080 and higher screen resolution. If the resolution is lower, kwin works fine.
In freedesktop.org Bugzilla #61182, Jürg Billeter (j-bitron) wrote : | #9 |
I don't have a usable backtrace at hand, but I'm seeing very similar crashes in gnome-shell as well with Mesa 9.1 and Linux 3.8.3. With Mesa 9.0.3, I haven't noticed any crashes so far. It crashes much more frequently with two monitors (both 1920x1200) attached than with just one.
This is on an x86-64 system with Radeon HD 4770.
In freedesktop.org Bugzilla #61182, agd5f (agd5f) wrote : | #10 |
(In reply to comment #8)
> I don't have a usable backtrace at hand, but I'm seeing very similar crashes
> in gnome-shell as well with Mesa 9.1 and Linux 3.8.3. With Mesa 9.0.3, I
> haven't noticed any crashes so far. It crashes much more frequently with two
> monitors (both 1920x1200) attached than with just one.
Can you bisect mesa?
In freedesktop.org Bugzilla #61182, Jürg Billeter (j-bitron) wrote : | #11 |
(In reply to comment #9)
> (In reply to comment #8)
> > I don't have a usable backtrace at hand, but I'm seeing very similar crashes
> > in gnome-shell as well with Mesa 9.1 and Linux 3.8.3. With Mesa 9.0.3, I
> > haven't noticed any crashes so far. It crashes much more frequently with two
> > monitors (both 1920x1200) attached than with just one.
>
> Can you bisect mesa?
I don't have a reliable trigger for the crash yet. If I can find one, I'll give it a try.
In freedesktop.org Bugzilla #61182, Michael Mair-Keimberger (bu9zilla) wrote : | #12 |
I don't know if its the same but i can confirm similar crashes.
First of all, i have a triple head setup, 2 screens with 1920x1200 (left and right) and one with 2560x1600 (middle). Those crashes happen since kernel 3.8 (i've used 3.8.[1-4]) and mesa-9.1 but i don't know which one actually introduced the problem as i both updated at the same time..
Furthermore they are no crashes at all if i disable desktop effects in kde.
Basically i only have to create an new user and login into it. Kde usually sets the resolution of all screens to 1920x1200 with enabled desktop effect. I can actually move the screens back and forth (because the ordering is wrong too with the first start) without problems, but as soon as i'm changing the resolution of the middle screen X crashes.
Without effects i won't get any crashes.
If you need more info, please let me know.
Below are the relevant parts of Xorg.0.log (even though without debug symbols i think its quite useless ;) ):
[ 1671.397] (EE)
[ 1671.397] (EE) Backtrace:
[ 1671.397] (EE) 0: /usr/bin/X (xorg_backtrace
[ 1671.397] (EE) 1: /usr/bin/X (0x400000+0x189e09) [0x589e09]
[ 1671.397] (EE) 2: /lib64/
[ 1671.397] (EE) 3: /lib64/libc.so.6 (0x7ff6d5238000
[ 1671.397] (EE) 4: /usr/lib64/
[ 1671.397] (EE) 5: /usr/lib64/
[ 1671.398] (EE) 6: /usr/lib64/
[ 1671.398] (EE) 7: /usr/lib64/
[ 1671.398] (EE) 8: /usr/lib64/
[ 1671.398] (EE) 9: /usr/lib64/
[ 1671.398] (EE) 10: /usr/lib64/
[ 1671.398] (EE) 11: /usr/lib64/
[ 1671.398] (EE) 12: /usr/lib64/
[ 1671.398] (EE) 13: /usr/bin/X (0x400000+0x3ad96) [0x43ad96]
[ 1671.398] (EE) 14: /usr/bin/X (0x400000+0x29e8d) [0x429e8d]
[ 1671.398] (EE) 15: /lib64/libc.so.6 (__libc_
[ 1671.398] (EE) 16: /usr/bin/X (0x400000+0x2a1fd) [0x42a1fd]
[ 1671.398] (EE)
[ 1671.398] (EE) Bus error at address 0x7ff6ccbee000
[ 1671.398]
Fatal server error:
[ 1671.398] Caught signal 7 (Bus error). Server aborting
[ 1671.398]
[ 1671.398] (EE)
Please consult the The X.Org Foundation support
at http://
for help.
[ 1671.398] (EE) Please also check the log file at "/var/log/
[ 1671.398] (EE)
[ 1671.398] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 1671.460] Server terminated with error (1). Closing log file.
In freedesktop.org Bugzilla #61182, agd5f (agd5f) wrote : | #13 |
I think these are actually several bugs at play here.
1. CPU only has a 256 MB window into vram. If the window is full due to fragmentation or other mapped buffers, we fail. Does disabling hyperz help? set env var R600_HYPERZ=0 (mesa 9.1 or older), or R600_DEBUG=nohyperz (mesa git).
2. running out of GPU accessible memory when migrating buffers. Does setting radeon.
In freedesktop.org Bugzilla #61182, Michel Dänzer (michel-daenzer) wrote : | #14 |
Eugene and Knut, in the future please always include information about which signal was generated, at least if it's not SIGSEGV (which is the most common).
In freedesktop.org Bugzilla #61182, Michael Mair-Keimberger (bu9zilla) wrote : | #15 |
(In reply to comment #12)
> I think these are actually several bugs at play here.
>
> 1. CPU only has a 256 MB window into vram. If the window is full due to
> fragmentation or other mapped buffers, we fail. Does disabling hyperz help?
> set env var R600_HYPERZ=0 (mesa 9.1 or older), or R600_DEBUG=nohyperz (mesa
> git).
>
> 2. running out of GPU accessible memory when migrating buffers. Does
> setting radeon.
Just tried both, but nothing changed...
In freedesktop.org Bugzilla #61182, Eugene Shalygin (eugene-shalygin) wrote : | #16 |
(In reply to comment #14)
Also tried both suggestions. Both changes together allows me to run `kwin --replace` with active kwin_gles. However, when I connect a second screen, it crashes (signal 7) with the same backtrace. When I toggle desktop effects, it crashes also.
In freedesktop.org Bugzilla #61182, Jürg Billeter (j-bitron) wrote : | #17 |
No gnome-shell crashes since I've upgraded to Mesa 9.1.1. Will post an update in a few days whether it remains stable or I was just lucky today.
In freedesktop.org Bugzilla #61182, D. Hugh Redelmeier (hugh-mimosa) wrote : | #18 |
I think that I am hitting this bug on Fedora 18 x86-64 with all current updates (as of a couple of days ago).
I'm hitting it in Gnome_shell (
In freedesktop.org Bugzilla #61182, D. Hugh Redelmeier (hugh-mimosa) wrote : | #19 |
(Sorry for the previous uncompleted comment. I will continue.)
I'm hitting it in Gnome_shell (https:/
I'm hitting it in Cinnamon (https:/
I'm hitting it in KWin (https:/
In each case, I get a SIGBUS in __memset_sse2, called from r600 code. I'm not used to getting SIGBUSes since I migrated from the PDP-11 :-).
This makes me think that it is a radeon driver bug.
One KDE developer pointed in another direction. Since it is reported as an intel driver bug, I don't think that it is right, but it might be relevant: https:/
I think that I still have crash dumps for each of these. If something from them would be useful, ask soon before I recover the space. But I think that I can regenerate one all too quickly.
In freedesktop.org Bugzilla #61182, D. Hugh Redelmeier (hugh-mimosa) wrote : | #20 |
More information about my Fedora 18 x86-64 configuration:
- a single monitor: 2560 x 1600 pixels
- video card: Radeon HD 3600 XT (according to Xorg.0.log)
- Fedora's kernel: kernel-
- Fedora's mesa:
mesa-debuginfo-
mesa-dri-
mesa-dri-
mesa-libEGL-
mesa-libgbm-
mesa-libGL-
mesa-libglapi-
mesa-libGLU-
mesa-libGLU-
mesa-libxatrack
I didn't have this problem when running Fedora 17. But I did have a bit of oddness: https:/
Is anything else of interest?
In freedesktop.org Bugzilla #61182, Muteki-f (muteki-f) wrote : | #21 |
(In reply to comment #16)
> No gnome-shell crashes since I've upgraded to Mesa 9.1.1. Will post an
> update in a few days whether it remains stable or I was just lucky today.
Observed the same gnome-shell crash problem with Mesa 9.1.1 with kernel 3.8.4-202 also. The way how I reproduce this is to have dual monitors. The left one with resolution 1680x1050 (rotated counterclockwise) and the right with 1920x1200. With this setup, gnome-shell will always crash at initial login. If I don't rotate the left monitor, gnome-shell will not crash.
In freedesktop.org Bugzilla #61182, Korgens (korgens) wrote : | #22 |
I can also confirm this bug.
Software:
Archlinux standard installation.
Linux 3.8.4-1-ARCH #1 SMP PREEMPT Wed Mar 20 22:10:25 CET 2013 x86_64 GNU/Linux
KDE: 4.10.1 (no widgets, other than the task panel)
Kwin: 4.10.1 (standard OpenGL effects installed)
Org X Server 1.14.0
Release Date: 2013-03-05
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.8.2-1-ARCH x86_64
Kernel command line: BOOT_IMAGE=
Build Date: 09 March 2013 11:43:05AM
Current version of pixman: 0.28.2
mesa: 9.1.1-1 (standard Arch package)
I also tried a git version from AUR repository (same crashes):
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL version string: 3.0 Mesa 9.2.0 (git-135bb3c)
OpenGL shading language version string: 1.30
Driver: R600G
GPU class: R700
OpenGL version: 3.0
GLSL version: 1.30
Mesa version: 9.2
X server version: 1.14
Linux kernel version: 3.8.4
Direct rendering: yes
Requires strict binding: no
GLSL shaders: yes
Texture NPOT support: yes
Virtual Machine: no
Application:
Xorg.conf: empty
Hardware:
Intel i7 920
ATI RV790 [Radeon HD 4890] 1GB VRAM
Monitor 1: 1920x1200 (DVI) - image as background
Monitor 2: 1920x1080 (HDMI) - image as background
Two virtual desktops configured.
How to reproduce: just log in into KDM. When the standard KDE desktop is displayed the first Kwin crash (caused by r600 crash) has occurred and its errors is already being displayed. Kwin is re-spawned and everything seems to be normal for some minutes. Then it crashes again and then again, and again until kwin and the desktop are dead definitively.
It doesn't seem to matter what applications are being used or if the second monitor is on or off. The crashes happens all the same.
I didn't try to downgrade either the kernel or xorg, but I'm sure those crashes started to happen after the latest kernel upgrade to 3.8.x.
Here is the backtrace, which seems to confirm the general suspicion of a texture-handling problem:
Thread 1 (Thread 0x7fb64bdb6780 (LWP 734)):
[KCrash Handler]
#5 0x00007fb64b59859b in __memset_sse2 () from /usr/lib/libc.so.6
#6 0x00007fb59a42b40a in r600_texture_
#7 0x00007fb59a42b6e7 in r600_texture_create () from /usr/lib/
#8 0x00007fb59a43fbb5 in dri2_allocate_
#9 0x00007fb59a43e695 in dri_st_
#10 0x00007fb59a43e8ce in dri_set_tex_buffer2 () from /usr/lib/
#11 0x00007fb64b989343 in KWin::GlxTextur
#12 0x00007fb64b9810f5 in KWin::SceneO...
In freedesktop.org Bugzilla #61182, Ogjerstad (ogjerstad) wrote : | #23 |
I can also confirm this bug on Fedora 18 X86_64, radeon driver, HD5870 card.
I cannot log into the system with two external monitors attached, but with only one external monitor it works fine. This seems to have started to happen after upgrade to mesa-dri-drivers 9.1-1 or 9.1-3 (I did not restart between those updates). Here is my backtrace:
b7b62d4d01e98c8
c9e82f1ca30be88
c9e82f1ca30be88
c9e82f1ca30be88
c9e82f1ca30be88
c9e82f1ca30be88
67f4899c1db4d10
67f4899c1db4d10
67f4899c1db4d10
67f4899c1db4d10
67f4899c1db4d10
c043a38bda0d5dc
c043a38bda0d5dc
c043a38bda0d5dc
c043a38bda0d5dc
c043a38bda0d5dc
c043a38bda0d5dc
1c54a46d2f8de1b
1c54a46d2f8de1b
1c54a46d2f8de1b
1c54a46d2f8de1b
In freedesktop.org Bugzilla #61182, Ogjerstad (ogjerstad) wrote : | #24 |
I can confirm now that downgrading mesa-dri-drivers to 9.0.1-1 (as packaged by Fedora) fixes the problem.
In freedesktop.org Bugzilla #61182, agd5f (agd5f) wrote : | #25 |
(In reply to comment #23)
> I can confirm now that downgrading mesa-dri-drivers to 9.0.1-1 (as packaged
> by Fedora) fixes the problem.
Can you bisect mesa?
In freedesktop.org Bugzilla #61182, Ogjerstad (ogjerstad) wrote : | #26 |
Not without some instructions, I have never done that before.
And, I must admit, I also downgraded llvm-libs, mesa-dri-filesystem and mesa-libxatracker. I think I had to because of dependences.
I guess I will have to build from source in that case?
In freedesktop.org Bugzilla #61182, agd5f (agd5f) wrote : | #27 |
*** Bug 61822 has been marked as a duplicate of this bug. ***
In freedesktop.org Bugzilla #61182, Knut-tidemann (knut-tidemann) wrote : | #28 |
I've bisected the issue to this commit:
35840ab189595b8
The only thing that was recompiled was mesa, with the following options:
--with-
--with-
--with-
--with-
--enable-
--enable-
--enable-
--enable-gles1
--enable-gles2
--enable-egl
--enable-dri
--enable-glx
--enable-xa
--enable-osmesa
--enable-gbm
--enable-
The issue was triggered by restarting kwin (kwin --replace) between each compile and locking and unlocking the screen.
In freedesktop.org Bugzilla #61182, Xeno-l (xeno-l) wrote : | #29 |
Here happens similar thing. KWin with desktop effects enabled crashes on login to KDE and after resume from suspend with 100% reproductibility.
My config Fedora 18.
- kernel-
- libdrm-
- xorg-x11-
- mesa-dri-
- kde 4.10.2-1
Backtrace:
Application: KWin (kwin), signal: Bus error
Using host libthread_db library "/lib/libthread
[Current thread is 1 (Thread 0xb769c780 (LWP 18403))]
Thread 2 (Thread 0xb1644b40 (LWP 18417)):
#0 0xb7784424 in __kernel_vsyscall ()
#1 0x4145e18c in pthread_
#2 0xb2d5c20c in pipe_semaphore_wait (sema=0xb4190b50) at ../../.
#3 radeon_
#4 0x4145aaff in start_thread (arg=0xb1644b40) at pthread_
#5 0x4138a0be in clone () at ../sysdeps/
Thread 1 (Thread 0xb769c780 (LWP 18403)):
[KCrash Handler]
#7 __memset_sse2 () at ../sysdeps/
#8 0xb2d2f186 in r600_texture_
#9 0xb2d2f49c in r600_texture_create (screen=
#10 0xb2d28564 in r600_resource_
#11 0xb2d5650f in dri2_drawable_
#12 dri2_allocate_
#13 0xb2d5788c in dri_st_
#14 0xb2d57ab7 in dri_drawable_
#15 dri_set_tex_buffer2 (pDRICtx=0x9310270, target=3553, format=8409, dPriv=0x948c7a0) at dri_drawable.c:220
#16 0xb771b770 in dri2_bind_tex_image (dpy=0x91897e8, drawable=29360181, buffer=8414, attrib_list=0x0) at dri2_glx.c:1004
#17 0xb76efa93 in __glXBindTexIma
#18 0x447d5a8c in loadTexture (depth=24, size=..., pix=@0xbfc4b40c: 29360179, this=0x9494f08) at /usr/src/
#19 KWin::GlxTextur
#20 0x447ca65a in KWin::SceneOpen
#21 0x447ccaf7 in KWin::SceneOpen
#22 0x4...
In freedesktop.org Bugzilla #61182, Marek Olšák (maraeo) wrote : | #30 |
r600g crashes because it's mapping a MSAA resource in order to clear the CMASK to zeros. The problem is MSAA resources occupy a lot of memory and the system is failing to map the whole resource.
The solution is easy: we should clear the CMASK and HTILE buffers using DMA or streamout and not with the CPU.
In freedesktop.org Bugzilla #61182, Glisse (glisse) wrote : | #31 |
Well this is also a kwin bug, kwin should not pick MSAA visual. I fixed cogl so that it does not pick msaa visual for gnome-shell.
In freedesktop.org Bugzilla #61182, Maxim Egorushkin (max0x7ba) wrote : | #32 |
I observe the same issue on Fedora 18 with Radeon HD 5670:
[KCrash Handler]
#6 __memset_sse2 () at ../sysdeps/
#7 0x00007f59a39eaff2 in memset (__len=<optimized out>, __ch=204, __dest=<optimized out>) at /usr/include/
#8 r600_texture_
#9 0x00007f59a39eb2c7 in r600_texture_create (screen=0x1f317a0, templ=0x7fff577
#10 0x00007f59a39fda25 in dri2_drawable_
#11 dri2_allocate_
#12 0x00007f59a39fc595 in dri_st_
#13 0x00007f59a39fc7ce in dri_drawable_
#14 dri_set_tex_buffer2 (pDRICtx=<optimized out>, target=3553, format=8409, dPriv=<optimized out>) at dri_drawable.c:220
#15 0x000000304bacb3c3 in loadTexture (depth=24, size=..., pix=<optimized out>, this=0x1ea0b70) at /usr/src/
#16 KWin::GlxTextur
#17 0x000000304bac30d5 in KWin::SceneOpen
#18 0x000000304bac9a8e in KWin::SceneOpen
#19 0x000000304bac249f in KWin::SceneOpen
#20 0x000000304bac263d in KWin::SceneOpen
#21 0x000000304bad63a5 in KWin::EffectsHa
#22 0x000000304bab585a in KWin::Scene:
#23 0x000000304bad6627 in KWin::EffectsHa
#24 0x000000304bab841d in KWin::Scene:
#25 0x000000304bab774f in KWin::Scene:
In freedesktop.org Bugzilla #61182, D. Hugh Redelmeier (hugh-mimosa) wrote : | #33 |
Thanks, Knut, for bisecting in #27. Thanks, Stan, for confirming bisection in #28.
So the bad changeset is http://
I read that code (out of context: I'm not familiar with Xorg code). It kind of looked as if things with obvious allocation potential were followed by asserts to check that the allocation worked. So why are we observing SIGBUS rather than assertion errors? If allocation failure is possible, even assertion failure seems harsh (but at least more diagnostic).
In freedesktop.org Bugzilla #61182, agd5f (agd5f) wrote : | #34 |
(In reply to comment #32)
> Thanks, Knut, for bisecting in #27. Thanks, Stan, for confirming bisection
> in #28.
>
> So the bad changeset is
> http://
> ?id=35840ab1895
>
> I read that code (out of context: I'm not familiar with Xorg code). It kind
> of looked as if things with obvious allocation potential were followed by
> asserts to check that the allocation worked. So why are we observing SIGBUS
> rather than assertion errors? If allocation failure is possible, even
> assertion failure seems harsh (but at least more diagnostic).
As per comment 29, the MSAA surface is too big to be mapped by the CPU (the CPU's window into VRAM is only 256 MB). The allocation is successful, but the CPU is not able to map the buffer due to the limited window. You get a sigbus because the mapping fails and the CPU tries to access an address beyond the PCI aperture where vram is mapped. The solution is to either disable MSAA or as per comment 29, use the GPU to initialize the CMASK/HTILE buffers rather than using the CPU.
In freedesktop.org Bugzilla #61182, D. Hugh Redelmeier (hugh-mimosa) wrote : | #35 |
Thanks, Alex, for the clear restatement.
Naively, I think of two C/UNIX conventions. For allocations that can either succeed or fail, typically the result is a pointer which is NULL for failure -- eg. malloc(3)). For allocations that can partially succeed, the result is the amount successfully processed (think write(2) which returns the length actually transferred).
It seems to me that for allocating address space in the VRAM window (aperture?), success can partial, and anything that deals with that window needs to be aware that accessing some object may require piecewise operations, punctuated by adjustment of the mapping.
In other words, this case doesn't sound pathological; it should be handled as a normal case.
I'm not saying that comment #29 is wrong. I'm saying that the existing code ought to have been written to handle this case. Clearly one solution is to replace the code as suggested. But fixing the code ought to be feasible too. Are there other lurking bugs where code assumes addressability?
I reiterate: I'm not knowledgeable about modern video architectures or about X server architectures.
Footnote: Why do I think that VRAM windows cannot always map the whole VRAM? Because video cards now routinely have gigabytes of VRAM and 32-bit address spaces for x86 machines cannot spare enough to allocate for that much VRAM (ignoring PAE).
In freedesktop.org Bugzilla #61182, D. Hugh Redelmeier (hugh-mimosa) wrote : | #36 |
I finally am trying to set the GART size, as per Alex's comment #12.
Without setting it, Xorg0.log reports:
[ 15.054] (II) RADEON(0): mem size init: gart size :1fdef000 vram size: s:20000000 visible:1f020000
The default GART size is 512MiB, You'd think that would be a good match for the 512MiB video RAM on my card. This output shows that the GART size is reduced by a somewhat odd number (13^2 * 2^12).
When I set radeon.
[ 14.842] (II) RADEON(0): mem size init: gart size :3fdef000 vram size: s:20000000 visible:1f020000
Again, the GART size is reduced by the same amount.
Wait: according to http://
In freedesktop.org Bugzilla #61182, agd5f (agd5f) wrote : | #37 |
(In reply to comment #34)
> I'm not saying that comment #29 is wrong. I'm saying that the existing code
> ought to have been written to handle this case. Clearly one solution is to
> replace the code as suggested. But fixing the code ought to be feasible
> too. Are there other lurking bugs where code assumes addressability?
>
It's a bug that needs to be fixed.
In freedesktop.org Bugzilla #61182, agd5f (agd5f) wrote : | #38 |
(In reply to comment #35)
>
> Wait: according to http://
> enable the video card to access the computer's memory, not the other way
> around. So I don't see how this is relevant: we're getting a crash in a CPU
> instruction that is trying to access the video card's memory.
GART and VRAM are separate. As I said in comment 12, I though there may have been two issues at play at first, but upon further debugging, it appears to just be the vram window.
In freedesktop.org Bugzilla #61182, Niels Ole Salscheider (niels-ole) wrote : | #39 |
Created attachment 78307
dma_fill function
I considered to implement Marek's proposal by adding a dma_fill function that works analogously to dma_copy.
I need the context to call this function, though, and I do not know how to get it in r600_texture_
In freedesktop.org Bugzilla #61182, Marek Olšák (maraeo) wrote : | #40 |
BTW today I have implemented buffer clearing using streamout. I'll send my patches to mesa-dev later today. We can use DMA later for selected chipsets. (I assume there'll be some quirks with DMA)
In freedesktop.org Bugzilla #61182, D. Hugh Redelmeier (hugh-mimosa) wrote : | #41 |
Thanks, Neils, for the patch in comment #38.
Warning: the following comments are made with no understanding of X code.
"writting" should be "writing"
What is 0x000fffff? I would find the code clearer if this constant were given a name (RADEON_MAX_DMA?).
Why code
nfill = (size / 0x000fffff) + !!(size % 0x000fffff);
instead of the generally more efficient
nfill = (size+ 0x000fffff - 1) / 0x000fffff;
My guess: to avoid overflow. But if that is the case, then nfill should be uint64_t (like size), not just unsigned (which might be only 32 bits). Any case where the second statement might have an overflow problem would also be a problem with nfill being only unsigned 32.
If you know size is not 0, this is even better:
nfill = ((size - 1) / 0x000fffff) + 1;
If size can be 0, it is probably worth an early-out test to avoid bothering the GPU anyway:
if (size == 0) return 0;
I find code is easier to read if the scope of a variable is minimized. So I'd make the assignment to fsize also its declaration.
Have you created a patch to get these functions called in place of the currently broken code?
In freedesktop.org Bugzilla #61182, Niels Ole Salscheider (niels-ole) wrote : | #42 |
As I said before, the dma_fill function is based on dma_copy and I tried to keep the diff small. But you are right, this could be improved.
> Have you created a patch to get these functions called in place of the
> currently broken code?
I did but I was missing the context that is needed to call the dma_fill function.
You can try Marek's patches on the mailing list, they work well for me.
You can try to replace the call to util_blitter_
In freedesktop.org Bugzilla #61182, Glisse (glisse) wrote : | #43 |
As i said in comment 30 it's also a bug of kwin, kwin should not use msaa visual for everything ...
In freedesktop.org Bugzilla #61182, K6j-fdedria-zp0 (k6j-fdedria-zp0) wrote : | #44 |
(In reply to comment #42)
> As i said in comment 30 it's also a bug of kwin, kwin should not use msaa
> visual for everything ...
I've pushed a patch to the stable branch in KDE that should fix this issue.
In freedesktop.org Bugzilla #61182, D. Hugh Redelmeier (hugh-mimosa) wrote : | #45 |
Jerome Glisse in comment #30:
"Well this is also a kwin bug, kwin should not pick MSAA visual. I fixed cogl so that it does not pick msaa visual for gnome-shell."
Thanks!
I am (even today) experiencing gnome-shell crashes like this on an up-to-date fedora 18 (cogl-1.
What version of cogl should I look for? I can add something about this to the Fedora bug report.
In freedesktop.org Bugzilla #61182, Emil-l-velikov (emil-l-velikov) wrote : | #46 |
(In reply to comment #44)
> What version of cogl should I look for? I can add something about this to
> the Fedora bug report.
commit: 93b7b4c850dd928
Author: Jerome Glisse <email address hidden>
glx do not use multisample visual config for front or pixmap
There is no guaranty that glXGetFBConfigs will return fbconfig ordered
with non msaa config first. This patch make sure that non msaa config
get choose.
Present only in the master branch. Mind you I'm not a dev, but I've sent a request[1] to pull it the 1.12, 1.14 branches. Hope they will pick it up soon
Emil
[1] http://
In freedesktop.org Bugzilla #61182, Bugs-xorg (bugs-xorg) wrote : | #47 |
(In reply to comment #43)
> (In reply to comment #42)
> > As i said in comment 30 it's also a bug of kwin, kwin should not use msaa
> > visual for everything ...
>
> I've pushed a patch to the stable branch in KDE that should fix this issue.
Could you post a link to that patch?
Thank you.
In freedesktop.org Bugzilla #61182, K6j-fdedria-zp0 (k6j-fdedria-zp0) wrote : | #48 |
(In reply to comment #46)
> (In reply to comment #43)
> > I've pushed a patch to the stable branch in KDE that should fix this issue.
>
> Could you post a link to that patch?
http://
In freedesktop.org Bugzilla #61182, Marco Trevisan (Treviño) (3v1n0) wrote : | #49 |
Noticed the same issue in unity (compiz, actually) as soon as the opengl plugin is loaded.
It seems to happen mostly in multi-monitor: http://
In freedesktop.org Bugzilla #61182, agd5f (agd5f) wrote : | #50 |
Should be fixed in mesa master and 9.1 branch with the following commit:
http://
In freedesktop.org Bugzilla #61182, Marco Trevisan (Treviño) (3v1n0) wrote : | #51 |
(In reply to comment #48)
> Noticed the same issue in unity (compiz, actually) as soon as the opengl
> plugin is loaded.
>
> It seems to happen mostly in multi-monitor: http://
FYI, Compiz fix is in https:/
Changed in mesa (Ubuntu): | |
status: | New → Confirmed |
Changed in mesa: | |
importance: | Unknown → Medium |
status: | Unknown → Fix Released |
summary: |
- r600_dri.so crashes in r600_texture_create_object (memset) + (needs 9.1.3) r600_dri.so crashes in r600_texture_create_object (memset) |
Changed in mesa (Ubuntu): | |
status: | Confirmed → Triaged |
In freedesktop.org Bugzilla #61182, Nikoli (nikoli) wrote : | #52 |
This bug is not fixed, still happens with kwin-4.10.4 and mesa-9.1.4
https:/
https:/
In freedesktop.org Bugzilla #61182, agd5f (agd5f) wrote : | #53 |
(In reply to comment #51)
> This bug is not fixed, still happens with kwin-4.10.4 and mesa-9.1.4
> https:/
> https:/
I think you are hitting a different issue. Please open a new bug.
In freedesktop.org Bugzilla #61182, Nikoli (nikoli) wrote : | #54 |
Done, bug #67265
Timo Aaltonen (tjaalton) wrote : | #55 |
fixed some time ago
Changed in mesa (Ubuntu): | |
status: | Triaged → Fix Released |
Kwin crashes with current mesa and kernel 3.8. It does not crash with 3.7 kernel. With mesa 9.0.2 and kernel 3.8 kwin also works fine
#5 0x0000003647c892ab in __memset_sse2 () from /lib64/libc.so.6 create_ object (screen=0x980ca0, base=0x7fff208b 4770, pitch_in_ bytes_override= 0, buf=0x0, surface= 0x7fff208b3a80) at r600_texture.c:509 b4770) at r600_texture.c:601 create (screen=0x980ca0, templ=0x7fff208 b4770) at r600_resource.c:37 process_ buffers (drawable=0xc2b130, buffers=0x764460, buffer_count=1, atts=0x7fff208b 48b0, att_count=1) at dri2.c:254 textures (drawable=0xc2b130, statts= 0x7fff208b48b0, statts_count=1) at dri2.c:404 framebuffer_ validate (stfbi=0xc2b130, statts= 0x7fff208b48b0, count=1, out=0x0) at dri_drawable.c:81 validate_ att (drawable=0xc2b130, statt=ST_ ATTACHMENT_ FRONT_LEFT) at dri_drawable.c:206 geEXT (dpy=0x7d15f0, drawable=29360171, buffer=8414, attrib_list=0x0) at glxcmds.c:2370 e::loadTexture( unsigned long const&, QSize const&, int) () from /usr/lib64/ libkdeinit4_ kwin.so GL::Window: :bindTexture( ) () from /usr/lib64/ libkdeinit4_ kwin.so GL::Window: :performPaint( int, QRegion, KWin::WindowPai ntData) () from /usr/lib64/ libkdeinit4_ kwin.so GL2::performPai ntWindow( KWin::EffectWin dowImpl* , int, QRegion, KWin::WindowPai ntData& ) () from /usr/lib64/ libkdeinit4_ kwin.so GL2::finalDrawW indow(KWin: :EffectWindowIm pl*, int, QRegion, KWin::WindowPai ntData& ) () from /usr/lib64/ libkdeinit4_ kwin.so ndlerImpl: :drawWindow( KWin::EffectWin dow*, int, QRegion, KWin::WindowPai ntData& ) () from /usr/lib64/ libkdeinit4_ kwin.so :finalPaintWind ow(KWin: :EffectWindowIm pl*, int, QRegion, KWin::WindowPai ntData& ) () from /usr/lib64/ libkdeinit4_ kwin.so ndlerImpl: :paintWindow( KWin::EffectWin dow*, int, QRegion, KWin::WindowPai ntData& ) () from /usr/lib64/ libkdeinit4_ kwin.so :paintWindow( KWin::Scene: :Window* , int, QRegion, KWin::WindowQua dList) () from /usr/lib64/ libkdeinit4_ kwin.so :paintSimpleScr een(int, QRegion) () from /usr/lib64/ libkdeinit4_ kwin.so :finalPaintScre en(int, QRegion, KWin::ScreenPai ntData& ) () from /usr/lib64/ libkdeinit4_ kwin.so ndlerImpl: :paintScreen( int, QRegion, KWin::ScreenPai ntD...
#6 0x00007f5a8cbf6cf3 in r600_texture_
#7 0x00007f5a8cbf7339 in r600_texture_create (screen=0x980ca0, templ=0x7fff208
#8 0x00007f5a8cbdbae5 in r600_resource_
#9 0x00007f5a8cc1b4d2 in dri2_drawable_
#10 0x00007f5a8cc1b9b3 in dri2_allocate_
#11 0x00007f5a8cc19f0f in dri_st_
#12 0x00007f5a8cc1a30e in dri_drawable_
#13 0x00007f5a8cc1a35c in dri_set_tex_buffer2 (pDRICtx=0x8fef20, target=3553, format=8409, dPriv=0xbee5e0) at dri_drawable.c:220
#14 0x00007f5a9b82f590 in dri2_bind_tex_image (dpy=0x7d15f0, drawable=29360171, buffer=8414, attrib_list=0x0) at dri2_glx.c:1002
#15 0x00007f5a9b7f30f5 in __glXBindTexIma
#16 0x00007f5a9d1773c3 in KWin::GlxTextur
#17 0x00007f5a9d16f175 in KWin::SceneOpen
#18 0x00007f5a9d175a8e in KWin::SceneOpen
#19 0x00007f5a9d16e32f in KWin::SceneOpen
#20 0x00007f5a9d16e4cd in KWin::SceneOpen
#21 0x00007f5a9d1822b5 in KWin::EffectsHa
#22 0x00007f5a9d16178a in KWin::Scene:
#23 0x00007f5a9d182557 in KWin::EffectsHa
#24 0x00007f5a9d16434d in KWin::Scene:
#25 0x00007f5a9d16367f in KWin::Scene:
#26 0x00007f5a9d1616ce in KWin::Scene:
#27 0x00007f5a9d182720 in KWin::EffectsHa