Frank de Lange | 1 Aug 21:06 2008

Status of the well-known savageGetLock() and related viaGetLock() crash?

Hi'all,

Is there any progress on solving the savageGetLock() (and most likely
related viaGetLock()) crash? This bug has been haunting savage and via
users for a long time now. My otherwise trusty Thinkpad T23's crash and
burn whenever some program tries to destroy a GL context. In free
software this can generally be circumvented by refraining from
destroying the context until the program closes, but in close
source/proprietary stuff (think Pro/E etc.) this is not possible.

For reference, I'm talking about these bugs:

https://launchpad.net/bugs/81889
https://launchpad.net/bugs/90850
https://lists.ubuntu.com/archives/ubuntu-mono/2007-September/008219.html
http://bugs.freedesktop.org/show_bug.cgi?id=10191
http://www.google.se/search?q=savageGetLock+OR+viaGetLock+segfault+OR+crash
etc...

I have not hacked any dri stuff so it would take me some time to get up
to snuff wrt these drivers. If there are no takers I'd be willing and
hopefully able to give it a go but in that case I'd like some pointers
in the right direction. Someone somewhere surely has wondered about
these segfaults before... right?

Cheers//Frank

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
(Continue reading)

bugzilla-daemon | 2 Aug 13:43 2008

[Bug 16959] New: Xorg crash when delete_renderbuffer_cb is called

http://bugs.freedesktop.org/show_bug.cgi?id=16959

           Summary: Xorg crash when delete_renderbuffer_cb is called
           Product: Mesa
           Version: 7.0.3
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: critical
          Priority: high
         Component: Mesa core
        AssignedTo: mesa3d-dev <at> lists.sourceforge.net
        ReportedBy: bsdmaniak <at> gmail.com

Created an attachment (id=18077)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=18077)
Fix for this bug

gdb Xorg backtrace :
#0  0x00000000 in ?? ()
#1  0x08a8b2cc in delete_renderbuffer_cb () 
from /usr/X11R6/lib/modules/extensions/libGLcore.so
#2  0x08ac0c34 in _mesa_HashDeleteAll () 
from /usr/X11R6/lib/modules/extensions/libGLcore.so
#3  0x08a8b3e2 in free_shared_state () 
from /usr/X11R6/lib/modules/extensions/libGLcore.so
#4  0x08a8bd5e in _mesa_free_context_data () 
from /usr/X11R6/lib/modules/extensions/libGLcore.so
#5  0x08bb707d in XMesaDestroyContext () 
from /usr/X11R6/lib/modules/extensions/libGLcore.so
(Continue reading)

Stephane Marchesin | 2 Aug 19:40 2008
Picon
Picon

Re: [PATCH] Gallium-0.1 Softpipe PIPE_FORMAT_R16_SNORM

On 7/30/08, Younes Manton <younes.m <at> gmail.com> wrote:
> I needed this to test some XvMC related stuff.
>

Looks good, I applied it.

Stephane

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
bugzilla-daemon | 2 Aug 21:24 2008

[Bug 16959] Xorg crash when delete_renderbuffer_cb is called

http://bugs.freedesktop.org/show_bug.cgi?id=16959

Azwaw OUSADOU <bsdmaniak <at> gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Nicolai Hähnle | 3 Aug 00:40 2008
Picon

Yet another r300 memory management tree

Hi there,

seeing as lacking a memory manager is a pretty frustrating state of mind, I 
thought I'd explore this area a bit.

My goals are:
- bring the r300_dri driver into a state that is more compatible with a proper 
in-kernel memory manager,
- do so with as little breakage as possible, and
- do so without changes to DRM or DDX (binary compatibility and all that)
Basically, I want to have a development tree that is in almost-perfect 
condition almost all the time while moving towards memory management.

My tree is here: http://cgit.freedesktop.org/~nh/mesa/ (on the master branch)

Some comments about this tree:
1. I decided not to use an approach based on dri_bufmgr_fake yet. Instead, I 
based the bufmgr on the existing r300_mem which uses the RADEON_ALLOC/etc. 
ioctls to allocate buffers for DMA.

2. Textures are still handled in the old way - they will require 
dri_bufmgr_fake-like handling, probably more like airlied's approach.

