[Dri-devel] Compilation on FreeBSD 5.0
Hi! I have FreeBSD 5.0-RELEASE. I can't compile DRI CVS. I got this error: making all in lib/GL/GL... rm -f libGL.so.1.2~ + cd . + LD_LIBRARY_PATH=../../../exports/lib cc -o ./libGL.so.1.2~ -shared -rpath /usr /X11R6/lib -Wl,-soname,libGL.so.1 ../../../lib/GL/glx/clientattrib.o ../../../li b/GL/glx/compsize.o ../../../lib/GL/glx/dispatch.o ../../../lib/GL/glx/eval.o .. /../../lib/GL/glx/g_render.o ../../../lib/GL/glx/g_single.o ../../../lib/GL/glx/ g_vendpriv.o ../../../lib/GL/glx/glapi.o ../../../lib/GL/glx/glapi_x86.o ../../. ./lib/GL/glx/glthread.o ../../../lib/GL/glx/glxcmds.o ../../../lib/GL/glx/glxext .o ../../../lib/GL/glx/indirect_init.o ../../../lib/GL/glx/pixel.o ../../../lib/ GL/glx/pixelstore.o ../../../lib/GL/glx/render2.o ../../../lib/GL/glx/renderpix. o ../../../lib/GL/glx/single2.o ../../../lib/GL/glx/singlepix.o ../../../lib/GL/ glx/vertarr.o ../../../lib/GL/glx/xfont.o ../../../lib/GL/dri/XF86dri.o ../../.. /lib/GL/dri/dri_glx.o -L../../../exports/lib -L/usr/X11R6/lib -lXThrStub /usr/bin/ld: cannot find -lXThrStub *** Error code 1 Stop in /usr/home/simon/src/dri/build/xc/lib/GL/GL. *** Error code 1 Stop in /usr/home/simon/src/dri/build/xc/lib/GL. *** Error code 1 Stop in /usr/home/simon/src/dri/build/xc/lib. *** Error code 1 Stop in /usr/home/simon/src/dri/build/xc. *** Error code 1 Stop in /usr/home/simon/src/dri/build/xc. I installed XFree CVS first, and then tried to build DRI CVS. Thanks, Simon --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] CTX ioctl differences
Could someone please explain the difference between DRM_IOCTL_ADD_CTX vs DRM_IOCTL_NEW_CTX Then again, maybe DRM_IOCTL_NEW_CTX is more like DRM_IOCTL_SWITCH_CTX, reguardless of whether the name itself sounds more like ADD_CTX? --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Compilation on FreeBSD 5.0
Hello: Simon Cahuk wrote, Hi! I have FreeBSD 5.0-RELEASE. I can't compile DRI CVS. I got this error: /usr/bin/ld: cannot find -lXThrStub *** Error code 1 I ran into the same thing just now, fixed it with a symlink: root# ln -s /usr/local/lib/compat/pkg/libXThrStub.so.6 \ /usr/X11R6/lib/X11/libXThrStub.so -- Shanu http://shankerbalan.com/ -- There's no room in the drug world for amateurs. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] RE: ATI reference drivers
On Thu, 13 Feb 2003, Alexander Stohr wrote: development for the Linux platform has not stopped, surely not, it is just that there were no releases in the last two months or so. i have to admit that there were some problems as for any driver out there, but none was so fundamental serious that we felt it needed an instant driver update. I'm wondering - TransGaming sent in some feedback to ATI about these driver's use of the fs register, which conflicts with the Win32 threading model, replicated by Wine and WineX (TransGaming WineX is designed to run Windows games on Linux). Do you happen to know the status of this issue? WineX is clobbering a register that the OpenGL part of the driver has already sort of claimed? Then their software is sort of broken. ;-) I have never tried WineX myselves in recent times but i am confident that the next ATI Linux driver release will address that thing so that this conflict is solved. As I understand, the fs register is reserved for Wine/Winex usage, and the gs register is used by newer glibc for libpthread, and in the latest glibc for thread local storage (TLS), for threaded applications at least. Anything else using these registers is going to have problems. Nothing should be using fs or gs aside from the above. I've carbon copied Ulrich, Jakub and Arjan in case they'd like to add comments as well. Hope this helps. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Lock problem with Radeon DRI
Hello, I've sucessfully installed radeon DRI binary snapshot from dri.sourceforge.net on my system. 3D acceleration works well, with the exception of an irritating problem: sometimes the system locks with some GL applications if I move or resize the window or (sometimes) on exiting the application. The lock doesn't occur during the actual use of the application, only in the situations above. FlightGear 0.9.1 is the most affected application, but I've been able to reproduce it on FooBillard as well. The only way to recover from the lock is to hard reset the machine. After reboot I find a message like this on the kernel error log: Feb 14 10:11:14 benbecula kernel: [drm:radeon_freelist_get] *ERROR* returning NULL! Feb 14 10:11:15 benbecula kernel: [drm:radeon_lock_take] *ERROR* 4 holds heavyweight lock My system is a P4, intel 845 mb, Radeon 7000 AGP card, Mandrake 9.0 with kernel 2.4.19-ac4, Xfree86 4.2.1 (but with libxaa/XFree86 changed from the 'extras' snapshot to 4.2.0), radeon-20021022 drm snapshoot. Any help would be much appreciated, Pedro. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MindRover+Radeon+DRI=crash
I wrote that MindRover crashes X with Radeon VE and DRI. Last days I asked few people on irc to test MindRover-demo with their Radeons (TCL and no-TCL, DRI from current CVS and older). All of them got X locked. [...] I'm glad to see that FlightGear is not the only reliable test case for the Radeon X server lockup 'feature' ;-)) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
On Fri, 2003-02-14 at 10:38, Pedro Vasconcelos wrote: Hello, I've sucessfully installed radeon DRI binary snapshot from dri.sourceforge.net on my system. 3D acceleration works well, with the exception of an irritating problem: sometimes the system locks with some GL applications if I move or resize the window or (sometimes) on exiting the application. The lock doesn't occur during the actual use of the application, only in the situations above. FlightGear 0.9.1 is the most affected application, but I've been able to reproduce it on FooBillard as well. I'm seeing precisely the same with the Radeon9000 card again with flightgear. If I take off and buzz the scenery (whcih seems to be big textures) it hangs every time with the kernel spewing messages about radeon out of buffers and then hangs solid if I kill it Other than that it rocks --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
On Fre, 2003-02-14 at 11:38, Pedro Vasconcelos wrote: I've sucessfully installed radeon DRI binary snapshot from dri.sourceforge.net on my system. 3D acceleration works well, with the exception of an irritating problem: sometimes the system locks with some GL applications if I move or resize the window or (sometimes) on exiting the application. The lock doesn't occur during the actual use of the application, only in the situations above. FlightGear 0.9.1 is the most affected application, but I've been able to reproduce it on FooBillard as well. The only way to recover from the lock is to hard reset the machine. After reboot I find a message like this on the kernel error log: Feb 14 10:11:14 benbecula kernel: [drm:radeon_freelist_get] *ERROR* returning NULL! Feb 14 10:11:15 benbecula kernel: [drm:radeon_lock_take] *ERROR* 4 holds heavyweight lock My system is a P4, intel 845 mb, Radeon 7000 AGP card, Mandrake 9.0 with kernel 2.4.19-ac4, Xfree86 4.2.1 (but with libxaa/XFree86 changed from the 'extras' snapshot to 4.2.0), radeon-20021022 drm snapshoot. That DRM is pretty old, is the 3D driver from the same date? Someone said on an XFree86 list that the flightgear lockups went away for him with XFree86 4.3.0rc1. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
On Fri, 2003-02-14 at 13:37, Michel Dänzer wrote: That DRM is pretty old, is the 3D driver from the same date? Someone said on an XFree86 list that the flightgear lockups went away for him with XFree86 4.3.0rc1. My lockup with flightgear on the 9000 with 4.2.99 based tree and a recent DRM module. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
On Fre, 2003-02-14 at 16:03, Alan Cox wrote: On Fri, 2003-02-14 at 13:37, Michel Dänzer wrote: That DRM is pretty old, is the 3D driver from the same date? Someone said on an XFree86 list that the flightgear lockups went away for him with XFree86 4.3.0rc1. My lockup with flightgear on the 9000 with 4.2.99 based tree and a recent DRM module. I do wonder if the r200 driver doesn't need the recent r100 fix for DMA buffer corruption (by setting MaxArrayLockSize). -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
[... Alan Cox wrote ...] On Fri, 2003-02-14 at 13:37, Michel Dänzer wrote: That DRM is pretty old, is the 3D driver from the same date? Someone said on an XFree86 list that the flightgear lockups went away for him with XFree86 4.3.0rc1. My lockup with flightgear on the 9000 with 4.2.99 based tree and a recent DRM module. Where did you take the DRM sources from ? I usually take the source for the DRM module from the same DRI CVS tree I use to build the whole DRI thing, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
On Fri, 2003-02-14 at 14:52, Martin Spott wrote: My lockup with flightgear on the 9000 with 4.2.99 based tree and a recent DRM module. Where did you take the DRM sources from ? I usually take the source for the DRM module from the same DRI CVS tree I use to build the whole DRI thing, Mike Harris builds in Red Hat beta and in rawhide --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] (no subject)
confirm 990080 --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
On Fri, Feb 14, 2003 at 04:51:24PM +, Alan Cox wrote: On Fri, 2003-02-14 at 14:52, Martin Spott wrote: My lockup with flightgear on the 9000 with 4.2.99 based tree and a recent DRM module. Where did you take the DRM sources from ? I usually take the source for the DRM module from the same DRI CVS tree I use to build the whole DRI thing, Mike Harris builds in Red Hat beta and in rawhide So if Mike appears to have 'the right stuff' (TM), would it be worth merging the missing bits to the DRI ? I'll see if I can find this stuff and if it helps getting 'my' FlightGear stable, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
On Fri, Feb 14, 2003 at 03:03:06 +, Alan Cox wrote: On Fri, 2003-02-14 at 13:37, Michel Dänzer wrote: That DRM is pretty old, is the 3D driver from the same date? Someone said on an XFree86 list that the flightgear lockups went away for him with XFree86 4.3.0rc1. My lockup with flightgear on the 9000 with 4.2.99 based tree and a recent DRM module. Just to report, I'm also seeing a lockup on an 8500 card. Simple test here is to start the 'tunnel' demo from Mesa - twice... Alan. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch
Leif Delgass wrote: I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've updated the mach64 driver to Mesa 5 based on the changes to the Rage 128 driver. Testing hasn't shown any problems so far. I haven't adapted the mach64 drm to the os-independence changes yet. I could start this, but we are going to need a generic replacement for the pci_alloc_consistent Linux interface. I think it's probably best to hold off on making that switch, pending the changes Jose has proposed: http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg08243.html In the meantime, the drm can still be compiled and used from the old linux kernel directory like the other drivers which have yet to be converted. I'd recommend that people using the mach64-0-0-5-branch from CVS update to this new branch and report any regressions or new bugs to the list. Sometime in the next few weeks, I'll also be updating the GATOS Xvideo patch available at the site in my sig. Since the GATOS head is now based on current XFree86 cvs, I may not have a new patch until 4.3.0 is released and changes get propagated back to the DRI and GATOS trees. Seems to work for me as long as I don't try to use my Radeon at the same time. I have my setup as follows: HEAD 1 HEAD 0 On-board RageXL Radeon 8500 (initialised by BIOS) (Initialised by XFree86) DRI enabled DRI enabled DOES NOT WORK HEAD 1 HEAD 0 On-board RageXL Radeon 8500 (initialised by BIOS) (Initialised by XFree86) DRI disabled DRI enabled DOES WORK HEAD 1 HEAD 0 On-board RageXL Radeon 8500 AGP (initialised by BIOS) (Initialised by XFree86) DRI enabled DRI disabled NOT TESTED HEAD 0 On-board RageXL (initialised by BIOS) DRI enabled DOES WORK I can not have the Radeon initialised by the BIOS since the the RageXL can not then be initialised later. I do have a problem with Radeon with subsequent X server starts. It can not access the V_BIOS and tries to use extremely bogus values. Unless someone here knows how to fix this I will send a mail to XFree86-devel. Attached is the output for the Dual-head DRI failure case. This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.2.99.2 (DRI mach64-0-0-6-branch) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 21 October 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.5.59-test i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Fri Feb 14 16:40:16 2003 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout Default Layout (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Videocard1_0 (**) |--Screen Screen1 (1) (**) | |--Monitor Monitor1 (**) | |--Device Videocard0 (**) |--Input Device DevInputMice (**) |--Input Device Keyboard0 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout gb (**) XKB: layout: gb (==) Keyboard: CustomKeycode disabled (**) FontPath set to /usr/X11R6/lib/X11/fonts/misc:unscaled,/usr/X11R6/lib/X11/fonts/75dpi:unscaled,/usr/X11R6/lib/X11/fonts/100dpi:unscaled,/usr/X11R6/lib/X11/fonts/misc,/usr/X11R6/lib/X11/fonts/Type1,/usr/X11R6/lib/X11/fonts/Speedo,/usr/X11R6/lib/X11/fonts/cyrillic,/usr/X11R6/lib/X11/fonts/TTF,/usr/X11R6/lib/X11/fonts/msttcorefonts,/usr/X11R6/lib/X11/fonts/OTF,/usr/share/fonts/default/Type1,/usr/lib/openoffice/share/fonts/truetype,/usr/share/fonts/ja/TrueType (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (++) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such device) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.2.99.2, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project
Re: [Dri-devel] MindRover+Radeon+DRI=crash
On Fri, Feb 14, 2003 at 11:43:17AM +0100, Martin Spott wrote: I'm glad to see that FlightGear is not the only reliable test case for the Radeon X server lockup 'feature' ;-)) It's probably different problem, because it happen on both R100 and R200. With old DRI drivers and driver from XFree86-4.3.0rc1. -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Security in new drivers
On Fre, 2003-02-14 at 17:42, John Bartoszewski wrote: On Wed, Feb 12, 2003 at 08:19:35PM -0500, Mike A. Harris wrote: On Wed, 12 Feb 2003, John Bartoszewski wrote: Heard comments from whom? And what specific security problems? What source code files are these problems in? Or are they just what-if rumors? The sources at the time could not point me to any specific reports, just that the had read them somewhere. Since then I have concluded that they were talking about the 1999 paper: http://dri.sourceforge.net/doc/security_low_level.html and specifically the possible ability of a DRI client to use DMA to read and write anywhere in memory. I can only talk about the Radeon and Rage128 DRI drivers. The only possibility I'm aware of to do something like that with those is to dispatch an indirect buffer with commands for the chip's command processor, which only root (i.e. normally the X server) can do. There is a potential problem though: all clients have all indirect buffers mapped and thus can read from and write to buffers other clients have allocated. This makes a DoS by crashing the chip relatively easy, but I think it would be very hard to exploit for system memory access, if at all possible. Also keep in mind that access to the DRI can be controlled via ownership and permissions of the /dev/dri/cardX devices. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI Mailing list maintanence / maintaner
Hi Rich Is there anything that can be done to cut down the spam on dri-devel? Several other mailing lists I'm on hold submissions by non-subscribers for approval. I'd even be willing to sort the non-subscribed emails, so that everyone else could avoid them... That would be great, its really starting to get on my tits now. What you've mentioned has been suggested by Alex in response to one of my emails about this. I've tried contacting the list mainatiner privately but it would appear that the maintainer listed under dri-devel list info is incorrect. I've just started running bogofilter on all incoming email, myself, though yeah, it'd be nice if it weren't so necessary. I'm on the dri-digest(s) option so I just live with it. Or am I just being obnoxious? Less so than the spammers. :) I skipped your email because of the subject line. g Liam it depends --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI Mailing list maintanence / maintaner
Smitty wrote: Hi Rich Is there anything that can be done to cut down the spam on dri-devel? Several other mailing lists I'm on hold submissions by non-subscribers for approval. I'd even be willing to sort the non-subscribed emails, so that everyone else could avoid them... That would be great, its really starting to get on my tits now. What you've mentioned has been suggested by Alex in response to one of my emails about this. I've tried contacting the list mainatiner privately but it would appear that the maintainer listed under dri-devel list info is incorrect. I've just started running bogofilter on all incoming email, myself, though yeah, it'd be nice if it weren't so necessary. I'm on the dri-digest(s) option so I just live with it. Or am I just being obnoxious? Less so than the spammers. :) I skipped your email because of the subject line. g I'd be happy to see postings restricted to subscribers too. Unfortunately, I don't know what the list-admin password is. Maybe Daryll or Rik do? -Brian --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Security in new drivers
On Fri, Feb 14, 2003 at 03:23:07PM -0700, John Bartoszewski wrote: On Fri, Feb 14, 2003 at 10:14:21PM +0100, Michel D?nzer wrote: Also keep in mind that access to the DRI can be controlled via ownership and permissions of the /dev/dri/cardX devices. On a private machine this is method is effective. On a public machine, such as a University lab, where all users must be considered hostile this is less effective. how is only user joebrown can read and write /dev/dri/card0 any less effective when there are multiple users on the box ?? --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Some DRM related changes for running multiplei810/830M X servers
Leif Delgass wrote: On Fri, 14 Feb 2003, David Dawes wrote: [snip] There are some more serious things holding up 4.3, including the issue that Leif mentioned here a couple of days ago. I haven't seen anyone comment on his proposed solution for that one either... David I was wondering about that myself. :) I'll reiterate the problem, but this time with a patch to give people something more concrete to comment on. This is, I think, the easiest and quickest fix, if not necessarily the most correct. This patch does the following: 1. Move the __driGarbageCollectDrawables() call in driDestroyContext() back after the driver's DestroyContext() callback as in the original patch in the DRI mesa-4-0-4-branch. This avoids the issue of the drawable being destroyed before the driver tries to reference it, at least in the observed case in the Radeon driver's DestroyContext(). As per our earlier discussions about this patch, I think that this is absolutely correct. The old code is clearly wrong. Does anybody know why the patch was reverted??? 2. Free pBackClipRects in driDestroyDrawable(). This fixes a potential memory leak if there are back-buffer cliprects when the drawable is destroyed. I'm pretty sure this a seperate issue and a valid fix. That seems okay too. Is there any way to verify that the memory leak could actually ever happen? 3. As an added sanity measure, set pClipRects and pBackClipRects pointers to NULL in the drawable private struct when they are freed, before freeing the struct. This _might_ prevent a mirrored private drawable struct pointer held by a driver from pointing to invalid cliprect pointers. However, it won't change the fact that the mirrored private drawable struct pointer itself would be invalid. This change is pretty dubious, as it has the potential to hide the actual problem. I don't think this should take the place of fix #1. If the mirrored private drawable pointer itself is invalid, dereferencing it produces undefined behavior. For debugging, would we just over-write the whole private drawable struct with garbage? Is there anyway to back track and NULL out the mirrored pointer when the private drawable is destroyed? --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Security in new drivers
On Fri, 2003-02-14 at 23:56, Philip Brown wrote: On Fri, Feb 14, 2003 at 03:23:07PM -0700, John Bartoszewski wrote: On Fri, Feb 14, 2003 at 10:14:21PM +0100, Michel D?nzer wrote: Also keep in mind that access to the DRI can be controlled via ownership and permissions of the /dev/dri/cardX devices. On a private machine this is method is effective. On a public machine, such as a University lab, where all users must be considered hostile this is less effective. how is only user joebrown can read and write /dev/dri/card0 any less effective when there are multiple users on the box ?? As well as the unix permissions DRI is also playing games with authentication of its own between the server and clients --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI Mailing list maintanence / maintaner
On Fri, Feb 14, 2003 at 03:34:45 -0700, Brian Paul wrote: Smitty wrote: Hi Rich Is there anything that can be done to cut down the spam on dri-devel? Several other mailing lists I'm on hold submissions by non-subscribers for approval. I'd even be willing to sort the non-subscribed emails, so that everyone else could avoid them... That would be great, its really starting to get on my tits now. What you've mentioned has been suggested by Alex in response to one of my emails about this. I've tried contacting the list mainatiner privately but it would appear that the maintainer listed under dri-devel list info is incorrect. I've just started running bogofilter on all incoming email, myself, though yeah, it'd be nice if it weren't so necessary. I'm on the dri-digest(s) option so I just live with it. Or am I just being obnoxious? Less so than the spammers. :) I skipped your email because of the subject line. g I'd be happy to see postings restricted to subscribers too. Unfortunately, I don't know what the list-admin password is. Maybe Daryll or Rik do? I could do it, but I don't think it's a good idea to restrict those who are non-members of the list. Cross postings from the xfree86 lists are sometimes useful. Alan. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI Mailing list maintanence / maintaner
On Sat, 15 Feb 2003, Alan Hourihane wrote: On Fri, Feb 14, 2003 at 03:34:45 -0700, Brian Paul wrote: Smitty wrote: Hi Rich Is there anything that can be done to cut down the spam on dri-devel? Several other mailing lists I'm on hold submissions by non-subscribers for approval. I'd even be willing to sort the non-subscribed emails, so that everyone else could avoid them... That would be great, its really starting to get on my tits now. What you've mentioned has been suggested by Alex in response to one of my emails about this. I've tried contacting the list mainatiner privately but it would appear that the maintainer listed under dri-devel list info is incorrect. I've just started running bogofilter on all incoming email, myself, though yeah, it'd be nice if it weren't so necessary. I'm on the dri-digest(s) option so I just live with it. Or am I just being obnoxious? Less so than the spammers. :) I skipped your email because of the subject line. g I'd be happy to see postings restricted to subscribers too. Unfortunately, I don't know what the list-admin password is. Maybe Daryll or Rik do? I could do it, but I don't think it's a good idea to restrict those who are non-members of the list. Cross postings from the xfree86 lists are sometimes useful. Alan. What about dri-patches? It gets all the same spam that -devel and -users do. I don't see any reason not to restrict posting to that list to project members. Of course, there may be people with commit access that aren't subscribed. Is there a way to restrict it to sourceforge accounts rather than the subscriber list? -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI Mailing list maintanence / maintaner
Is there anything that can be done to cut down the spam on dri-devel? Several other mailing lists I'm on hold submissions by non-subscribersfor approval. I'd even be willing to sort the non-subscribed emails,so that everyone else could avoid them... That would be great, its really starting to get on my tits now. What you've mentioned has been suggested by Alex in response to one of my emails about this. I've tried contacting the list mainatiner privately but it would appear that the maintainer listed under dri-devel list info is incorrect. I've just started running bogofilter on all incoming email, myself, though yeah, it'd be nice if it weren't so necessary. I'm on the dri-digest(s) option so I just live with it. Or am I just being obnoxious? Less so than the spammers. :) I skipped your email because of the subject line. g I'd be happy to see postings restricted to subscribers too. Unfortunately, I don't know what the list-admin password is. Maybe Daryll or Rik do? I could do it, but I don't think it's a good idea to restrict those who are non-members of the list. Cross postings from the xfree86 lists are sometimes useful. Well Rich already wanted to proof the emails / kill the spam for the list, Alex recomended splitting the list in two, subscribed vs unsubscribed, allowing anything posted by a subscriber through, and filtering the unsubscribed postings. I mean I've heard of Viagra and Propecia (I think) but what the heck Phentermine and Xenical are is beyond me. I assume filtering of sf mailng lists is not possible because filtering on: viagra, porn, mortage - would catch about half of the spam. Liam it depends --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lock problem with Radeon DRI
Michel Dänzer wrote: On Fre, 2003-02-14 at 16:03, Alan Cox wrote: On Fri, 2003-02-14 at 13:37, Michel Dänzer wrote: That DRM is pretty old, is the 3D driver from the same date? Someone said on an XFree86 list that the flightgear lockups went away for him with XFree86 4.3.0rc1. My lockup with flightgear on the 9000 with 4.2.99 based tree and a recent DRM module. I do wonder if the r200 driver doesn't need the recent r100 fix for DMA buffer corruption (by setting MaxArrayLockSize). I don't think so as locked arrays are always emitted as separate arrays, which have a maximum size less than the dma buffer size. Keith --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Security in new drivers
On Sat, Feb 15, 2003 at 01:51:57AM +, Alan Cox wrote: On Fri, 2003-02-14 at 23:56, Philip Brown wrote: how is only user joebrown can read and write /dev/dri/card0 any less effective when there are multiple users on the box ?? As well as the unix permissions DRI is also playing games with authentication of its own between the server and clients So the idea is maybe that: Someone could get access to the device, get a key, log out, but not fully log out, and keep the key... then the next person logs in, uses DRI, but the first person still has access? I'm not up to speed on the drm kernel access granting methods yet.. would this really work? I'm surprised, if it does . I would think if one user logs out, then the X server gets killed. At which point, I would assume that the drm code would reset all access to the dri device. If not, sounds like someone has some more kernel coding to do ;-) One obvious way to handle this, would be for the root server to send the uid of the first DRI-using user-level process as part of the request a key sequence to the driver. Then the driver only grants access to root, and that user, until the main root session dies. Then access perms should be reset, and there's no more security problem. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Some DRM related changes for running multiplei810/830M X servers
On Fri, 14 Feb 2003, Ian Romanick wrote: Leif Delgass wrote: On Fri, 14 Feb 2003, David Dawes wrote: [snip] There are some more serious things holding up 4.3, including the issue that Leif mentioned here a couple of days ago. I haven't seen anyone comment on his proposed solution for that one either... David I was wondering about that myself. :) I'll reiterate the problem, but this time with a patch to give people something more concrete to comment on. This is, I think, the easiest and quickest fix, if not necessarily the most correct. This patch does the following: 1. Move the __driGarbageCollectDrawables() call in driDestroyContext() back after the driver's DestroyContext() callback as in the original patch in the DRI mesa-4-0-4-branch. This avoids the issue of the drawable being destroyed before the driver tries to reference it, at least in the observed case in the Radeon driver's DestroyContext(). As per our earlier discussions about this patch, I think that this is absolutely correct. The old code is clearly wrong. Does anybody know why the patch was reverted??? As far as I can tell, an additional fix for the infinite loop on getting the drawable info was added (using __driFindDrawable()), and it was assumed that this part of the patch wasn't needed. Probably the double-free issue wasn't known to be there? (There's no segfault, so you'd have to use MALLOC_CHECK_ to see it in testing). 2. Free pBackClipRects in driDestroyDrawable(). This fixes a potential memory leak if there are back-buffer cliprects when the drawable is destroyed. I'm pretty sure this a seperate issue and a valid fix. That seems okay too. Is there any way to verify that the memory leak could actually ever happen? I put a printf in the block where pBackClipRects is freed (in the patched version), and I can get it to trigger when closing multiple texobj instances, e.g. I ran them both with MALLOC_CHECK_, and there's no double-free happening. So yes, it seems it can happen. 3. As an added sanity measure, set pClipRects and pBackClipRects pointers to NULL in the drawable private struct when they are freed, before freeing the struct. This _might_ prevent a mirrored private drawable struct pointer held by a driver from pointing to invalid cliprect pointers. However, it won't change the fact that the mirrored private drawable struct pointer itself would be invalid. This change is pretty dubious, as it has the potential to hide the actual problem. I don't think this should take the place of fix #1. If the mirrored private drawable pointer itself is invalid, dereferencing it produces undefined behavior. For debugging, would we just over-write the whole private drawable struct with garbage? Is there anyway to back track and NULL out the mirrored pointer when the private drawable is destroyed? Well, as I mentioned, the driDestroyDrawable() function calls the driver's DestroyBuffer() right before freeing the private struct, so the driver could NULL out it's mirrored pointer then. But that means checking for a NULL private drawable in any code that could be reached after that point. __driUtilUpdateDrawableInfo() should never be called with a NULL or invalid private drawable pointer as it stands now, as the result of freeing the cliprects is undefined behavior (even with Fix #3). Moving the __driGarbageCollectDrawables() call avoids all this, at least for context teardown. The other place __driGarbageCollectDrawables() is called is at the end of driCreateContext(). At that point, the driver's CreateContext() has been called, which initializes the drawable private pointer to NULL. The pointer first gets a real value when the context is made current. I don't see any other way that the drawable could be destroyed before the driver's context is, with Fix #1 in place. -- Leif Delgass http://www.retinalburn.net --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] dri-devel .()
Title: ±×µ¿¾È Àß Áö³»¼Ì´ÂÁö¿ä ±×µ¿¾È Àß Áö³»¼Ì´ÂÁö¿ä? ÇöÀçÀÇ »îÀ» ȹ±âÀûÀ¸·Î º¯ÈÇϽðíÀÚ ÇÏ´Â ºÐ¸¸ ÀоîÁÖ½Ã°í µ¿ÂüÇÏ¿© Áֽñ⸦ ¹Ù¶ø´Ï´Ù. ÇöÀçÀÇ »î¿¡ ¸¸Á·ÇϽô ºÐ²² Á¤¸» ¹Ì¾ÈÇÕ´Ï´Ù. 2003³â! ÇÑÇØ°¡ ½ÃÀÛµÇ°í ¸ðµÎµé »õ·Î¿î °¢¿À·Î »îÀ» ¼³°èÇÏ°í ÀÖ½À´Ï´Ù. ÇÑÇظ¦ ¸¶¹«¸®ÇÏ¸é¼ º¸¶÷µµ ÀÖ¾ú½À´Ï´Ù¸¸ ¸¹Àº ºÐµéÀÌ ÈÄȸ¸¦ ÇÏ´Â »îÀ» »ì¾Æ°¡°í ÀÖ½À´Ï´Ù. Àú ¿ª½Ã(46¼¼ 1³² 1³àÀÇ °¡Àå) ¿½ÉÈ÷ »îÀ» °³Ã´ÇÏ°í âÁ¶ÇÏ°í ÀÖÀ¸³ª ÈÄȸ¸¦ ÇÏÁö¿ä. ±×·¯¸é¼ ¿ÃÇØ´Â Á¶±Ý ´õ ÁÁ¾Æ Áú °Å¾ß! »îÀÇ ÁúÀÌ Çâ»ó µÉ °Å¾ß! ÀÌ·¸°Ô ÀÚ½ÅÀ» À§·ÎÇÏ¸é¼ ¸»ÀÔ´Ï´Ù. ½Å¿ëºÒ·®ÀÚ 400¸¸ ¸íÀÇ ½Ã´ë! - Àúµµ ½Å¿ë ºÒ·®ÀÚÁßÀÇ ÇÑ»ç¶÷! ÁÖÀ§¸¦ µ¹¾Æ º¸¸é ¿½ÉÈ÷ »ì¾Æ°¡Áö ¾ÊÀº »ç¶÷Àº ¾ø¾ú½À´Ï´Ù. ±æ°Å¸®¿¡¼ ºØ¾î»§À» ¿½ÉÈ÷ ²ß´Â ¾ÆÀú¾¾, ½ÃÀå¹Ù´Ú ³Àü¿¡¼ ¾ç¸»À» ÆÄ´Â ¾ÆÁÖ¸Ó´Ï, À½¾Ç¿¡ ¸ÂÃß¾î ½Ä´ç OPENÀ» ¿½ÉÈ÷ È«º¸ÇÏ´Â µµ¿ì¹Ì ¾Æ°¡¾¾ Àú¸¶´Ù ¿½ÉÈ÷ ¹«¾ùÀÌ À߸ø µÇ¾ú±æ·¡ ½Å¿ë ºÒ·®ÀÚ¶ó´Â ½Å¼¼°¡ µÇ¾î¾ß ÇÏ´ÂÁö ¿½ÉÈ÷ ³ë·Â Çϴµ¥µµ ¸»ÀÔ´Ï´Ù. ´©±¸¸¦ Å¿ ÇÒ ¼ö ¾ø´Ù! ºóºÎÀÇ °ÝÂ÷´Â Á¼Èú ¼ö ¾ø°í Á¡Á¡ Ä¿Áö°í ÀÖ½À´Ï´Ù. Á¤ºÎµµ ±â¾÷µµ Ã¥ÀÓÁú »çÇ×ÀÌ ¾Æ´Ï¶ó´Â °ÍÀÔ´Ï´Ù. ¼±Áø±¹ Çü ´ëÇѹα¹ Çö½ÇÀÌÁö¿ä. Àú´Â ¿À´Ã Áý »ç¶÷°ú ÇÔ²² Ä«µå ±øÀ» ÇÏ·¯ °¬½À´Ï´Ù. ¼ö¼ö·á°¡ 10% ÀÌ´õ±º¿ä. ±×°Íµµ »çÁ¤À» ÇÏ¿©¼ ¸»ÀÔ´Ï´Ù! µ¹¾Æ¿À¸é¼ ³»°¡ ¿Ö ÀÌ·²±î? ¹«¾ùÀÌ À߸øµÇ¾ú´Â°¡? 46³â µ¿¾È ³²À» ¼ÓÀÌÁö ¾Ê¾Ò°í Á÷Àå»ýÈ°¿¡¼´Â ¼º½ÇÇÏ°í ºÎÁö·±ÇÏ¿© ƯÁøÀ» ¸î ¹øÇÑ ±â¾ïÀÌ ÀÖ°í °³ÀÎ »ç¾÷ÇÒ ¶§¿¡´Â ÀáÀ» ÁÙ¿©°¡¸ç Àü·Â ÅõÀÚÇÏ¿´À¸³ª ½ÇÆÐÇÏ¿´½À´Ï´Ù. °³ÀÎ »ç¾÷ÀÇ ½ÇÆÐ¿Í ÈÄÀ¯Áõ°ú °íÅëÀº ±ä ÅͳÎÀÌ µÇ°í. ¿ì¿¬ÇÑ ¹ß°ß! ¹¶Ä¡¸é »ì°í Èð¾îÁö¸é Á״´٠À̽¸¸¹Ú»ç´ÔÀÇ ´ëÇѹα¹ Á¤ºÎ ¼ö¸³ ½Ã ÇϽŠ¸»¾¸À¸·Î ±â¾ïÇÕ´Ï´Ù. ±×·¸½À´Ï´Ù. ÀÌÁ¦ Âù¶õÇÑ 21¼¼±â°¡ ½ÃÀ۵ǰí ÀÖ½À´Ï´Ù. ¾ÈŸ±õ°Ôµµ Çö½ÇÀº Âù¶õÇÏÁö¸¦ ¾Ê½À´Ï´Ù. Á¤ºÎµµ ±â¾÷µµ ¾î´À ´©±¸µµ ³ª¿Í ÀÌ ±ÛÀ» Àаí ÀÖ´Â ±ÍÇÏÀÇ »îÀ» º¸ÀåÇÏÁö ¾Ê½À´Ï´Ù. ±×·¸´Ù¸é ¾î¶»°Ô ³»ÀÏ, 2003³â 365ÀÏ, ³ª¿Í °¡Á·ÀÇ ¹Ì·¡¸¦ Áغñ ÇÒ °ÍÀΰ¡? ÇØ´äÀº ÀÎÅͳݿ¡ ÀÖ¾ú½À´Ï´Ù. ±×¸®°í °°Àº ¸¶À½ÀÇ »ç¶÷µé°ú ÇÔ²² ¶Ê¶Ê ¹¶Ä¡¸é µÈ´Ù. Èñ¸ÁÀÔ´Ï´Ù. ±ôºýÀ̸¦ ³Ö°í Â÷¼±À» ÇÔ²² ¹Ù²ÙÀÚ! ¿À´Ã ÂøÀâÇÑ ¸¶À½À¸·Î ÀÎÅͳÝÀ» ÇÏ´ø Áß Æò¼Ò¿¡ °¥¸ÁÇÏ´ø ¹æ¹ýÀ» ã¾Ò½À´Ï´Ù. ¸ð¸£´Â »ç¶÷¿¡°Ô ºÎŹÇÒ ÇÊ¿äµµ ¾ø°í ¹°°ÇÀ» ÆÈ ÇÊ¿äµµ ¾ø½À´Ï´Ù. ´ÜÁö ±ÍÇϲ²¼ ±ôºýÀ̸¦ ³Ö°í Â÷¼± º¯°æÀ» °áÁ¤¸¸ ÇϽŴٸé 100% ÀÎÅͳÝÀ¸·Î ÀÌ·ç¾îÁö´Â ȹ±âÀûÀÎ ¾ÆÀÌÅÛÀÔ´Ï´Ù. Áø¸®´Â ´Ü¼øÇÕ´Ï´Ù. ±×¸®°í °¡±î¿îµ¥ ÀÖ¾ú½À´Ï´Ù. Àú¿Í ÇÔ²² ÇÏ½Ç 3¸íÀ» ã½À´Ï´Ù. ¾ÆÀÌÅÛÀ» ¸ÞÀÏ·Î °ø°³ ÇÏÁö ¸øÇÔÀ» ¾çÇعٶó¸ç ÀúÀÇ ¸¶À½°ú °°ÀÌ Àý¹ÚÇÏ°Ô Ã£´Â ºÐ¿¡°Ô ¾Ë·Á µå¸®°Ú½À´Ï´Ù. ´ëÇѹα¹ ÀþÀº Á¤ºÎ ź»ý! 2002³âÀº ÀÎÅͳÝÀ̶ó´Â µµ±¸·Î ¸î ³â Àü ¿¡´Â »ó»óµµ ÇÏÁö ¸øÇÑ ÀþÀº Á¤ºÎ¸¦ ź»ý½ÃÅ°´Â ÈûÀÇ ½Ã¹ßÁ¡ÀÌ µÇ¾ú½À´Ï´Ù. ÀÎÅͳÝÀÇ À§·ÂÀÔ´Ï´Ù. Àú¿Í ÇÔ²² °Ç°ÇÑ °¡Á¤! °Ç°ÇÑ °³ÀÎÀ» ¸¸µé¾î °©½Ã´Ù! ±×¸®°í ½Å¿ë ºÒ·®ÀÚ¿¡¼ Å»ÃâÇսôÙ. ÇÔ²² ¹¶Ä¡¸é µË´Ï´Ù. À̸ÞÀÏ·Î ¹®ÀÇ ÇϽøé Áï½Ã ¹æ¹ýÀ» ¾Ë·Á µå¸®°Ú½À´Ï´Ù. [EMAIL PROTECTED] ÁÁÀº ÇÏ·çµÇ½Ã°í ÈÀÌÆà ÇϽʽÿÀ. http://www.crusade.co.kr/reject/reject.php?id=1013=write&[EMAIL PROTECTED] Âü°í·Î 8¾ï¹ú±â±¤°í º¸°í µ·¹ú±âµîÀº ¾Æ´Ï¶ó´Â °ÍÀ» ¾Ë·Áµå¸³´Ï´Ù. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] DRI Mailing list maintanence / maintaner
below is a sample how other lists do handle list submissions from non subscribers. on a second place i know that the adminstrators eased their job by setting a maximum hold time after which the mail will be passed trough unless an admin has canceled its delivery. I would further like to know if it is possible to install that same spam filtering on SF.net which David mentioned for the XFree86 mail lists. -Alex. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 15, 2003 06:45 To: [EMAIL PROTECTED] Subject: Your message to Flightgear-users awaits moderator approval Your mail to 'Flightgear-users' with the subject base package path contains a bad trap Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Some DRM related changes for running multiplei810/830M X servers
On Fri, 14 Feb 2003, David Dawes wrote:
[snip]
There are some more serious things holding up 4.3, including the issue
that Leif mentioned here a couple of days ago. I haven't seen anyone
comment on his proposed solution for that one either...
David
I was wondering about that myself. :) I'll reiterate the problem, but this
time with a patch to give people something more concrete to comment on.
This is, I think, the easiest and quickest fix, if not necessarily the
most correct. This patch does the following:
1. Move the __driGarbageCollectDrawables() call in driDestroyContext()
back after the driver's DestroyContext() callback as in the original patch
in the DRI mesa-4-0-4-branch. This avoids the issue of the drawable being
destroyed before the driver tries to reference it, at least in the
observed case in the Radeon driver's DestroyContext().
2. Free pBackClipRects in driDestroyDrawable(). This fixes a potential
memory leak if there are back-buffer cliprects when the drawable is
destroyed. I'm pretty sure this a seperate issue and a valid fix.
3. As an added sanity measure, set pClipRects and pBackClipRects pointers
to NULL in the drawable private struct when they are freed, before freeing
the struct. This _might_ prevent a mirrored private drawable struct
pointer held by a driver from pointing to invalid cliprect pointers.
However, it won't change the fact that the mirrored private drawable
struct pointer itself would be invalid. This change is pretty dubious, as
it has the potential to hide the actual problem. I don't think this
should take the place of fix #1. If the mirrored private drawable pointer
itself is invalid, dereferencing it produces undefined behavior.
If we don't use Fix #1, the alternative is to modify the drivers to set
the mirrored drawable pointer to NULL in the DestroyBuffer() callback and
deal with the possibility of a NULL drawable pointer in any code that can
be called after DestroyBuffer(), e.g when locking and any state changes
made after the lock is acquired. This might be a more correct fix, but it
seems to me it would be more intrusive and require more checking for
side-effects.
--
Leif Delgass
http://www.retinalburn.net
Index: dri_util.c
===
RCS file: /cvs/xc/lib/GL/dri/dri_util.c,v
retrieving revision 1.5
diff -u -r1.5 dri_util.c
--- dri_util.c 2003/02/11 03:30:20 1.5
+++ dri_util.c 2003/02/14 22:50:11
@@ -629,7 +629,7 @@
pdp-numClipRects = 0;
pdp-pClipRects = NULL;
pdp-numBackClipRects = 0;
- pdp-pBackClipRects = 0;
+ pdp-pBackClipRects = NULL;
}
else
pdp-pStamp = (psp-pSAREA-drawableTable[pdp-index].stamp);
@@ -740,8 +740,14 @@
(*psp-DriverAPI.DestroyBuffer)(pdp);
if (__driWindowExists(dpy, pdp-draw))
(void)XF86DRIDestroyDrawable(dpy, scrn, pdp-draw);
- if (pdp-pClipRects)
+ if (pdp-pClipRects) {
Xfree(pdp-pClipRects);
+ pdp-pClipRects = NULL;
+ }
+ if (pdp-pBackClipRects) {
+ Xfree(pdp-pBackClipRects);
+ pdp-pBackClipRects = NULL;
+ }
Xfree(pdp);
}
}
@@ -763,8 +769,8 @@
psp-fullscreen = NULL;
}
}
- __driGarbageCollectDrawables(pcp-driScreenPriv-drawHash);
(*pcp-driScreenPriv-DriverAPI.DestroyContext)(pcp);
+ __driGarbageCollectDrawables(pcp-driScreenPriv-drawHash);
(void)XF86DRIDestroyContext(dpy, scrn, pcp-contextID);
Xfree(pcp);
}
[Dri-devel] Some DRM related changes for running multiple i810/830M X servers
Egbert and I have been looking into the issues that are preventing a second
X server to be started for i810/830M platforms when DRI is enabled. Several
issues were found:
1. The i810 support doesn't unbind/release the agpgart module when VT
switching away, and this prevents a second X server from acquiring
it. Since the i810 driver requires agpgart access even for 2D
operation, this is prevents a second X server from running. A fix
for this is to add the unbind/release calls at LeaveVT, and
acquire/rebind at EnterVT. The attached patch does this. It also
makes a small change to the unbind code in the DRM kernel modules
to handle this.
2. The 830M support does unbind/release the agpgart module, but code
in DRM(release) called when closing a /dev/dri/* device blocks
until it can obtain the lock. Since the first server holds the
lock while switched away, the second one can never get it, so it
ends up blocking in close(). The second server opens/closes the
devices to find out whether DRI can be enabled. DRI can't be
enabled on the second server (which isn't a problem), but this
blocking behaviour is preventing it from starting up at all. I've
found that this can be solved by keeping track of whether the opener
has ever tried to acquire the lock, and not try to acquire it at
close/release when it had never previously been acquired. The patch
below implements this.
3. The drm module AGP support code keeps track of a handle for
allocated AGP regions. It uses the memory address returned from
the allocation for this purpose. This would normally be unique,
but for the i810 driver case where DCACHE memory is allocated.
In the DCACHE case, the allocated memory is freed immediately (since
DCACHE doesn't come from the system memory pool), and the next
allocation often ends up getting the same memory address, and thus
the same handle. This showed up as a problem when the unbind/rebind
code was added.
The user-level agpgart interfaces use a key value to uniquely
identify allocated AGP regions. I don't know why the DRM module
doesn't do the same, since the key is guaranteed to be unique.
The patch below changes the handle to be the key value.
I'm wary of making changes like this so close to the 4.3 release, but
I would like to see this problem fixed in 4.3. Does anyone see any
potential problems with the attached patch?
David
--
David Dawes
Release Engineer/Architect The XFree86 Project
www.XFree86.org/~dawes
Index: drivers/i810/i810.h
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/i810/i810.h,v
retrieving revision 1.37
diff -u -r1.37 i810.h
--- drivers/i810/i810.h 2002/12/10 01:27:04 1.37
+++ drivers/i810/i810.h 2003/02/14 20:00:33
@@ -264,6 +264,9 @@
extern Bool I810DRIFinishScreenInit(ScreenPtr pScreen);
extern Bool I810InitDma(ScrnInfoPtr pScrn);
extern Bool I810CleanupDma(ScrnInfoPtr pScrn);
+extern Bool I810DRILeave(ScrnInfoPtr pScrn);
+extern Bool I810DRIEnter(ScrnInfoPtr pScrn);
+
#define I810PTR(p) ((I810Ptr)((p)-driverPrivate))
#define I810REGPTR(p) ((I810PTR(p)-ModeReg))
Index: drivers/i810/i810_dri.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/i810/i810_dri.c,v
retrieving revision 1.33
diff -u -r1.33 i810_dri.c
--- drivers/i810/i810_dri.c 2002/12/10 01:27:04 1.33
+++ drivers/i810/i810_dri.c 2003/02/14 20:00:33
@@ -1218,3 +1218,84 @@
pI810-AccelInfoRec-NeedToSync = TRUE;
}
+
+Bool
+I810DRILeave(ScrnInfoPtr pScrn)
+{
+I810Ptr pI810 = I810PTR(pScrn);
+
+if (pI810-directRenderingEnabled) {
+ if (pI810-dcacheHandle != 0)
+ if (drmAgpUnbind(pI810-drmSubFD, pI810-dcacheHandle) != 0) {
+ xf86DrvMsg(pScrn-scrnIndex, X_ERROR,%s\n,strerror(errno));
+ return FALSE;
+ }
+ if (pI810-backHandle != 0)
+ if (drmAgpUnbind(pI810-drmSubFD, pI810-backHandle) != 0) {
+ xf86DrvMsg(pScrn-scrnIndex, X_ERROR,%s\n,strerror(errno));
+ return FALSE;
+ }
+ if (pI810-zHandle != 0)
+ if (drmAgpUnbind(pI810-drmSubFD, pI810-zHandle) != 0) {
+ xf86DrvMsg(pScrn-scrnIndex, X_ERROR,%s\n,strerror(errno));
+ return FALSE;
+ }
+ if (pI810-sysmemHandle != 0)
+ if (drmAgpUnbind(pI810-drmSubFD, pI810-sysmemHandle) != 0) {
+ xf86DrvMsg(pScrn-scrnIndex, X_ERROR,%s\n,strerror(errno));
+ return FALSE;
+ }
+ if (pI810-xvmcHandle != 0)
+ if (drmAgpUnbind(pI810-drmSubFD, pI810-xvmcHandle) != 0) {
+ xf86DrvMsg(pScrn-scrnIndex, X_ERROR,%s\n,strerror(errno));
+ return FALSE;
+ }
+ if
[Dri-devel] Re: Some DRM related changes for running multiple i810/830M X servers
I meant to add that it'd be good if something along the lines of Michel Dänzer's work to allow DRI to be reinitialised at VT switch was added in after 4.3. I'm curious why it didn't made it into the DRI trunk already. David On Fri, Feb 14, 2003 at 04:17:16PM -0500, David Dawes wrote: Egbert and I have been looking into the issues that are preventing a second X server to be started for i810/830M platforms when DRI is enabled. Several issues were found: 1. The i810 support doesn't unbind/release the agpgart module when VT switching away, and this prevents a second X server from acquiring it. Since the i810 driver requires agpgart access even for 2D operation, this is prevents a second X server from running. A fix for this is to add the unbind/release calls at LeaveVT, and acquire/rebind at EnterVT. The attached patch does this. It also makes a small change to the unbind code in the DRM kernel modules to handle this. 2. The 830M support does unbind/release the agpgart module, but code in DRM(release) called when closing a /dev/dri/* device blocks until it can obtain the lock. Since the first server holds the lock while switched away, the second one can never get it, so it ends up blocking in close(). The second server opens/closes the devices to find out whether DRI can be enabled. DRI can't be enabled on the second server (which isn't a problem), but this blocking behaviour is preventing it from starting up at all. I've found that this can be solved by keeping track of whether the opener has ever tried to acquire the lock, and not try to acquire it at close/release when it had never previously been acquired. The patch below implements this. 3. The drm module AGP support code keeps track of a handle for allocated AGP regions. It uses the memory address returned from the allocation for this purpose. This would normally be unique, but for the i810 driver case where DCACHE memory is allocated. In the DCACHE case, the allocated memory is freed immediately (since DCACHE doesn't come from the system memory pool), and the next allocation often ends up getting the same memory address, and thus the same handle. This showed up as a problem when the unbind/rebind code was added. The user-level agpgart interfaces use a key value to uniquely identify allocated AGP regions. I don't know why the DRM module doesn't do the same, since the key is guaranteed to be unique. The patch below changes the handle to be the key value. I'm wary of making changes like this so close to the 4.3 release, but I would like to see this problem fixed in 4.3. Does anyone see any potential problems with the attached patch? David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Some DRM related changes for running multiple i810/830M X servers
Since the changes touch the general DRM code I would say hold off on making the changes. I think it might be a good idea to push the 4.3.0 out the door and let the vendors pick up that for release since quite a few improvements already exist in the code base. At that point we can focus on a release that has some of the improvements that have been working their way into the DRI CVS tree, but haven't been accepted in the main XFree86 tree since they were too drastic for the 4.3.0 release. Just my thoughts ... On Fri, 14 Feb 2003, David Dawes wrote: Egbert and I have been looking into the issues that are preventing a second X server to be started for i810/830M platforms when DRI is enabled. Several issues were found: 1. The i810 support doesn't unbind/release the agpgart module when VT switching away, and this prevents a second X server from acquiring it. Since the i810 driver requires agpgart access even for 2D operation, this is prevents a second X server from running. A fix for this is to add the unbind/release calls at LeaveVT, and acquire/rebind at EnterVT. The attached patch does this. It also makes a small change to the unbind code in the DRM kernel modules to handle this. 2. The 830M support does unbind/release the agpgart module, but code in DRM(release) called when closing a /dev/dri/* device blocks until it can obtain the lock. Since the first server holds the lock while switched away, the second one can never get it, so it ends up blocking in close(). The second server opens/closes the devices to find out whether DRI can be enabled. DRI can't be enabled on the second server (which isn't a problem), but this blocking behaviour is preventing it from starting up at all. I've found that this can be solved by keeping track of whether the opener has ever tried to acquire the lock, and not try to acquire it at close/release when it had never previously been acquired. The patch below implements this. 3. The drm module AGP support code keeps track of a handle for allocated AGP regions. It uses the memory address returned from the allocation for this purpose. This would normally be unique, but for the i810 driver case where DCACHE memory is allocated. In the DCACHE case, the allocated memory is freed immediately (since DCACHE doesn't come from the system memory pool), and the next allocation often ends up getting the same memory address, and thus the same handle. This showed up as a problem when the unbind/rebind code was added. The user-level agpgart interfaces use a key value to uniquely identify allocated AGP regions. I don't know why the DRM module doesn't do the same, since the key is guaranteed to be unique. The patch below changes the handle to be the key value. I'm wary of making changes like this so close to the 4.3 release, but I would like to see this problem fixed in 4.3. Does anyone see any potential problems with the attached patch? David -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Some DRM related changes for running multiple i810/830M X servers
On Fri, Feb 14, 2003 at 03:35:48PM -0600, D. Hageman wrote: Since the changes touch the general DRM code I would say hold off on making the changes. I think it might be a good idea to push the 4.3.0 out the door and let the vendors pick up that for release since quite a few improvements already exist in the code base. At that point we can focus on a release that has some of the improvements that have been working their way into the DRI CVS tree, but haven't been accepted in the main XFree86 tree since they were too drastic for the 4.3.0 release. Just my thoughts ... Thanks for them, but I'm really looking for feedback on the technical merit or otherwise of the fix rather than opening a discussion about the 4.3 release schedule. There are some more serious things holding up 4.3, including the issue that Leif mentioned here a couple of days ago. I haven't seen anyone comment on his proposed solution for that one either... David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Some DRM related changes for running multiple i810/830M X servers
This patch looks good to me Leif.
Alan.
On Fri, Feb 14, 2003 at 06:24:50 -0500, Leif Delgass wrote:
On Fri, 14 Feb 2003, David Dawes wrote:
[snip]
There are some more serious things holding up 4.3, including the issue
that Leif mentioned here a couple of days ago. I haven't seen anyone
comment on his proposed solution for that one either...
David
I was wondering about that myself. :) I'll reiterate the problem, but this
time with a patch to give people something more concrete to comment on.
This is, I think, the easiest and quickest fix, if not necessarily the
most correct. This patch does the following:
1. Move the __driGarbageCollectDrawables() call in driDestroyContext()
back after the driver's DestroyContext() callback as in the original patch
in the DRI mesa-4-0-4-branch. This avoids the issue of the drawable being
destroyed before the driver tries to reference it, at least in the
observed case in the Radeon driver's DestroyContext().
2. Free pBackClipRects in driDestroyDrawable(). This fixes a potential
memory leak if there are back-buffer cliprects when the drawable is
destroyed. I'm pretty sure this a seperate issue and a valid fix.
3. As an added sanity measure, set pClipRects and pBackClipRects pointers
to NULL in the drawable private struct when they are freed, before freeing
the struct. This _might_ prevent a mirrored private drawable struct
pointer held by a driver from pointing to invalid cliprect pointers.
However, it won't change the fact that the mirrored private drawable
struct pointer itself would be invalid. This change is pretty dubious, as
it has the potential to hide the actual problem. I don't think this
should take the place of fix #1. If the mirrored private drawable pointer
itself is invalid, dereferencing it produces undefined behavior.
If we don't use Fix #1, the alternative is to modify the drivers to set
the mirrored drawable pointer to NULL in the DestroyBuffer() callback and
deal with the possibility of a NULL drawable pointer in any code that can
be called after DestroyBuffer(), e.g when locking and any state changes
made after the lock is acquired. This might be a more correct fix, but it
seems to me it would be more intrusive and require more checking for
side-effects.
--
Leif Delgass
http://www.retinalburn.net
Content-Description: dri_util.diff
Index: dri_util.c
===
RCS file: /cvs/xc/lib/GL/dri/dri_util.c,v
retrieving revision 1.5
diff -u -r1.5 dri_util.c
--- dri_util.c2003/02/11 03:30:20 1.5
+++ dri_util.c2003/02/14 22:50:11
@@ -629,7 +629,7 @@
pdp-numClipRects = 0;
pdp-pClipRects = NULL;
pdp-numBackClipRects = 0;
- pdp-pBackClipRects = 0;
+ pdp-pBackClipRects = NULL;
}
else
pdp-pStamp = (psp-pSAREA-drawableTable[pdp-index].stamp);
@@ -740,8 +740,14 @@
(*psp-DriverAPI.DestroyBuffer)(pdp);
if (__driWindowExists(dpy, pdp-draw))
(void)XF86DRIDestroyDrawable(dpy, scrn, pdp-draw);
- if (pdp-pClipRects)
+ if (pdp-pClipRects) {
Xfree(pdp-pClipRects);
+ pdp-pClipRects = NULL;
+ }
+ if (pdp-pBackClipRects) {
+ Xfree(pdp-pBackClipRects);
+ pdp-pBackClipRects = NULL;
+ }
Xfree(pdp);
}
}
@@ -763,8 +769,8 @@
psp-fullscreen = NULL;
}
}
- __driGarbageCollectDrawables(pcp-driScreenPriv-drawHash);
(*pcp-driScreenPriv-DriverAPI.DestroyContext)(pcp);
+ __driGarbageCollectDrawables(pcp-driScreenPriv-drawHash);
(void)XF86DRIDestroyContext(dpy, scrn, pcp-contextID);
Xfree(pcp);
}
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Some DRM related changes for running multiple i810/830M X servers
Certainly can't see any immediate problem David.
We can always cut a 4.3.1 if issues are found anyway.
Alan.
On Fri, Feb 14, 2003 at 04:17:16 -0500, David Dawes wrote:
Egbert and I have been looking into the issues that are preventing a second
X server to be started for i810/830M platforms when DRI is enabled. Several
issues were found:
1. The i810 support doesn't unbind/release the agpgart module when VT
switching away, and this prevents a second X server from acquiring
it. Since the i810 driver requires agpgart access even for 2D
operation, this is prevents a second X server from running. A fix
for this is to add the unbind/release calls at LeaveVT, and
acquire/rebind at EnterVT. The attached patch does this. It also
makes a small change to the unbind code in the DRM kernel modules
to handle this.
2. The 830M support does unbind/release the agpgart module, but code
in DRM(release) called when closing a /dev/dri/* device blocks
until it can obtain the lock. Since the first server holds the
lock while switched away, the second one can never get it, so it
ends up blocking in close(). The second server opens/closes the
devices to find out whether DRI can be enabled. DRI can't be
enabled on the second server (which isn't a problem), but this
blocking behaviour is preventing it from starting up at all. I've
found that this can be solved by keeping track of whether the opener
has ever tried to acquire the lock, and not try to acquire it at
close/release when it had never previously been acquired. The patch
below implements this.
3. The drm module AGP support code keeps track of a handle for
allocated AGP regions. It uses the memory address returned from
the allocation for this purpose. This would normally be unique,
but for the i810 driver case where DCACHE memory is allocated.
In the DCACHE case, the allocated memory is freed immediately (since
DCACHE doesn't come from the system memory pool), and the next
allocation often ends up getting the same memory address, and thus
the same handle. This showed up as a problem when the unbind/rebind
code was added.
The user-level agpgart interfaces use a key value to uniquely
identify allocated AGP regions. I don't know why the DRM module
doesn't do the same, since the key is guaranteed to be unique.
The patch below changes the handle to be the key value.
I'm wary of making changes like this so close to the 4.3 release, but
I would like to see this problem fixed in 4.3. Does anyone see any
potential problems with the attached patch?
David
--
David Dawes
Release Engineer/Architect The XFree86 Project
www.XFree86.org/~dawes
Index: drivers/i810/i810.h
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/i810/i810.h,v
retrieving revision 1.37
diff -u -r1.37 i810.h
--- drivers/i810/i810.h 2002/12/10 01:27:04 1.37
+++ drivers/i810/i810.h 2003/02/14 20:00:33
@@ -264,6 +264,9 @@
extern Bool I810DRIFinishScreenInit(ScreenPtr pScreen);
extern Bool I810InitDma(ScrnInfoPtr pScrn);
extern Bool I810CleanupDma(ScrnInfoPtr pScrn);
+extern Bool I810DRILeave(ScrnInfoPtr pScrn);
+extern Bool I810DRIEnter(ScrnInfoPtr pScrn);
+
#define I810PTR(p) ((I810Ptr)((p)-driverPrivate))
#define I810REGPTR(p) ((I810PTR(p)-ModeReg))
Index: drivers/i810/i810_dri.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/i810/i810_dri.c,v
retrieving revision 1.33
diff -u -r1.33 i810_dri.c
--- drivers/i810/i810_dri.c 2002/12/10 01:27:04 1.33
+++ drivers/i810/i810_dri.c 2003/02/14 20:00:33
@@ -1218,3 +1218,84 @@
pI810-AccelInfoRec-NeedToSync = TRUE;
}
+
+Bool
+I810DRILeave(ScrnInfoPtr pScrn)
+{
+I810Ptr pI810 = I810PTR(pScrn);
+
+if (pI810-directRenderingEnabled) {
+ if (pI810-dcacheHandle != 0)
+ if (drmAgpUnbind(pI810-drmSubFD, pI810-dcacheHandle) != 0) {
+ xf86DrvMsg(pScrn-scrnIndex, X_ERROR,%s\n,strerror(errno));
+ return FALSE;
+ }
+ if (pI810-backHandle != 0)
+ if (drmAgpUnbind(pI810-drmSubFD, pI810-backHandle) != 0) {
+ xf86DrvMsg(pScrn-scrnIndex, X_ERROR,%s\n,strerror(errno));
+ return FALSE;
+ }
+ if (pI810-zHandle != 0)
+ if (drmAgpUnbind(pI810-drmSubFD, pI810-zHandle) != 0) {
+ xf86DrvMsg(pScrn-scrnIndex, X_ERROR,%s\n,strerror(errno));
+ return FALSE;
+ }
+ if (pI810-sysmemHandle != 0)
+ if (drmAgpUnbind(pI810-drmSubFD, pI810-sysmemHandle) != 0) {
+ xf86DrvMsg(pScrn-scrnIndex, X_ERROR,%s\n,strerror(errno));
+ return FALSE;
+
[Dri-devel] Re: Some DRM related changes for running multiple i810/830M X servers
On Fri, Feb 14, 2003 at 04:37:31 -0500, David Dawes wrote: I meant to add that it'd be good if something along the lines of Michel Dnzer's work to allow DRI to be reinitialised at VT switch was added in after 4.3. I'm curious why it didn't made it into the DRI trunk already. Michel's is good work, there's probably no reason that it shouldn't have been committed already. But I would like to see if we can make it more generic and work for the other DRI drivers too. Alan. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [XFree86] Re: Security in new drivers
On Fri, Feb 14, 2003 at 10:14:21PM +0100, Michel D?nzer wrote: Also keep in mind that access to the DRI can be controlled via ownership and permissions of the /dev/dri/cardX devices. On a private machine this is method is effective. On a public machine, such as a University lab, where all users must be considered hostile this is less effective. Thanks for the infomation. John Bartoszewski Email: [EMAIL PROTECTED] Senior Systems/Security Administrator .--. Instructional Laboratories: If you are not terrified : Department of Computing Science : you are just repeating yourself. : University of Alberta, Canada `._- Gilbert and George _.' --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
