From: <uni...@sh...> - 2005-04-18 19:20:58
|
Hi! I have an application that takes the hardware DRI lock and then does an usleep(1) while polling hardware status. Entering the polling function, I've verified that the lock is indeed taken 0x80000002, with 2 corresponding to the correct DRM context. Upon exit from the polling function, sometimes the X server has stolen the lock, 0x80000001, or even 0x1, signalling the X server already did it's processing. The lock has never been touched by the application in-between. This, later on results in a drm error when the application tries to submit an AGP command buffer while the X server has stolen the lock. [drm:via_cmdbuffer] *ERROR* via_cmdbuffer called without lock held, held -2147483648 owner d2c4a580 d7792780 The occurence is quite rare (this is xine with the via xvmc library), and it happens when a window is moved over xine's output window, triggering a lot of hardware redraws and at the same time a lot of X server activity. I'm not sure what causes this, but IMHO it's quite serious. drm CVS as of today. xorg 6.8.2 Mandrake patched. Anybody having an idea? |
From: <uni...@sh...> - 2005-04-18 20:17:53
|
Thomas Hellstr=F6m wrote: > Hi! > > I'm not sure what causes this, but IMHO it's quite serious. > OK, Easy to reproduce also with Mesa DRI. I did the following alteration to via_context.h, so that it sleeps just=20 before and just after it takes the hardware lock: The sleep before is necessary so that other display=20 applications get some unlocked CPU time. /* Lock the hardware and validate our state.=20 */ #define LOCK_HARDWARE(vmesa) \ do { \ char __ret =3D 0; \ usleep(1); /* Here */ \ DRM_CAS(vmesa->driHwLock, vmesa->hHWContext, \ (DRM_LOCK_HELD|vmesa->hHWContext), __ret); \ if (__ret) \ viaGetLock(vmesa, 0); \ usleep(1); /* Here */ \ } while (0) Then running glxgears while resizing the window will give the same drm=20 error, and, with unichrome dri, terminate the application: [drm:via_cmdbuffer] *ERROR* via_cmdbuffer called without lock held,=20 held 0 owner d2c4a580 d7792680 Again, presumably the X server stole the lock. Could somebody verify whether this is happening also on other=20 architectures? Currently I'm running a Prescott Celeron on a PM800 Unichrome Pro. Has there been any changes to the drm kernel locking code lately? /Thomas > drm CVS as of today. > xorg 6.8.2 Mandrake patched. > > Anybody having an idea? > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users= . > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick > --=20 > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel |
From: Luke D. <lu...@di...> - 2005-04-18 22:56:40
|
I'm attempting to run fgfs (FlightGear) using the VIA/Unichrome driver. When I do so, fgfs fails at startup saying: fire_buffer: DRM_VIA_CMDBUFFER returned -22 dmesg reports: [drm:investigate_hazard] *ERROR* Illegal DMA data: 0xfffffff0 Other programs like glxgears seem to work fine. My drm.ko version is 1.0.0 20040925 My via.ko version is 2.6.0 20050328 I'm using X.Org version: 6.8.2 on linux kernel 2.6.11. The unichrome server module is release 30. Any suggestions on what could be going wrong or how I should proceed? Thanks Luke Diamand |
From: Benno S. <ben...@ju...> - 2005-04-19 13:17:17
|
Luke Diamand wrote: > I'm attempting to run fgfs (FlightGear) using the VIA/Unichrome > driver. When I do so, fgfs fails at startup saying: > > fire_buffer: DRM_VIA_CMDBUFFER returned -22 This was a problem in Mesa. A workaround has been comitted to CVS a few days ago. Try a cvs update and rebuild and please report back whether this solved it. Benno |
From: Luke D. <lu...@di...> - 2005-04-19 18:27:18
|
Benno Schulenberg wrote: > Luke Diamand wrote: > >>I'm attempting to run fgfs (FlightGear) using the VIA/Unichrome >>driver. When I do so, fgfs fails at startup saying: >> >>fire_buffer: DRM_VIA_CMDBUFFER returned -22 > > > This was a problem in Mesa. A workaround has been comitted to CVS a > few days ago. Try a cvs update and rebuild and please report back > whether this solved it. That's better. It starts up now. Graphics are a bit odd (flickering) but other than that seems fine. Thanks! Luke > > Benno > > > ------------------------------------------------------- > This SF.Net email is sponsored by: New Crystal Reports XI. > Version 11 adds new functionality designed to reduce time involved in > creating, integrating, and deploying reporting solutions. Free runtime info, > new features, or free trial, at: http://www.businessobjects.com/devxi/728 > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Thomas <uni...@sh...> - 2005-04-19 13:22:05
|
Hi! > I'm attempting to run fgfs (FlightGear) using the VIA/Unichrome driver. > When I do so, fgfs fails at startup saying: > > fire_buffer: DRM_VIA_CMDBUFFER returned -22 > > dmesg reports: > > [drm:investigate_hazard] *ERROR* Illegal DMA data: 0xfffffff0 > > Other programs like glxgears seem to work fine. > > My drm.ko version is 1.0.0 20040925 > My via.ko version is 2.6.0 20050328 > I'm using X.Org version: 6.8.2 on linux kernel 2.6.11. > The unichrome server module is release 30. > > Any suggestions on what could be going wrong or how I should proceed? > > Thanks > Luke Diamand > A bug in the Mesa Unichrome driver that has recently been fixed. However, there are still some rendering probs. Try latest Mesa CVS. /Thomas |
From: Dave A. <ai...@li...> - 2005-04-18 23:18:51
|
> > I have an application that takes the hardware DRI lock and then does an > usleep(1) while polling hardware status. Entering the polling function, I've > verified that the lock is indeed taken > 0x80000002, with 2 corresponding to the correct DRM context. Upon exit from > the polling function, sometimes the X server has stolen the lock, 0x80000001, > or even 0x1, signalling the X server already did it's processing. > The lock has never been touched by the application in-between. Don't sleep holding the lock unless you have a good reason, the X server will take it back forcibly if it can't get it nicely as it is in charge and a locked up Xserver waiting for a client is a bad idea in terms of sharing resources.. it would be a DoS if a DRI client can just take the lock and sit on it .. take a look at the programs/Xserver/GL/dri/dri.c:DRISpinLockTimeout /* Didn't get lock, so take it. The worst that can happen is that there is some garbage written to the wrong part of the framebuffer that a refresh will repair. That's undesirable, but better than locking the server. This should be a very rare event. */ is a comment from that function.. Dave. |
From: <uni...@sh...> - 2005-04-19 05:31:47
|
Hi! Dave Airlie wrote: >>I have an application that takes the hardware DRI lock and then does an >>usleep(1) while polling hardware status. Entering the polling function, I've >>verified that the lock is indeed taken >>0x80000002, with 2 corresponding to the correct DRM context. Upon exit from >>the polling function, sometimes the X server has stolen the lock, 0x80000001, >>or even 0x1, signalling the X server already did it's processing. >>The lock has never been touched by the application in-between. >> >> > >Don't sleep holding the lock unless you have a good reason, the X server >will take it back forcibly if it can't get it nicely as it is in charge >and a locked up Xserver waiting for a client is a bad idea in terms of >sharing resources.. it would be a DoS if a DRI client can just take the >lock and sit on it .. > >take a look at the programs/Xserver/GL/dri/dri.c:DRISpinLockTimeout > /* Didn't get lock, so take it. The worst > that can happen is that there is some > garbage written to the wrong part of >the > framebuffer that a refresh will repair. > That's undesirable, but better than > locking the server. This should be a > very rare event. */ >is a comment from that function.. > >Dave. > > I don't think this is the cause of the problem, since what you're referring to above is IIRC a drawable spinlock, not the heavyweight hardware lock. If a client takes the heavyweight lock and then sleeps even for a couple of seconds, the X server should freeze during this time, which it also usually does. In this case (the Mesa testcase) we're talking the minimal amount of sleep available (1ms on 2.6 kernels), and from what I can see in the above file, the X server uses DRM_LOCK, which immediately calls the kernel if the cmpxchg fails. /Thomas |
From: <uni...@sh...> - 2005-04-19 06:05:12
|
Thomas Hellstr=F6m wrote: > I don't think this is the cause of the problem, since what you're=20 > referring to above is IIRC a drawable spinlock, not the heavyweight=20 > hardware lock. > > If a client takes the heavyweight lock and then sleeps even for a=20 > couple of seconds, the X server should freeze during this time, which=20 > it also usually does. In this case (the Mesa testcase) we're talking=20 > the minimal amount of sleep available (1ms on 2.6 kernels), and from=20 > what I can see in the above file, the X server uses DRM_LOCK, which=20 > immediately calls the kernel if the cmpxchg fails. > > /Thomas > Since the error messages I get indicate that indeed the filp associated=20 with the HW lock has changed, the stealing has probably occured in the=20 kernel DRM code. I'll try to check back with the old 2.6-series drm. /Thomas > > |
From: <uni...@sh...> - 2005-04-19 19:23:17
|
Index: linux/drm_drv.h =================================================================== RCS file: /cvs/dri/drm/linux/drm_drv.h,v retrieving revision 1.93 diff -u -r1.93 drm_drv.h --- linux/drm_drv.h 31 Oct 2004 15:16:43 -0000 1.93 +++ linux/drm_drv.h 19 Apr 2005 19:08:41 -0000 @@ -1048,7 +1048,10 @@ } current->state = TASK_RUNNING; remove_wait_queue( &dev->lock.lock_queue, &entry ); - + + DRM_DEBUG( "%d %s\n", lock.context, ret ? "interrupted" : "has lock" ); + if (ret) return ret; + sigemptyset( &dev->sigmask ); sigaddset( &dev->sigmask, SIGSTOP ); sigaddset( &dev->sigmask, SIGTSTP ); @@ -1062,19 +1065,19 @@ if (dev->fn_tbl.dma_ready && (lock.flags & _DRM_LOCK_READY)) dev->fn_tbl.dma_ready(dev); - if ( dev->fn_tbl.dma_quiescent && (lock.flags & _DRM_LOCK_QUIESCENT )) - return dev->fn_tbl.dma_quiescent(dev); - - + if (dev->fn_tbl.dma_quiescent && (lock.flags & _DRM_LOCK_QUIESCENT)) { + if (dev->fn_tbl.dma_quiescent(dev)) { + DRM_DEBUG( "%d waiting for DMA quiescent\n", lock.context); + return DRM_ERR(EBUSY); + } + } + if ( dev->fn_tbl.kernel_context_switch && dev->last_context != lock.context ) { dev->fn_tbl.kernel_context_switch(dev, dev->last_context, lock.context); } - - DRM_DEBUG( "%d %s\n", lock.context, ret ? "interrupted" : "has lock" ); - - return ret; + return 0; } /** Index: linux-core/drm_lock.c =================================================================== RCS file: /cvs/dri/drm/linux-core/drm_lock.c,v retrieving revision 1.14 diff -u -r1.14 drm_lock.c --- linux-core/drm_lock.c 18 Oct 2004 14:16:41 -0000 1.14 +++ linux-core/drm_lock.c 19 Apr 2005 19:08:41 -0000 @@ -99,6 +99,9 @@ current->state = TASK_RUNNING; remove_wait_queue(&dev->lock.lock_queue, &entry); + DRM_DEBUG( "%d %s\n", lock.context, ret ? "interrupted" : "has lock" ); + if (ret) return ret; + sigemptyset(&dev->sigmask); sigaddset(&dev->sigmask, SIGSTOP); sigaddset(&dev->sigmask, SIGTSTP); @@ -111,8 +114,12 @@ if (dev->driver->dma_ready && (lock.flags & _DRM_LOCK_READY)) dev->driver->dma_ready(dev); - if (dev->driver->dma_quiescent && (lock.flags & _DRM_LOCK_QUIESCENT)) - return dev->driver->dma_quiescent(dev); + if (dev->driver->dma_quiescent && (lock.flags & _DRM_LOCK_QUIESCENT)) { + if (dev->driver->dma_quiescent(dev)) { + DRM_DEBUG( "%d waiting for DMA quiescent\n", lock.context); + return DRM_ERR(EBUSY); + } + } if (dev->driver->kernel_context_switch && dev->last_context != lock.context) { @@ -120,9 +127,7 @@ lock.context); } - DRM_DEBUG("%d %s\n", lock.context, ret ? "interrupted" : "has lock"); - - return ret; + return 0; } /** |