3. The tree contains a lot of patches to unify the way command buffer emits 
are done. Basically, I introduced macros BEGIN_BATCH/OUT_BATCH/etc. similar 
to what we have in the DRM and the DDX - hopefully, this will reduce 
confusion for new people.
There's a new macro called COMMIT_BATCH. The idea behind this macro is that 
BEGIN_BATCH can flush the command buffer at times where we really don't want 
the command buffer to be flushed (flushing between certain kinds of packet3 
(Continue reading)

bugzilla-daemon | 3 Aug 19:14 2008

[Bug 16959] Xorg crash when delete_renderbuffer_cb is called

http://bugs.freedesktop.org/show_bug.cgi?id=16959

--- Comment #1 from Brian Paul <brian.paul <at> tungstengraphics.com>  2008-08-03 10:14:33 PST ---
fix commited to git. thanks.

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
bugzilla-daemon | 3 Aug 19:20 2008

[Bug 16959] Xorg crash when delete_renderbuffer_cb is called

http://bugs.freedesktop.org/show_bug.cgi?id=16959

Azwaw OUSADOU <bsdmaniak <at> gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Nicolai Hähnle | 4 Aug 01:48 2008
Picon

Re: Yet another r300 memory management tree

P.S.: Sorry to the list admins for repeatedly sending this from the wrong 
account...

Am Sonntag 03 August 2008 00:40:30 schrieb Nicolai Hähnle:
> Hi there,
>
> seeing as lacking a memory manager is a pretty frustrating state of mind, I
> thought I'd explore this area a bit.
>
> My goals are:
> - bring the r300_dri driver into a state that is more compatible with a
> proper in-kernel memory manager,
> - do so with as little breakage as possible, and
> - do so without changes to DRM or DDX (binary compatibility and all that)
> Basically, I want to have a development tree that is in almost-perfect
> condition almost all the time while moving towards memory management.
>
> My tree is here: http://cgit.freedesktop.org/~nh/mesa/ (on the master
> branch)

I've pushed some more work. The tree builds together with the standard 
mesa/drm master. Basic things work (i.e. an arbitrary sample of piglit tests, 
openarena, nexuiz, glxgears).

In the current version, textures are now managed via the bufmgr. It's not 
exactly efficient yet, as there will be three copies of texture data in 
memory (one for Mesa, one for bufmgr backing store, and one in vram). This 
can be dealt with by taking even more ideas from the Intel driver.

My bufmgr allocates blocks in vram by wrapping the old dri/common/texmem.c 
(Continue reading)

Roland Scheidegger | 4 Aug 14:51 2008

Re: Yet another r300 memory management tree

On 03.08.2008 00:40, Nicolai Hähnle wrote:
> Hi there,
> 
> seeing as lacking a memory manager is a pretty frustrating state of mind, I 
> thought I'd explore this area a bit.
> 
> My goals are:
> - bring the r300_dri driver into a state that is more compatible with a proper 
> in-kernel memory manager,
> - do so with as little breakage as possible, and
> - do so without changes to DRM or DDX (binary compatibility and all that)
> Basically, I want to have a development tree that is in almost-perfect 
> condition almost all the time while moving towards memory management.
> 
> My tree is here: http://cgit.freedesktop.org/~nh/mesa/ (on the master branch)
> 
> Some comments about this tree:
> 1. I decided not to use an approach based on dri_bufmgr_fake yet. Instead, I 
> based the bufmgr on the existing r300_mem which uses the RADEON_ALLOC/etc. 
> ioctls to allocate buffers for DMA.
> 
> 2. Textures are still handled in the old way - they will require 
> dri_bufmgr_fake-like handling, probably more like airlied's approach.
> 
> 3. The tree contains a lot of patches to unify the way command buffer emits 
> are done. Basically, I introduced macros BEGIN_BATCH/OUT_BATCH/etc. similar 
> to what we have in the DRM and the DDX - hopefully, this will reduce 
> confusion for new people.
> There's a new macro called COMMIT_BATCH. The idea behind this macro is that 
> BEGIN_BATCH can flush the command buffer at times where we really don't want 
(Continue reading)

Nicolai Hähnle | 4 Aug 15:05 2008
Picon

Re: Yet another r300 memory management tree

Am Montag 04 August 2008 14:51:37 schrieb Roland Scheidegger:
> On 03.08.2008 00:40, Nicolai Hähnle wrote:
> > Hi there,
> >
> > seeing as lacking a memory manager is a pretty frustrating state of mind,
> > I thought I'd explore this area a bit.
> >
> > My goals are:
> > - bring the r300_dri driver into a state that is more compatible with a
> > proper in-kernel memory manager,
> > - do so with as little breakage as possible, and
> > - do so without changes to DRM or DDX (binary compatibility and all that)
> > Basically, I want to have a development tree that is in almost-perfect
> > condition almost all the time while moving towards memory management.
> >
> > My tree is here: http://cgit.freedesktop.org/~nh/mesa/ (on the master
> > branch)
> >
> > Some comments about this tree:
> > 1. I decided not to use an approach based on dri_bufmgr_fake yet.
> > Instead, I based the bufmgr on the existing r300_mem which uses the
> > RADEON_ALLOC/etc. ioctls to allocate buffers for DMA.
> >
> > 2. Textures are still handled in the old way - they will require
> > dri_bufmgr_fake-like handling, probably more like airlied's approach.
> >
> > 3. The tree contains a lot of patches to unify the way command buffer
> > emits are done. Basically, I introduced macros BEGIN_BATCH/OUT_BATCH/etc.
> > similar to what we have in the DRM and the DDX - hopefully, this will
> > reduce confusion for new people.
(Continue reading)


Gmane