Re: root priv and DRM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Jackson wrote: On Friday 17 June 2005 23:18, Ian Romanick wrote: Basically, user-mode should say to the kernel, Please initialize yourself with these tunable parameters. The kernel should then do whatever it wants and let user-mode know what it did. Actually right after I said that I remembered that drmAddMap is also used to set up the SAREA. So, maybe it shouldn't die, but I don't think it should need to do anything besides the DRM_SHM mappings, and those can be done without needing root. Why can't the kernel do that too? The only reason I didn't move that into the kernel in the MGA driver is that it would have required too much *more* code surgery in the DDX. I very strongly believe that the right model moving forward is for user-mode to say to the kernel, I beg of thee. Initialize thyne self. Over the years we've had serveral cases where the user / kernel initialization dance has needed to change, and this has resulted in numerous backwards-compatability nightmares. Moving the whole dance into the kernel won't eliminate all of them, but it will certainly reduce them (IMO). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtvO3X1gOwKyEAw8RAiMoAJ9/FatEuR3ObELyHgS6JsYDeBvVywCdHKTK gxhCmJLPX9eI9VOCN4jIhEs= =g0NF -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
On Monday 20 June 2005 00:03, Jon Smirl wrote: On 6/18/05, Adam Jackson [EMAIL PROTECTED] wrote: Obviously determining which sets of registers can be mapped through the drm is a card-by-card problem. Different cards have different register maps, by definition. But the DRI drivers work as a normal user _right_ _now_, and (modulo mach64 and possibly r300) they seem to be secure. There are more security holes than just restricting AddMap. If a normal user has register access to some cards (like the radeon), they can program the DMA controller to write into system RAM. You can use the ability to write into system RAM to gain root priv. I don't think we have good enough docs on any of the cards to says with 100% certainty that it is safe to allow a normal user access to the registers. You still sound really confused here. You say there are more holes than just AddMap, but then go on to describe the hole in AddMap. The DMA controller doesn't just magically show up in a process' address space. It has to have been set up first, either through drmAddMap from a process running as root (and subsequent authorization and drmMap sequence), or from DRM setup (and auth and drmMap). - ajax pgp7pQ1Q9v8ic.pgp Description: PGP signature
Re: hu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tino Keitel wrote: I installed the r300 driver with X.org and Mesa CVS and it works without problems until now. However, one app called mythtv tries use OpenGL and brought this error: libGL: XF86DRIGetClientDriverName: 4.0.1 r300 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r300_dri.so libGL error: __driCreateScreen() not defined in r300_dri.so! libGL error: unable to find driver: r300_dri.so Any chance to get this fixed? You need an updated version of libGL. The r300 driver only supported the new driver API, and the libGL installed on your system apparently does not support the new API. If you build one of the 'linux-dri-*' targets in Mesa CVS, you will get a new libGL in your lib directory. Try a test with 'LD_PRELOAD=path to Mesa build/lib/libGL.so some_gl_app' and see if that helps. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtvWpX1gOwKyEAw8RAnm1AJ0d5KnXigauTXZFLd2HLRTh9sT5YgCeNAii UJaRD89IfbKZwAkf7kwvLjs= =fbwY -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Smirl wrote: On 6/18/05, Adam Jackson [EMAIL PROTECTED] wrote: On Saturday 18 June 2005 15:22, Jon Smirl wrote: On 6/18/05, Adam Jackson [EMAIL PROTECTED] wrote: The point to notice here is that these registers generally segmented apart in the card's memory map. If all those trigger regs are within a single 4k range, then that's the only range you need to hide from userspace. Then this is a card by card problem. If user space needs to get to the registers, and we can't split the safe registers from the unsafe (security issues) ones, then the user space drivers also needs to run as root. You sound really confused here. Obviously determining which sets of registers can be mapped through the drm is a card-by-card problem. Different cards have different register maps, by definition. But the DRI drivers work as a normal user _right_ _now_, and (modulo mach64 and possibly r300) they seem to be secure. There are more security holes than just restricting AddMap. If a normal user has register access to some cards (like the radeon), they can program the DMA controller to write into system RAM. You can use the ability to write into system RAM to gain root priv. I don't think we have good enough docs on any of the cards to says with 100% certainty that it is safe to allow a normal user access to the registers. Right now the 3.2 MGA DRM does the AddMap for MMIO registers in the kernel. The map is added as DRM_READONLY (and never returned to user-mode, but that's another story). There are three things to take home here: 1. User-mode does not /need/ to AddMap *anything* *ever*. 2. The kernel can make the same access decisions for MMIO space that the X-server makes. If all or part of MMIO space needs to be read-only, fine. If all or part of MMIO space can be read-write, fine. The kernel is a big boy and can do all that magic too. 3. In the auth/master/root view of things, the mapping is done (indirectly) by the master, and the master has no opportunity to create a security hole (e.g., by creating the map with open permissions instead of read-only). Also notice that there is no need for a permanent mapping of MMIO space. The mapping is created when the master bootstraps the card for DMA. I'm still investigating things to see if it is possible to permanently create all of the maps needed. I know we can do it for registers and framebuffer. I just looked at sarea and that looks doable but I haven't written code to try it yet. I haven't gotten to the agp/pci maps yet. The problem with the SAREA is that user-mode can request an SAREA *larger* than the kernel knows about. For example, the user-mode drivers can add extra fields for the DDX and client-side drivers to communicate. The kernel doesn't need to know anything about what's in that memory. It just knows that user mode wants N bytes of shared space. If region is created in advance, there is no opportunity for user-mode to specify a size. HOWEVER, the map creation can still be done within the kernel during a bootstrap process. It would have been very easy for the MGA_DRM_BOOTSTRAP_DMA ioctl to create the mapping for the SAREA. If all of the maps are permanently created AddMap can be turned into a noop. s/If all of the maps are permanently created/When all map creation is moved into the kernel/ ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtv0vX1gOwKyEAw8RAiE/AKCNiuRCyeW/G/7qkiNrSLPnKnoiZgCdHWQb EKvDG2Ojcy+L/cos60EnQiU= =BXDR -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nicolai Haehnle wrote: I don't see any reason for mapping registers into userspace in the first place. Except for mode setting and related setup tasks (which aren't exactly performance critical), you'll never want to write to registers directly but go through a DMA'd command stream. Okay, there may be ancient hardware that doesn't support that mode of operation. But why not get rid of register maps completely for everything else? Some drivers (e.g., pre-3.2 MGA DRM) poll registers to know when the engine is idle. The radeon / r200 drivers can also fallback to something similar if interrupts are not available. I think some of the other drivers may do similar things. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtv2zX1gOwKyEAw8RApvqAJ9WKrppm2UgPLJXap9BXIZ6WeS4JgCgkLgw 25gQUiS+sUmxjl/DHPvdwjI= =5IVT -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
On Sad, 2005-06-18 at 23:30, Adam Jackson wrote: The issue is that drmAddMap, the function that sets up these maps, is currently run from the server during DDX bringup. These maps can just as easily be created during DRM init - and as a design issue, probably _should_ be created there. And if we do that, nothing else in the server-side libdrm API needs to be run as root (that I can see). In some cases the maps cannot come into existance until the X server has done the neccessary configuration to make the mapping of registers safe. Similarly there are dependancies at points like mode change that require care with what is exposed and active in order to avoid lockups. Currently the X server handles this and whoever handles this needs to be priviledged as they are able to get it wrong. Alan --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
On Sad, 2005-06-18 at 20:22, Jon Smirl wrote: Then this is a card by card problem. If user space needs to get to the registers, and we can't split the safe registers from the unsafe (security issues) ones, then the user space drivers also needs to run as root. Incorrect. See the via driver. The maps are just a useful performance trick for some cards. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: root priv and DRM
On Sad, 2005-06-18 at 16:54, Jon Smirl wrote: How about this as a safe first step: 1) Remove the general root capability check 2) Change the semantics of the root_only field on these calls to mean master only. 3) Push the root capability check into each of these IOCTL individually. 4) Leave a root capability check on the general switch code to per device IOCTLs if they are marked master only. This sounds like a way to make mistakes. Far better is to make the check a set of flags where 0/1 happen to keep their meaning ie #define DRM_NEED_ROOT 1 #define DRM_NEED_MASTER 2 now anything you miss/forget to touch won't go off in your hand so to speak. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: root priv and DRM
I very strongly believe that the right model moving forward is for user-mode to say to the kernel, I beg of thee. Initialize thyne self. Much of the initialization of chips is complex and messy and not neccessarily good kernel material. SAREA setup I agree seems an obvious kernel thing to do except that we need to figure who decided what size it should be. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan Cox wrote: On Sad, 2005-06-18 at 23:30, Adam Jackson wrote: The issue is that drmAddMap, the function that sets up these maps, is currently run from the server during DDX bringup. These maps can just as easily be created during DRM init - and as a design issue, probably _should_ be created there. And if we do that, nothing else in the server-side libdrm API needs to be run as root (that I can see). In some cases the maps cannot come into existance until the X server has done the neccessary configuration to make the mapping of registers safe. Similarly there are dependancies at points like mode change that require care with what is exposed and active in order to avoid lockups. Currently the X server handles this and whoever handles this needs to be priviledged as they are able to get it wrong. Do you have any specific examples of drivers that work like that? That seems really odd, and I'd like to understand that code better. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtxQEX1gOwKyEAw8RAi8WAKCHEZItwitzRELWFQd689jsf/jf/QCfY2zJ B+ID7xvGIPSvKzKaYlMl6OM= =GQ7C -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
On 6/20/05, Ian Romanick [EMAIL PROTECTED] wrote: The problem with the SAREA is that user-mode can request an SAREA *larger* than the kernel knows about. For example, the user-mode drivers can add extra fields for the DDX and client-side drivers to communicate. The kernel doesn't need to know anything about what's in that memory. It just knows that user mode wants N bytes of shared space. If region is created in advance, there is no opportunity for user-mode to specify a size. The size is still constained by SAREA_MAX right? If so the DRM driver can always allocate an SAREA of that size. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: root priv and DRM
On 6/20/05, Alan Cox [EMAIL PROTECTED] wrote: On Sad, 2005-06-18 at 16:54, Jon Smirl wrote: How about this as a safe first step: 1) Remove the general root capability check 2) Change the semantics of the root_only field on these calls to mean master only. 3) Push the root capability check into each of these IOCTL individually. 4) Leave a root capability check on the general switch code to per device IOCTLs if they are marked master only. This sounds like a way to make mistakes. Far better is to make the check a set of flags where 0/1 happen to keep their meaning ie #define DRM_NEED_ROOT 1 #define DRM_NEED_MASTER 2 now anything you miss/forget to touch won't go off in your hand so to speak. I ended up implementing something closer to this model instead of what I suggested. The patch is up a couple of messages in this thread. I made two columns, root and master, instead of using 1/2. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removing the root priv requirement from DRM
Ian Romanick wrote: The problem with the SAREA is that user-mode can request an SAREA *larger* than the kernel knows about. For example, the user-mode drivers can add extra fields for the DDX and client-side drivers to communicate. The kernel doesn't need to know anything about what's in that memory. It just knows that user mode wants N bytes of shared space. If region is created in advance, there is no opportunity for user-mode to specify a size. HOWEVER, the map creation can still be done within the kernel during a bootstrap process. It would have been very easy for the MGA_DRM_BOOTSTRAP_DMA ioctl to create the mapping for the SAREA. The current model actually allows for the server to create a number of shared memory areas and to specify a flag for the one that contains the hardware lock. If this model is kept then the size of the sarea created at kernel module initialization time could IMHO be known by the kernel. If dri is used for other applications with special needs that does not fit in the defalult size (for example the unichrome XvMC in the future) they could create an sarea mapping of their own and should not need to be root to do this, perhaps master though, since the map handle still needs to be communicated to all clients. This would require the drmAddMap or similar functionality to remain. Some drivers (e.g., pre-3.2 MGA DRM) poll registers to know when the engine is idle. The radeon / r200 drivers can also fallback to something similar if interrupts are not available. I think some of the other drivers may do similar things. Unichrome is doing this as well. Both OpenGL and XvMC drivers. /Thomas If all of the maps are permanently created AddMap can be turned into a noop. s/If all of the maps are permanently created/When all map creation is moved into the kernel/ ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCtv0vX1gOwKyEAw8RAiE/AKCNiuRCyeW/G/7qkiNrSLPnKnoiZgCdHWQb EKvDG2Ojcy+L/cos60EnQiU= =BXDR -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 1/1] drm/drm_os_linux: use wait_event_interruptible_timeout()
I already NAK'ed this patch, it breaks things.. so hardly janitorial stuff really... On Mon, 20 Jun 2005 [EMAIL PROTECTED] wrote: From: Nishanth Aravamudan [EMAIL PROTECTED] Rather than use custom code in DRM_WAIT_ON() to do exactly what wait_event_interruptible_timeout() does, use the function and just change the return values appropriately. Signed-off-by: Nishanth Aravamudan [EMAIL PROTECTED] Signed-off-by: Domen Puncer [EMAIL PROTECTED] NAK: Dave Airlie [EMAIL PROTECTED] -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 1/1] drm/drm_os_linux: use wait_event_interruptible_timeout()
On 20/06/05 15:52 -0700, Nishanth Aravamudan wrote: On 20.06.2005 [23:48:22 +0100], Dave Airlie wrote: I already NAK'ed this patch, it breaks things.. so hardly janitorial stuff really... On Mon, 20 Jun 2005 [EMAIL PROTECTED] wrote: From: Nishanth Aravamudan [EMAIL PROTECTED] Rather than use custom code in DRM_WAIT_ON() to do exactly what wait_event_interruptible_timeout() does, use the function and just change the return values appropriately. Signed-off-by: Nishanth Aravamudan [EMAIL PROTECTED] Signed-off-by: Domen Puncer [EMAIL PROTECTED] NAK: Dave Airlie [EMAIL PROTECTED] Indeed you did, sorry for the noise, Dave. Domen, can you drop this from your patchset? Must have missed it somehow before, sorry. Thanks, Nish --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 1/1] drm/drm_os_linux: use wait_event_interruptible_timeout()
On 20.06.2005 [23:48:22 +0100], Dave Airlie wrote: I already NAK'ed this patch, it breaks things.. so hardly janitorial stuff really... On Mon, 20 Jun 2005 [EMAIL PROTECTED] wrote: From: Nishanth Aravamudan [EMAIL PROTECTED] Rather than use custom code in DRM_WAIT_ON() to do exactly what wait_event_interruptible_timeout() does, use the function and just change the return values appropriately. Signed-off-by: Nishanth Aravamudan [EMAIL PROTECTED] Signed-off-by: Domen Puncer [EMAIL PROTECTED] NAK: Dave Airlie [EMAIL PROTECTED] Indeed you did, sorry for the noise, Dave. Domen, can you drop this from your patchset? Thanks, Nish --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[patch 1/1] drm/drm_os_linux: use wait_event_interruptible_timeout()
From: Nishanth Aravamudan [EMAIL PROTECTED]
Rather than use custom code in DRM_WAIT_ON() to do exactly
what wait_event_interruptible_timeout() does, use the function and just
change the return values appropriately.
Signed-off-by: Nishanth Aravamudan [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
drm_os_linux.h | 27 +++
1 files changed, 7 insertions(+), 20 deletions(-)
Index: quilt/drivers/char/drm/drm_os_linux.h
===
--- quilt.orig/drivers/char/drm/drm_os_linux.h
+++ quilt/drivers/char/drm/drm_os_linux.h
@@ -6,6 +6,7 @@
#include linux/interrupt.h /* For task queue support */
#include linux/delay.h
+#include linux/wait.h
/** File pointer type */
#define DRMFILE struct file *
@@ -121,26 +122,12 @@ do {
\
#define DRM_WAIT_ON( ret, queue, timeout, condition ) \
do { \
- DECLARE_WAITQUEUE(entry, current); \
- unsigned long end = jiffies + (timeout);\
- add_wait_queue((queue), entry); \
- \
- for (;;) { \
- __set_current_state(TASK_INTERRUPTIBLE);\
- if (condition) \
- break; \
- if (time_after_eq(jiffies, end)) { \
- ret = -EBUSY; \
- break; \
- } \
- schedule_timeout((HZ/100 1) ? HZ/100 : 1);\
- if (signal_pending(current)) { \
- ret = -EINTR; \
- break; \
- } \
- } \
- __set_current_state(TASK_RUNNING); \
- remove_wait_queue((queue), entry);\
+ long __ret; \
+ __ret = wait_event_interruptible_timeout(queue, condition, timeout); \
+ if (__ret == 0) \
+ ret = -EBUSY; \
+ else if (__ret == -ERESTARTSYS) \
+ ret = -EINTR; \
} while (0)
--
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM and permanent SAREA
Looking at driver/server all of the drivers are effectively creating
an sarea of size SAREA_MAX. I also grepped through x.org and could not
find any place where it is set to anything besides SAREA_MAX. There is
code that sets it to other values but it is ifdef'd out.
x.org ifdef's have this comment...
/* FIXME: Need to extend DRI protocol to pass this size back to
* client for SAREA mapping that includes a device private record
*/
[EMAIL PROTECTED] dri]$ grep -rI SAREASize * | grep =
fb/fb_dri.c: ctx-shared.SAREASize = SAREA_MAX;
i810/server/i810_dri.c: ctx-shared.SAREASize = 0x2000;
mga/server/mga_dri.c: ctx-shared.SAREASize = SAREA_MAX;
r128/server/r128_dri.c:ctx-shared.SAREASize = SAREA_MAX;
r200/server/radeon_dri.c: ctx-shared.SAREASize = SAREA_MAX;
r200/server/radeon_egl.c: disp-SAREASize = SAREA_MAX;
radeon/server/radeon_dri.c: ctx-shared.SAREASize = SAREA_MAX;
radeon/server/radeon_egl.c: disp-SAREASize = SAREA_MAX;
tdfx/server/tdfx_dri.c: ctx-shared.SAREASize = SAREA_MAX;
unichrome/server/via_dri.c:ctx-shared.SAREASize =
((sizeof(drm_sarea_t) + 0xfff) 0x1000);
unichrome/server/via_dri.c:ctx-shared.SAREASize = SAREA_MAX;
Exception is i810 at 0x2000 which is what SAREA_MAX is minimally
defined too so i810 can be changed. The odd line in the via driver is
if'd out and SAREA_MAX is used.
Given that everyone is using SAREA_MAX I can modify DRM to pre-create
a SAREA_MAX region and return it from AddMap instead of making a new
one. Doing it that way will keep the old binaries working.
New apps use a loop similar to this instead of doing AddMap:
for (i = 0;; i++) {
if ((rc = drmGetMap(display-drmFD, i, offset, size, type,
flags, handle, mtrr)) != 0)
break;
if (type == DRM_SHM {
drmMap(fd, handle, size, (drmAddressPtr)display-sarea);
break;
}
}
This lets new non-root apps avoid calling AddMap for sarea. The AddMap
call has to stay marked as root only.
Any objections to why this won't work?
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300/ppc] lockups
On Sat, 18 Jun 2005, Johannes Berg wrote: Hi, I just tried the latest r300 cvs code (with current mesa cvs, latest Xorg snapshot) but all I get is a lockup as soon as the X server starts. If I have debugging enabled, I get a loop of radeon_do_cp_idle calls. Hardware is: :00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 255 (2000ns min), Cache Line Size: 0x08 (32 bytes) Interrupt: pin A routed to IRQ 48 Region 0: Memory at b800 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 802400 [size=256] Region 2: Memory at b000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at f100 [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=80 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP- GART64- 64bit- FW- Rate=none Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Any idea where I should start looking for the source of the lockups or what else to do? The problem is likely either due to the radeon memory controller - in particular registers like MC_FB_LOCATION MC_AGP_LOCATION - or some sort of AGP issue with ring buffer not working properly. The 2d support should work - the fact that it does not indicates a screw up someplace obvious. Check that the registers mentioned above are programmed to what Xserver and drm driver think they are. In particular look for endianness errors, though this might not be it.. To avoid lockups you can modify Xserver code to put exit(0) just after those are set - you will need a separate box to ssh in as the monitor will not be in a usable state. best Vladimir Dergachev Thanks, johannes --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
