[Dri-devel] when I had the choice ....
Hello, we are currently looking for the best graphics cards for linux and OpenGL. Can someone give me a hint which of the currently available cards are the best to use for extensive 3D applications in technical field (CAD, visualization of finite element data etc., no games). With regards Thomas Emmel -- Thomas Emmel ABAQUS Deutschland GmbH Theaterstr. 30-32 D-52062 Aachen Tel.: +49 241 474010 Fax:+49 241 4090963 E-Mail: [EMAIL PROTECTED] URL:http://www.abaqus.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] when I had the choice ....
On Thu, Oct 02, 2003 at 10:12:21AM +0200, Thomas Emmel wrote: Hello, we are currently looking for the best graphics cards for linux and OpenGL. Can someone give me a hint which of the currently available cards are the best to use for extensive 3D applications in technical field (CAD, visualization of finite element data etc., no games). Well, the best supported card with free driver would be any with the radeon R200 core (8500, 9000, 9100 and 9200). Newer radeon cards and nvidia stuff are only supported with the proprietary drivers, and there is proprietary servers for another bunch of high-end cards. I think 3Dlabs also announced linux support for their very high-end wildcat cards : http://www.3dlabs.com/whatsnew/pressreleases/pr03/03-07-09-linux.htm But they only provide binary rpms, so i suppose it is for whatever XFree86 Redhat 7.3 provides. Friendly, Sven Luther --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] dri hangs the pc (radeon 7000/VE, SiS645DX AGP)
I tried to get 3D graphichs, enabling the following kernel config options: CONFIG_AGP, CONFIG_AGP_SIS, CONFIG_DRM, CONFIG_DRM_RADEON I'm also using the radeon framebuffer driver and X with the appropriate driver. Unfortunately, any attempt to use 3D, such as glxgears, hangs the machine immediately. The mouse cursor stops and the keyboard is only useful for sysrq+B. (The other sysrq keys do nothing.) Is this an unsupported hw combination, or am I doing something wrong? I use debian testing and got opengl running on another machine with similiar software but a Intel BX chipset and a matrox G550. Helge Hafting lspci output: 00:00.0 Host bridge: Silicon Integrated Systems [SiS] SiS645DX Host Memory AGP Controller 00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS 530 Virtual PCI-to-PCI bridge (AGP) 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev 04) 00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016 00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] 00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] SiS7012 PCI Audio Accelerator (rev a0) 00:03.0 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB Controller (rev 0f) 00:03.1 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB Controller (rev 0f) 00:03.2 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB Controller (rev 0f) 00:03.3 USB Controller: Silicon Integrated Systems [SiS] SiS7002 USB 2.0 00:0b.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) 00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] glxinfo output: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa DRI Radeon 20010402 AGP 1x x86/MMX OpenGL version string: 1.2 Mesa 3.4.2 OpenGL extensions: GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_func_separate, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_MESA_window_pos, GL_MESA_resize_buffers, GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGIS_pixel_texture, GL_SGIS_texture_edge_clamp glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 Slow 0x25 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 Slow 0x29 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2a 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri hangs the pc (radeon 7000/VE, SiS645DX AGP)
Helge Hafting wrote: I tried to get 3D graphichs, enabling the following kernel config options: CONFIG_AGP, CONFIG_AGP_SIS, CONFIG_DRM, CONFIG_DRM_RADEON I'm also using the radeon framebuffer driver and X with the appropriate driver. Unfortunately, any attempt to use 3D, such as glxgears, hangs the machine immediately. The mouse cursor stops and the keyboard is only useful for sysrq+B. (The other sysrq keys do nothing.) Is this an unsupported hw combination, or am I doing something wrong? I use debian testing and got opengl running on another machine with similiar software but a Intel BX chipset and a matrox G550. Helge Hafting snip OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa DRI Radeon 20010402 AGP 1x x86/MMX OpenGL version string: 1.2 Mesa 3.4.2 I believe above lies your problem. You're using a 2 year old DRI build. I'm going out on a limb here, but try a snapshot (there are binary snapshots available at http://dri.sourceforge.net/snapshots/). This would be the latest DRM code. Get the Radeon snapshot. Basically, follow the instructions, and when you're finished, check that the OpenGL renderer string has changed to something more sane, like say Mesa DRI Radeon 20030926 AGP 1x x86/MMX/SSE... This brings up another point: With the modern drivers (once everything's functioning _properly_ -- do NOT do this before) you can set the AGP mode, as well as enabling page flipping. I'm not going to tell you how to do this; there's plenty of documentation out there, and it's not strictly necessary. Good luck! David Bronaugh --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri hangs the pc (radeon 7000/VE, SiS645DX AGP)
Helge Hafting wrote: I tried to get 3D graphichs, enabling the following kernel config options: CONFIG_AGP, CONFIG_AGP_SIS, CONFIG_DRM, CONFIG_DRM_RADEON I'm also using the radeon framebuffer driver and X with the appropriate driver. Unfortunately, any attempt to use 3D, such as glxgears, hangs the machine immediately. The mouse cursor stops and the keyboard is only useful for sysrq+B. (The other sysrq keys do nothing.) Is this an unsupported hw combination, or am I doing something wrong? I use debian testing and got opengl running on another machine with similiar software but a Intel BX chipset and a matrox G550. [snip] OpenGL version string: 1.2 Mesa 3.4.2 You have a really, really old version. Please try one of the more recent binary snapshots. They can be found under Downloads on http://dri.sourceforge.net/ . You'll need the most recent radeon-*.tar.bz2 and extras/XFree86.bz2. Make sure that CONFIG_DRM_RADEON build it as a module. The binary snapshot will replace the Radeon kernel module with a newer one. If CONFIG_DRM_RADEON built it into the kernel, it won't be updated. :) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] fixing pageflipping in mergedfb modes
I'm attempting to fix pageflipping in certain mergedfb modes. right now it only works in when crtc2 is right of crtc1. I suspect the problem has to do with the CRTC offsets that are set in RADEONDoAdjustFrame() for instance if I have crtc2 left of or above crtc1, I would need to adjust RADEON_CRTC_OFFSET by something like (crtc2_mode-CrtcHDisplay * crtc2_mode-CrtcVDisplay) right? and for clone mode, I'd have to adjust the offsets depending on the modes of each head. is my thinking right here? or does it work differently? Also, looking at radeon_dri.c, RADEONDRIFinishScreenInit() could we cap the 3D engine to 2048x2048 my adjusting the values of pRADEONDRI-width and pRADEONDRI-height? something like: if (pScrn-virtualX 2048) pRADEONDRI-width = 2048; else pRADEONDRI-width = pScrn-virtualX; if (pScrn-virtualY 2048) pRADEONDRI-width = 2048; else pRADEONDRI-width = pScrn-virtualY; Thanks, Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] when I had the choice ....
On Iau, 2003-10-02 at 12:46, Sven Luther wrote: radeon R200 core (8500, 9000, 9100 and 9200). Newer radeon cards and nvidia stuff are only supported with the proprietary drivers, and there is proprietary servers for another bunch of high-end cards. If you go with the binary cards with kernel modules (which for some kinds of workload you have too alas) also be aware that you will need to budget for a Motif license if you use any Motif applications as the OpenMotif shipped by Linux vendors is licensed solely for an Open Source OS. Not a big deal but its not obvious --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa 5.1-6.0
Keith Whitwell wrote: Alan Hourihane wrote: On Tue, Sep 30, 2003 at 11:02:13AM +0100, Alan Hourihane wrote: Is it worth moving the remaining DRI drivers into Mesa for the 6.0 release ? It seems as though mga, r128, r200 and radeon are already there. Actually, Do it this way we can fork the drivers for the Mesa 6.0 release and get them updated, while leaving the DRI tree at Mesa 5.0.2 ready for bug fixes to be merged back into XFree86 ready for a stable release of XFree86. That sounds good to me. Me too. I'll try to quickly wrap up and release 5.1 so it gets tested out by more people. Then, rev it to 6.0. That would be a good time to bring in the DRI stuff. -Brian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Savage 2D driver.
Hi, I've been working on the savage 2D driver because i was having problems with it. I checked the current 2D driver on CVS trunk and it worked just fine here and i decided to take it as a template and modified the driver on savage-1_0_0-branch and now it's working here and i decided to post a diff to get opinions from people here, specially if it worked for you (for those how has a video card with savage chip) and if i did the right thing or if there is something wrong with this diff. You can get the diff on http://www.max.brz.net/savage2D.patch. You should apply this diff on xc/xc/programs/Xserver/hw/xfree86/drivers of savage-1_0_0-branch with the command patch -p0 savage2D.patch and you must load agpgart module before running Xfree86. I'm looking forward for your answer so that i can continue working on the 3D driver. bye. Rafael Máximo --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Copyright stuff and junk (was Re: CVS Update: xc (branch: trunk))
Eric Anholt wrote: Log message: Add an MIT-style copyright, assigned to myself, to these files. I think I've touched enough of the code here, and there was no previous copyright. This reminds me, there are a few other files (lib/GL/dri/dri_util.c is one) that don't have any copyright message in them. I did the following and found 57 files: grep --exclude=Imakefile* -rLi copyright lib/GL |\ grep -v CVS Could people check that and add a copyright message to any files that they think belong to them. :) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] firstLevel / lastLevel calculation in R200 driver
A long time ago I promided to refactor the firstLevel / lastLevel calculation code from the various *SetTexImages routines. I have a patch that does this, and it follows the definition of how firstLevel lastLevel selection should work pretty closely. The only problem is that this does NOT grok with the way the R200 driver calculates it for GL_TEXTURE_3D. 3D textures are supposed to work just like 1D, 2D, and cubemap textures. However, the R200 driver picks baseLevel for firstLevel and lastLevel. Does this represent some limitation of the r200 hardware or was it just an oversight? I know that 3D textures are not currently hardware accelerated, but they will be someday. I don't want to put code in that will break when that happens. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri hangs the pc (radeon 7000/VE, SiS645DX AGP)
On Thu, 2003-10-02 at 18:27, Ian Romanick wrote: Helge Hafting wrote: OpenGL version string: 1.2 Mesa 3.4.2 You have a really, really old version. Please try one of the more recent binary snapshots. They can be found under Downloads on http://dri.sourceforge.net/ . You'll need the most recent radeon-*.tar.bz2 and extras/XFree86.bz2. Make sure that CONFIG_DRM_RADEON build it as a module. The binary snapshot will replace the Radeon kernel module with a newer one. If CONFIG_DRM_RADEON built it into the kernel, it won't be updated. :) Agreed, except that there's a more convenient way for Debian users. :) See http://dri.sourceforge.net/snapshots/README.Debian . -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri hangs the pc (radeon 7000/VE, SiS645DX AGP)
On Fri, Oct 03, 2003 at 02:31:57AM +0200, Michel Dänzer wrote: On Thu, 2003-10-02 at 18:27, Ian Romanick wrote: Helge Hafting wrote: OpenGL version string: 1.2 Mesa 3.4.2 You have a really, really old version. Please try one of the more recent binary snapshots. They can be found under Downloads on http://dri.sourceforge.net/ . You'll need the most recent radeon-*.tar.bz2 and extras/XFree86.bz2. Make sure that CONFIG_DRM_RADEON build it as a module. The binary snapshot will replace the Radeon kernel module with a newer one. If CONFIG_DRM_RADEON built it into the kernel, it won't be updated. :) Agreed, except that there's a more convenient way for Debian users. :) See http://dri.sourceforge.net/snapshots/README.Debian . oops, thats useful info to me... :) -solca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Deadlock with radeon DRI
On Thu, 2003-10-02 at 22:30, Keith Whitwell wrote:
Keith Whitwell wrote:
The problem seems to be that RADEONAdjustFrame() is designed to be
called from cursor handling routines that are executed outside the
Wakeup/Block handlers (perhaps this came in with SilkenMouse?) but is
being called during initialization after the point the lock is grabbed.
Actually, looking more closely at RADEONAdjustFrame(), I would guess that the
test of (info-CPStarted) is designed to avoid precisely this problem, right?
So I wonder why that's not working for you...
Me too, considering that it seems to be working for the vast majority of
people. Also, DRI{Lock,Unlock}() are designed to handle nested calls. It
seems the problem must be somewhere else, maybe it is a subtle
architecture difference after all?
--
Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Deadlock with radeon DRI
John Dennis wrote:
[Note: this is cross posted between dri-devel and [EMAIL PROTECTED] ]
I'm trying to debug a hung X server problem with DRI using the radeon
driver. Sources are XFree86 4.3.0. This happens to be on ia64, but at
the moment I don't see anything architecture specific about the problem.
The symptom of the problem is the following message from the drm
radeon kernel driver:
[drm:radeon_lock_take] *ERROR* x holds heavyweight lock
where x is a context id. I've tracked the sequence of events down to
the following:
DRIFinishScreenInit is called during the radeon driver initialization,
inside DRIFinishScreenInit is the following code snippet:
/* Now that we have created the X server's context, we can grab the
* hardware lock for the X server.
*/
DRILock(pScreen, 0);
pDRIPriv-grabbedDRILock = TRUE;
Slightly later on RADEONAdjustFrame is called and it does the following:
#ifdef XF86DRI
if (info-CPStarted) DRILock(pScrn-pScreen, 0);
#endif
Its this DRILock which is causing the *ERROR* x holds heavyweight
lock message. The reason is both DRIFinishScreenInit and
RADEONAdjustFrame are executing in the server and using the servers
DRI lock. DRIFinishScreenInit never unlocks, it sets the
grabbedDRILock flag, big deal, no one ever references this flag. When
RADEONAdjustFrame calls DRILock its already locked because
DRIFinishScreenInit locked and never unlocked. The dri kernel driver
on the second lock call then suspends the X server process
(DRM(lock_take) returns zero to DRM(lock) because the context holding
the lock and context requesting the lock are the same, this then
causes DRM(lock) to put the X server on the lock wait queue). Putting
the X server on the wait queue waiting for the lock to be released
then deadlocks the X server because its the process holding the lock
on its context.
Questions:
The whole crux of the problem seems to me the taking and holding of
the lock in DRIFinishScreenInit. Why is this being done?
It is done because the X server expects to be holding the lock whenever it is
between the Wakeup Block handlers. The odd man out in this case is when the
server first starts up, it won't have aquired the lock coming in through the
Wakeup handler. So, it gets aquired at this point.
The rest of the DRI initialization code needs to be holding the lock, so we
have to grab it somewhere.
The problem seems to be that RADEONAdjustFrame() is designed to be called from
cursor handling routines that are executed outside the Wakeup/Block handlers
(perhaps this came in with SilkenMouse?) but is being called during
initialization after the point the lock is grabbed.
I haven't deeply investigated this but two solutions spring to mind:
- Hack: Move the call to RADEONAdjustFrame() during initialization to before
the lock is grabbed.
- Better: Replace the call to RADEONAdjustFrame() during initialization with
something like:
if (info-FBDev) {
fbdevHWAdjustFrame(scrnIndex, x, y, flags);
} else {
RADEONDoAdjustFrame(pScrn, x, y, FALSE);
}
which is basically what RADEONAdjustFrame() wraps.
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Deadlock with radeon DRI
Keith Whitwell wrote:
I haven't deeply investigated this but two solutions spring to mind:
- Hack: Move the call to RADEONAdjustFrame() during initialization
to before the lock is grabbed.
- Better: Replace the call to RADEONAdjustFrame() during
initialization with something like:
if (info-FBDev) {
fbdevHWAdjustFrame(scrnIndex, x, y, flags);
} else {
RADEONDoAdjustFrame(pScrn, x, y, FALSE);
}
which is basically what RADEONAdjustFrame() wraps.
That seems like the right way to go, but I'd feel better if the body of
RADEONAdjectFrame was moved to a new function called
RADEONAdjectFrameLocked. RADEONAdjectFrame would just lock, call
RADEONAdjectFrameLocked, and unlock. That matches what's been done
elsewhere in the 3D driver, anyway.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Deadlock with radeon DRI
Keith Whitwell wrote: John Dennis wrote: [Note: this is cross posted between dri-devel and [EMAIL PROTECTED] ] I'm trying to debug a hung X server problem with DRI using the radeon driver. Sources are XFree86 4.3.0. This happens to be on ia64, but at the moment I don't see anything architecture specific about the problem. The symptom of the problem is the following message from the drm radeon kernel driver: [drm:radeon_lock_take] *ERROR* x holds heavyweight lock where x is a context id. I've tracked the sequence of events down to the following: DRIFinishScreenInit is called during the radeon driver initialization, inside DRIFinishScreenInit is the following code snippet: /* Now that we have created the X server's context, we can grab the * hardware lock for the X server. */ DRILock(pScreen, 0); pDRIPriv-grabbedDRILock = TRUE; Slightly later on RADEONAdjustFrame is called and it does the following: #ifdef XF86DRI if (info-CPStarted) DRILock(pScrn-pScreen, 0); #endif Its this DRILock which is causing the *ERROR* x holds heavyweight lock message. The reason is both DRIFinishScreenInit and RADEONAdjustFrame are executing in the server and using the servers DRI lock. DRIFinishScreenInit never unlocks, it sets the grabbedDRILock flag, big deal, no one ever references this flag. When RADEONAdjustFrame calls DRILock its already locked because DRIFinishScreenInit locked and never unlocked. The dri kernel driver on the second lock call then suspends the X server process (DRM(lock_take) returns zero to DRM(lock) because the context holding the lock and context requesting the lock are the same, this then causes DRM(lock) to put the X server on the lock wait queue). Putting the X server on the wait queue waiting for the lock to be released then deadlocks the X server because its the process holding the lock on its context. Questions: The whole crux of the problem seems to me the taking and holding of the lock in DRIFinishScreenInit. Why is this being done? It is done because the X server expects to be holding the lock whenever it is between the Wakeup Block handlers. The odd man out in this case is when the server first starts up, it won't have aquired the lock coming in through the Wakeup handler. So, it gets aquired at this point. The rest of the DRI initialization code needs to be holding the lock, so we have to grab it somewhere. The problem seems to be that RADEONAdjustFrame() is designed to be called from cursor handling routines that are executed outside the Wakeup/Block handlers (perhaps this came in with SilkenMouse?) but is being called during initialization after the point the lock is grabbed. Actually, looking more closely at RADEONAdjustFrame(), I would guess that the test of (info-CPStarted) is designed to avoid precisely this problem, right? So I wonder why that's not working for you... Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Deadlock with radeon DRI
[Note: this is cross posted between dri-devel and [EMAIL PROTECTED] ] I'm trying to debug a hung X server problem with DRI using the radeon driver. Sources are XFree86 4.3.0. This happens to be on ia64, but at the moment I don't see anything architecture specific about the problem. The symptom of the problem is the following message from the drm radeon kernel driver: [drm:radeon_lock_take] *ERROR* x holds heavyweight lock where x is a context id. I've tracked the sequence of events down to the following: DRIFinishScreenInit is called during the radeon driver initialization, inside DRIFinishScreenInit is the following code snippet: /* Now that we have created the X server's context, we can grab the * hardware lock for the X server. */ DRILock(pScreen, 0); pDRIPriv-grabbedDRILock = TRUE; Slightly later on RADEONAdjustFrame is called and it does the following: #ifdef XF86DRI if (info-CPStarted) DRILock(pScrn-pScreen, 0); #endif Its this DRILock which is causing the *ERROR* x holds heavyweight lock message. The reason is both DRIFinishScreenInit and RADEONAdjustFrame are executing in the server and using the servers DRI lock. DRIFinishScreenInit never unlocks, it sets the grabbedDRILock flag, big deal, no one ever references this flag. When RADEONAdjustFrame calls DRILock its already locked because DRIFinishScreenInit locked and never unlocked. The dri kernel driver on the second lock call then suspends the X server process (DRM(lock_take) returns zero to DRM(lock) because the context holding the lock and context requesting the lock are the same, this then causes DRM(lock) to put the X server on the lock wait queue). Putting the X server on the wait queue waiting for the lock to be released then deadlocks the X server because its the process holding the lock on its context. Questions: The whole crux of the problem seems to me the taking and holding of the lock in DRIFinishScreenInit. Why is this being done? I can't see a reason for it. Why does it set a flag indicating its holding the lock if nobody examines that flag? Is suspending a process that already holds a lock during a lock request really the right behavior? Granted, a process thats trying to lock twice without an intervening unlock is broken, but do we really want to deadlock that process? Any other insights to this issue? FWIW, I googled for this error and came up with several folks who starting around last spring started seeing the same problem, but none of the mail threads had a follow up solution. Thanks, John --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
