Re: [R300 and other radeons] MergedFB lockups
On Sun, Feb 20, 2005 at 12:00:10PM +1100, Benjamin Herrenschmidt wrote:
On Sat, 2005-02-19 at 11:23 +0100, Philipp Klaus Krause wrote:
Well my rv250 lockups occour only during mouse movement in fullscreen
applications. But for month ago there were no lockups. The situation
was slowly getting worse since. With current DRM and Mesa driver I
get an immediate lockup in gl-117 when moving the mouse. If I use
current DRM with an older Mesa it locks up after about a minute of mouse
movement.
rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel
(well, actually, all of the above are about 5 days old, doesn't have
Vladimir latest fixes), I get very jerky display with g117 and broken
textures, ultimately it locks up after moving the mouse a little bit (at
the meny screen).
I can kill X tho, that works, so the chip/bus isn't totally dead (or it
recovers with an engine reset).
Fwiw, gl-117 locks up almost immediately (goes fullscreen, puts
Please wait {or something like that} up, then hangs) for me on my
rv280 (Radeon 9200SE).
This is with the nixnuts Debian dri packages, so dri CVS from
2005-02-08 or so.
cheers,
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Sun, Feb 20, 2005 at 12:00:10PM +1100, Benjamin Herrenschmidt wrote:
On Sat, 2005-02-19 at 11:23 +0100, Philipp Klaus Krause wrote:
Well my rv250 lockups occour only during mouse movement in fullscreen
applications. But for month ago there were no lockups. The situation
was slowly getting worse since. With current DRM and Mesa driver I
get an immediate lockup in gl-117 when moving the mouse. If I use
current DRM with an older Mesa it locks up after about a minute of mouse
movement.
rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel
(well, actually, all of the above are about 5 days old, doesn't have
Vladimir latest fixes), I get very jerky display with g117 and broken
textures, ultimately it locks up after moving the mouse a little bit (at
the meny screen).
I can kill X tho, that works, so the chip/bus isn't totally dead (or it
recovers with an engine reset).
Fwiw, gl-117 locks up almost immediately (goes fullscreen, puts
Please wait {or something like that} up, then hangs) for me on my
rv280 (Radeon 9200SE).
This is with the nixnuts Debian dri packages, so dri CVS from
2005-02-08 or so.
cheers,
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
Vladimir Dergachev wrote: [snip] Interesting :) Could you try this with latest X.org source ? Also, what is gl-117 ? OpenGL flight simulator. Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Fri, 18 Feb 2005 20:06:53 -0500 (EST), Vladimir Dergachev [EMAIL PROTECTED] wrote: I think I found the cause of lockups in VB mode - they were due to cursor updating function in radeon_mergedfb.c calling OUTREGP() which in turn called INREG. When silken mouse is enabled this function could be called at any time which would do *bad* things when CP engine is active. The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. I have *no* idea why this worked with immediate mode at all and why no issues were reported by R200 and Radeon users (well, I only looked through the mailing lists, perhaps there is something on bugzilla but I don't know how to use that efficiently) I've never had any reports of this kind that I can think of for radeon or r200. Also, I have no idea why the code in radeon_cursor.c that writes images directly into framebuffer memory works - according to the manual any writes into framebuffer while GUI is active should cause a hard lock. However, I could not produce any lockups with it, and so left it as is. Does using the overlay also cause a lockup? there are some non-idled INREGs in there as well. I've never had a problem with them on r100 or r200 though. Alex --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
Vladimir Dergachev schrieb: I think I found the cause of lockups in VB mode - they were due to cursor updating function in radeon_mergedfb.c calling OUTREGP() which in turn called INREG. When silken mouse is enabled this function could be called at any time which would do *bad* things when CP engine is active. The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. I have *no* idea why this worked with immediate mode at all and why no issues were reported by R200 and Radeon users (well, I only looked through the mailing lists, perhaps there is something on bugzilla but I don't know how to use that efficiently) Well my rv250 lockups occour only during mouse movement in fullscreen applications. But for month ago there were no lockups. The situation was slowly getting worse since. With current DRM and Mesa driver I get an immediate lockup in gl-117 when moving the mouse. If I use current DRM with an older Mesa it locks up after about a minute of mouse movement. Philipp --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
Also, I have no idea why the code in radeon_cursor.c that writes images directly into framebuffer memory works - according to the manual any writes into framebuffer while GUI is active should cause a hard lock. However, I could not produce any lockups with it, and so left it as is. Does using the overlay also cause a lockup? there are some non-idled INREGs in there as well. I've never had a problem with them on r100 or r200 though. Not anymore, I think I fixed all of those when importing GATOS code a while back. best Vladimir Dergachev Alex --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. I have *no* idea why this worked with immediate mode at all and why no issues were reported by R200 and Radeon users (well, I only looked through the mailing lists, perhaps there is something on bugzilla but I don't know how to use that efficiently) Well my rv250 lockups occour only during mouse movement in fullscreen applications. But for month ago there were no lockups. The situation was slowly getting worse since. With current DRM and Mesa driver I get an immediate lockup in gl-117 when moving the mouse. If I use current DRM with an older Mesa it locks up after about a minute of mouse movement. Interesting :) Could you try this with latest X.org source ? Also, what is gl-117 ? thank you Vladimir Dergachev Philipp --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
Vladimir Dergachev schrieb: Interesting :) Could you try this with latest X.org source ? Sorry, but I probably won't find much time. I'll be away from the rv250 during the next week. Next month I'll have to write some exams, while at the beginning of april there are oral exams. I hope to find more time for DRI testing at the beginning of the next term. Also, what is gl-117 ? It's a free flight simulator, included in Debian. Philipp --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Sat, 19 Feb 2005 09:56:33 -0500 (EST), Vladimir Dergachev [EMAIL PROTECTED] wrote: Also, I have no idea why the code in radeon_cursor.c that writes images directly into framebuffer memory works - according to the manual any writes into framebuffer while GUI is active should cause a hard lock. However, I could not produce any lockups with it, and so left it as is. Does using the overlay also cause a lockup? there are some non-idled INREGs in there as well. I've never had a problem with them on r100 or r200 though. Not anymore, I think I fixed all of those when importing GATOS code a while back. there's still one is the overlay gamma setup function, and I think another one further down. I can add the idle calls at some point this weekend unless someone beats me to it. Alex best Vladimir Dergachev Alex --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Sat, 19 Feb 2005, Alex Deucher wrote: On Sat, 19 Feb 2005 09:56:33 -0500 (EST), Vladimir Dergachev [EMAIL PROTECTED] wrote: Also, I have no idea why the code in radeon_cursor.c that writes images directly into framebuffer memory works - according to the manual any writes into framebuffer while GUI is active should cause a hard lock. However, I could not produce any lockups with it, and so left it as is. Does using the overlay also cause a lockup? there are some non-idled INREGs in there as well. I've never had a problem with them on r100 or r200 though. Not anymore, I think I fixed all of those when importing GATOS code a while back. there's still one is the overlay gamma setup function, and I think another one further down. I can add the idle calls at some point this weekend unless someone beats me to it. Ohh I see - these are triggerred only by changing Xv attributes and I don't think many people do this simultaneously with running 3d. I fixed it, no problem. best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Sat, 2005-02-19 at 11:23 +0100, Philipp Klaus Krause wrote: Vladimir Dergachev schrieb: I think I found the cause of lockups in VB mode - they were due to cursor updating function in radeon_mergedfb.c calling OUTREGP() which in turn called INREG. When silken mouse is enabled this function could be called at any time which would do *bad* things when CP engine is active. The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. I have *no* idea why this worked with immediate mode at all and why no issues were reported by R200 and Radeon users (well, I only looked through the mailing lists, perhaps there is something on bugzilla but I don't know how to use that efficiently) Well my rv250 lockups occour only during mouse movement in fullscreen applications. But for month ago there were no lockups. The situation was slowly getting worse since. With current DRM and Mesa driver I get an immediate lockup in gl-117 when moving the mouse. If I use current DRM with an older Mesa it locks up after about a minute of mouse movement. rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel (well, actually, all of the above are about 5 days old, doesn't have Vladimir latest fixes), I get very jerky display with g117 and broken textures, ultimately it locks up after moving the mouse a little bit (at the meny screen). I can kill X tho, that works, so the chip/bus isn't totally dead (or it recovers with an engine reset). Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Saturday 19 February 2005 02:06, Vladimir Dergachev wrote: I think I found the cause of lockups in VB mode - they were due to cursor updating function in radeon_mergedfb.c calling OUTREGP() which in turn called INREG. When silken mouse is enabled this function could be called at any time which would do *bad* things when CP engine is active. The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. I have *no* idea why this worked with immediate mode at all and why no issues were reported by R200 and Radeon users (well, I only looked through the mailing lists, perhaps there is something on bugzilla but I don't know how to use that efficiently) Also, I have no idea why the code in radeon_cursor.c that writes images directly into framebuffer memory works - according to the manual any writes into framebuffer while GUI is active should cause a hard lock. However, I could not produce any lockups with it, and so left it as is. I can see no difference at all with this latest change, i.e. no regressions, but the lockup is still there. cu, Nicolai best Vladimir Dergachev pgpwdAI9btdc8.pgp Description: PGP signature
Re: [R300 and other radeons] MergedFB lockups
Also, I have no idea why the code in radeon_cursor.c that writes images directly into framebuffer memory works - according to the manual any writes into framebuffer while GUI is active should cause a hard lock. However, I could not produce any lockups with it, and so left it as is. I can see no difference at all with this latest change, i.e. no regressions, but the lockup is still there. I think we can safely assume that there is more than one issue. For example, I am often seeing about 2-sec delay upon the start of a GL app (all 2d updates are frozen). The delay always happens upon the first GL context after a cold reboot, and it is often not present on successive launches of GL apps. I just tried to check for partly covered window lockup bug - glxgears appears to be entirely indifferent to whether anything is covering it. As for gl-117 - I just tried it and it segfaults due to undefined functions to handle vertex buffers. best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
get an immediate lockup in gl-117 when moving the mouse. If I use current DRM with an older Mesa it locks up after about a minute of mouse movement. rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel (well, actually, all of the above are about 5 days old, doesn't have Vladimir latest fixes), I get very jerky display with g117 and broken textures, ultimately it locks up after moving the mouse a little bit (at the meny screen). Is it a hard lockup ? With R300 it segfaults when I move a mouse due to vertex arrays code not written yet, however it is strange this happens only after a mouse movement. It could be that it tramples over some Mesa driver memory (or there is a bug in Mesa driver/library). best Vladimir Dergachev I can kill X tho, that works, so the chip/bus isn't totally dead (or it recovers with an engine reset). Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Sat, 2005-02-19 at 23:22 -0500, Vladimir Dergachev wrote: [...] For example, I am often seeing about 2-sec delay upon the start of a GL app (all 2d updates are frozen). The delay always happens upon the first GL context after a cold reboot, and it is often not present on successive launches of GL apps. I see this on my R200 on amd64, as well. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Sat, 19 Feb 2005, Vladimir Dergachev wrote: get an immediate lockup in gl-117 when moving the mouse. If I use current DRM with an older Mesa it locks up after about a minute of mouse movement. rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel (well, actually, all of the above are about 5 days old, doesn't have Vladimir latest fixes), I get very jerky display with g117 and broken textures, ultimately it locks up after moving the mouse a little bit (at the meny screen). Is it a hard lockup ? With R300 it segfaults when I move a mouse due to vertex arrays code not written yet, however it is strange this happens only after a mouse movement. One more thing: go to ~/.gl-117 and edit the file conf to turn off full screen mode. Reduce the resolution to something small (like 640x480). Now you would be able to run it under debugger and see where it segfaults. I am curious to see where the problem is in rv250 driver. best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Sat, 19 Feb 2005, Eric Anholt wrote: On Sat, 2005-02-19 at 23:22 -0500, Vladimir Dergachev wrote: [...] For example, I am often seeing about 2-sec delay upon the start of a GL app (all 2d updates are frozen). The delay always happens upon the first GL context after a cold reboot, and it is often not present on successive launches of GL apps. I see this on my R200 on amd64, as well. Really ? Do you have DynamicClocks on ? Do you have ACPI in the kernel ? I have no idea what could have caused such a delay, as microcode has long been loaded by then. best Vladimir Dergachev -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Sat, 2005-02-19 at 23:25 -0500, Vladimir Dergachev wrote: get an immediate lockup in gl-117 when moving the mouse. If I use current DRM with an older Mesa it locks up after about a minute of mouse movement. rv250 here, CVS HEAD X.org, Meas CVS Head DRI driver, current bk kernel (well, actually, all of the above are about 5 days old, doesn't have Vladimir latest fixes), I get very jerky display with g117 and broken textures, ultimately it locks up after moving the mouse a little bit (at the meny screen). Is it a hard lockup ? With R300 it segfaults when I move a mouse due to vertex arrays code not written yet, however it is strange this happens only after a mouse movement. It could be that it tramples over some Mesa driver memory (or there is a bug in Mesa driver/library). Well, difficult to say, I didn't manage to get back to X, but I managed to kill X and radeonfb managed to restore the display, at which point I could re-launch X... best Vladimir Dergachev I can kill X tho, that works, so the chip/bus isn't totally dead (or it recovers with an engine reset). Ben. -- Benjamin Herrenschmidt [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300 and other radeons] MergedFB lockups
I think I found the cause of lockups in VB mode - they were due to cursor updating function in radeon_mergedfb.c calling OUTREGP() which in turn called INREG. When silken mouse is enabled this function could be called at any time which would do *bad* things when CP engine is active. The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. I have *no* idea why this worked with immediate mode at all and why no issues were reported by R200 and Radeon users (well, I only looked through the mailing lists, perhaps there is something on bugzilla but I don't know how to use that efficiently) Also, I have no idea why the code in radeon_cursor.c that writes images directly into framebuffer memory works - according to the manual any writes into framebuffer while GUI is active should cause a hard lock. However, I could not produce any lockups with it, and so left it as is. best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
On Fri, 18 Feb 2005, Vladimir Dergachev wrote: I think I found the cause of lockups in VB mode - they were due to cursor updating function in radeon_mergedfb.c calling OUTREGP() which in turn called INREG. Forgot to add: 1. the fix is in X.org CVS, if you are running R300 + merged fb I recommend to update the driver 2. VB mode also needs the fix from Nicolai Haehnle that was committed to R300 CVS earlier. I tested with glxgears and quake3a - no lockups so far, even on crossing window boundaries. best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300 and other radeons] MergedFB lockups
Vladimir Dergachev wrote: On Fri, 18 Feb 2005, Vladimir Dergachev wrote: I think I found the cause of lockups in VB mode - they were due to cursor updating function in radeon_mergedfb.c calling OUTREGP() which in turn called INREG. Forgot to add: 1. the fix is in X.org CVS, if you are running R300 + merged fb I recommend to update the driver 2. VB mode also needs the fix from Nicolai Haehnle that was committed to R300 CVS earlier. I tested with glxgears and quake3a - no lockups so far, even on crossing window boundaries. best Vladimir Dergachev Well that would definitely explain my lockups... I'll give it a shot later this weekend. Adam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
