[2.6 patch] DRM: misc cleanup
On Tue, Feb 01, 2005 at 09:16:16PM +1100, Dave Airlie wrote: I'll nack this patch for now Adrian, but I'm going to bring all these changes into the DRM tree as soon as I can.. one of the functions you removed pointed out a bug in the i810/i830/i915 drivers (granted no-one uses pageflip in those drivers but still should fix it..), I'm going to put the through drm CVS first... I've seen that part of this is already in recent kernels. Below is as a FYI a version against 2.6.12-rc2-mm3. Thanks, Dave. cu Adrian -- snip -- This patch contains the following cleanups: - make needlessly global functions static - remove the following unused global functions: - drm_fops.c: drm_read - i915_dma.c: i915_do_cleanup_pageflip - via_ds.c: via_mmDumpMemInfo - via_ds.c: via_mmAddRange - via_ds.c: via_mmReserveMem - via_ds.c: via_mmFreeReserved - via_ds.c: via_mmDestroy - remove the followig unused global variable: - via_mm.c: VIA_DEBUG Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- drivers/char/drm/ati_pcigart.c |2 drivers/char/drm/drmP.h| 22 -- drivers/char/drm/drm_auth.c|4 - drivers/char/drm/drm_bufs.c| 12 +-- drivers/char/drm/drm_context.c |6 - drivers/char/drm/drm_drv.c |9 +- drivers/char/drm/drm_fops.c| 10 --- drivers/char/drm/drm_irq.c |2 drivers/char/drm/drm_lock.c| 12 ++- drivers/char/drm/drm_proc.c|2 drivers/char/drm/drm_stub.c| 92 ++-- drivers/char/drm/drm_vm.c | 10 +-- drivers/char/drm/i810_dma.c| 24 +++ drivers/char/drm/i810_drv.h|1 drivers/char/drm/i830_dma.c| 20 +++--- drivers/char/drm/i830_drv.c|2 drivers/char/drm/i830_drv.h|2 drivers/char/drm/i830_irq.c|4 - drivers/char/drm/i915_dma.c| 60 +++--- drivers/char/drm/i915_drv.c|2 drivers/char/drm/i915_drv.h| 10 --- drivers/char/drm/i915_irq.c|4 - drivers/char/drm/r128_state.c |2 drivers/char/drm/via_dma.c |4 - drivers/char/drm/via_drv.h |2 drivers/char/drm/via_ds.c | 108 - drivers/char/drm/via_ds.h |8 -- drivers/char/drm/via_map.c |2 drivers/char/drm/via_mm.c | 14 ++-- drivers/char/drm/via_mm.h |5 - 30 files changed, 149 insertions(+), 308 deletions(-) --- linux-2.6.12-rc2-mm3-full/drivers/char/drm/drmP.h.old 2005-04-18 03:54:16.0 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/char/drm/drmP.h 2005-04-18 03:54:49.0 +0200 @@ -774,8 +774,6 @@ /* Driver support (drm_drv.h) */ extern int drm_init(struct drm_driver *driver); extern void drm_exit(struct drm_driver *driver); -extern int drm_version(struct inode *inode, struct file *filp, - unsigned int cmd, unsigned long arg); extern int drm_ioctl(struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg); extern long drm_compat_ioctl(struct file *filp, @@ -785,21 +783,13 @@ /* Device support (drm_fops.h) */ extern int drm_open(struct inode *inode, struct file *filp); extern int drm_stub_open(struct inode *inode, struct file *filp); -extern int drm_open_helper(struct inode *inode, struct file *filp, - drm_device_t *dev); extern int drm_flush(struct file *filp); extern int drm_fasync(int fd, struct file *filp, int on); extern int drm_release(struct inode *inode, struct file *filp); /* Mapping support (drm_vm.h) */ -extern void drm_vm_open(struct vm_area_struct *vma); -extern void drm_vm_close(struct vm_area_struct *vma); -extern void drm_vm_shm_close(struct vm_area_struct *vma); -extern int drm_mmap_dma(struct file *filp, - struct vm_area_struct *vma); extern int drm_mmap(struct file *filp, struct vm_area_struct *vma); extern unsigned int drm_poll(struct file *filp, struct poll_table_struct *wait); -extern ssize_t drm_read(struct file *filp, char __user *buf, size_t count, loff_t *off); /* Memory management support (drm_memory.h) */ #include drm_memory.h @@ -854,9 +844,6 @@ extern int drm_rmctx( struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg ); -extern int drm_context_switch(drm_device_t *dev, int old, int new); -extern int drm_context_switch_complete(drm_device_t *dev, int new); - extern int drm_ctxbitmap_init( drm_device_t *dev ); extern void drm_ctxbitmap_cleanup( drm_device_t *dev ); extern void drm_ctxbitmap_free( drm_device_t *dev, int ctx_handle ); @@ -874,9 +861,6 @@
Re: Radeon 9200SE hangs
On Sat, 16 Apr 2005, khaqq wrote: I had lockups a few months ago with my FireGL8800 with X/DRI, I gave up trying to find a stable X/DRI combination after trying 3 X versions and about 20 DRI snapshots. I'm *not* saying DRI isn't good, it used to work perfectly on my 7500. But the R200 was never stable here (I've had it for ~6 months now). I have to agree with you. I complained about the r200 driver some months ago. I was told to try to track down the time when the instability of the r200 driver started (some develorers suggested the end of September, 2004).Unfortunately, I wasn't able to compile older CVS snapshots on my debian sid system. It's very strange, I don't think that X.org CVS was broken for months... (I tried compiling snapshots from 2004.08.31 to 2004.11.30 without any success...) I'm using ATI-drivers atm and I've not seen a single crash with those. If debug logs are interesting to you, or to any X/DRI developpers, I'll go back to DRI and try to generate them if you tell me how. I'm happy to say my PC doesn't seem to have any hardware problem (as it was suggested on dri-devel) since going to ati-drivers solved *all* the stability issues I had with X+DRI (and before switching from the 7500 to the 8800, it was stable ; and it was still stable in 3D apps in windows (yuck) after the switch). Maybe if all users seeing crashes generated a debug log and put it online for all DRI developpers to see, finding a common denominator would be easier... I use Descent3 for testing. With recent snapshots it's getting harder to crash the game. Some months ago a simple X restart was enough to crash Descent3 (and of course the X server) in a few seconds. Nowadays I have to switch to the microwave gun and fire some dozen waves to crash X. It's 100% reproducible, so I offered my help to create gdb backtraces, but one of the DRI developers (Michael Daenzer, if I remember correctly) pointed out that gdb backtraces won't help diagnosing GPU lockups. Geller Sandor [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM_WAIT_ON changed behaviour.
Hi! The macro DRM_WAIT_ON changed behaviour. In earlier DRMs it checked every HZ for condition in case it was slightly missed. This doesn't happen anymore, which means some applications freezes for about 3 secs, when they just missed an interrupt. This in itself is a little bit strange since, if the following occurs: * Check condition * if false, go to sleep and DRM_WAKEUP is called by the interrupt handler in between those two, the sleep should never occur, which now it seems to do anyway. Could we pls have the old behaviour back? /Thomas --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM_WAIT_ON changed behaviour.
This in itself is a little bit strange since, if the following occurs: * Check condition * if false, go to sleep and DRM_WAKEUP is called by the interrupt handler in between those two, the sleep should never occur, which now it seems to do anyway. Is the current code still using the deprecated sleep_on type functions ? --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4513] New: Radeon driver in 2.6.10 through 2.6.11.6 fails in DRI mode. Kernel 2.6.9 works fine.
http://bugme.osdl.org/show_bug.cgi?id=4513 Summary: Radeon driver in 2.6.10 through 2.6.11.6 fails in DRI mode. Kernel 2.6.9 works fine. Kernel Version: 2.6.10 through 2.6.11.6 Status: NEW Severity: blocking Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Distribution: Fedora Core 2 Fedora Core 3 Hardware Environment: Sharp MM20 Laptop Transmetta Efficeon Processor, ATI Mobile Radeon 00:00.0 Host bridge: Transmeta Corporation: Unknown device 0060 00:01.0 PCI bridge: Transmeta Corporation: Unknown device 0061 00:02.0 PCI bridge: ALi Corporation M5249 HTT to PCI Bridge 00:03.0 ISA bridge: ALi Corporation M1563 HyperTransport South Bridge (rev 20) 00:03.1 Bridge: ALi Corporation M7101 Power Management Controller [PMU] 00:04.0 Multimedia audio controller: ALi Corporation M5455 PCI AC-Link Controller Audio Device (rev 03) 00:06.0 Network controller: Intersil Corporation Intersil ISL3890 [Prism GT/Prism Duette] (rev 01) 00:09.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 81) 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0e.0 IDE interface: ALi Corporation M5229 IDE (rev c5) 00:0f.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) 00:0f.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) 00:0f.3 USB Controller: ALi Corporation USB 2.0 Controller (rev 01) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY Software Environment: Fedora Core 3 Broken kernels include: custom built 2.6.11.6 Kernel.org kernel, and all FC3 released 2.6.10-* kernels. Working kernel: FC3 2.6.9-1.724_FC3 XWindows: xorg-x11-6.8.2-1.FC3.13 Problem Description: When running any 2.6.10 or later kernel with DRI enabled the screen locks to a point where you only have an x-cursor for the mouse which does respond to the mouse, and 4 screwed up minature images of the BIOS boot screen along the top of the LCD with the rest of the LCD being black. All though the mouse responds, there is no keyboard response. I can ssh in to cleanly shutdown the machine, so it doesn't lock the system, only the xserver. There are no errors in the xorg log files to report. DRI works prefectly fine with the 2.6.9 and before series kernels. Please see these two Fedora Core bugs as reference, the first bug includes a picture of what the screen looks like during a failure: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144867 (please ignore the earlier posts about the 2.6.9 kernel, was never able to reproduce for that kernel version) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152312 Steps to reproduce: 1. Boot a 2.6.10 or greater kernel with DRI enabled in the xorg.conf file. 2. Boot into Xwindows from init 5 or run startx from init 3 3. Watch your screen go screwy and still have a moving mouse cursor but no keyboard. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM_WAIT_ON changed behaviour.
Alan Cox wrote:
This in itself is a little bit strange since, if the following occurs:
* Check condition
* if false, go to sleep
and DRM_WAKEUP is called by the interrupt handler in between those two,
the sleep should never occur, which now it seems to do anyway.
Is the current code still using the deprecated sleep_on type functions ?
#define DRM_WAIT_ON( ret, queue, timeout, condition ) \
do {\
long __ret; \
__ret = wait_event_interruptible_timeout(queue, condition,
timeout); \
if (__ret == 0) \
ret = -EBUSY; \
else if (__ret == -ERESTARTSYS) \
ret = -EINTR; \
} while (0)
^ New implementation ^
#define DRM_WAKEUP( queue ) wake_up_interruptible( queue )
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon 9200SE hangs
On Mon, 18 Apr 2005 18:44:17 +0200 (CEST) Geller Sandor [EMAIL PROTECTED] wrote: On Mon, 18 Apr 2005, Michel [ISO-8859-1] Dänzer wrote: Did you post the problems you encountered? Yes, on Mon, 14 Feb 2005. You were one of the recipients :)) There was a thread 'OpenGL apps causes frequent system locks' on dri-devel. Define 'a simple X restart'. Do you mean running Descent 3 right after restarting the X server? Issued startx, exited X. Issued startx again, started D3, played for a while. I wrote my step-by-step test in one of the mails I sent to this thread. Nowadays I have to switch to the microwave gun and fire some dozen waves to crash X. It's 100% reproducible, so I offered my help to create gdb backtraces, but one of the DRI developers (Michael Daenzer, if I remember correctly) pointed out that gdb backtraces won't help diagnosing GPU lockups. Yeah, but maybe he was thinking of DRM debugging output or something. That can be useful, but is still tedious to wade through in the best case. Nice to see that you refer to yourself in 3rd person :)) If I can help with backtraces/ debug info, don't hesitate, tell me, what kind of information are you interested in! Same here, really. --- 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_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4513] Radeon driver in 2.6.10 through 2.6.11.6 fails in DRI mode. Kernel 2.6.9 works fine.
http://bugme.osdl.org/show_bug.cgi?id=4513 [EMAIL PROTECTED] changed: What|Removed |Added Owner|[EMAIL PROTECTED] |[EMAIL PROTECTED] |bugs.osdl.org | Severity|blocking|normal Component|Video(DRI) |Video(AGP) --- Additional Comments From [EMAIL PROTECTED] 2005-04-18 10:18 --- Ok, I tried something new, and narrowed the issue down to something with the AGP driver used. By using Option BusType PCI and forcing the xorg to use the AGP card as a PCI card, everything works as expected. The only issue being that it is slower than Using AGP mode. I'm updating this bug so that is is now listed under Drivers Video (AGP) --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon 9200SE hangs
On Mon, 2005-18-04 at 18:44 +0200, Geller Sandor wrote: On Mon, 18 Apr 2005, Michel [ISO-8859-1] Dnzer wrote: Did you post the problems you encountered? Yes, on Mon, 14 Feb 2005. You were one of the recipients :)) There was a thread 'OpenGL apps causes frequent system locks' on dri-devel. I mean the problems compiling older snapshots. Define 'a simple X restart'. Do you mean running Descent 3 right after restarting the X server? Issued startx, exited X. Issued startx again, started D3, played for a while. But it doesn't happen if you only start the X server once? I wrote my step-by-step test in one of the mails I sent to this thread. I don't see that in your other post to *this* thread. Do you mean the thread you started months ago? Nowadays I have to switch to the microwave gun and fire some dozen waves to crash X. It's 100% reproducible, so I offered my help to create gdb backtraces, but one of the DRI developers (Michael Daenzer, if I remember correctly) pointed out that gdb backtraces won't help diagnosing GPU lockups. Yeah, but maybe he was thinking of DRM debugging output or something. That can be useful, but is still tedious to wade through in the best case. Nice to see that you refer to yourself in 3rd person :)) No, I was referring to the part of the post that started this thread that I quoted just above what you quoted here. If I can help with backtraces/ debug info, don't hesitate, tell me, what kind of information are you interested in! If you can reproduce the problem with DRM debugging output enabled, send the output, e.g. But don't put your hopes too high, this is highly non-trivial stuff. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
X server steals DRI lock
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 0x8002, with 2 corresponding to the correct DRM context. Upon exit from the polling function, sometimes the X server has stolen the lock, 0x8001, 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? --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X server steals DRI lock
Thomas Hellström 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
before and just after it takes the
hardware lock: The sleep before is necessary so that other display
applications get some unlocked CPU time.
/* Lock the hardware and validate our state.
*/
#define LOCK_HARDWARE(vmesa)\
do {\
char __ret = 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
error, and, with unichrome dri,
terminate the application:
[drm:via_cmdbuffer] *ERROR* via_cmdbuffer called without lock held,
held 0 owner d2c4a580 d7792680
Again, presumably the X server stole the lock.
Could somebody verify whether this is happening also on other
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=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
---
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_ide95alloc_id396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Cannot run fgfs using via/unichrome: illegal DMA data
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: 0xfff0 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 --- 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM_WAIT_ON changed behaviour.
The macro DRM_WAIT_ON changed behaviour. In earlier DRMs it checked every HZ for condition in case it was slightly missed. This doesn't happen anymore, which means some applications freezes for about 3 secs, when they just missed an interrupt. This in itself is a little bit strange since, if the following occurs: * Check condition * if false, go to sleep and DRM_WAKEUP is called by the interrupt handler in between those two, the sleep should never occur, which now it seems to do anyway. Could we pls have the old behaviour back? This was as a result of a patch from Nishanth who I've cc'ed, I was a bit dodgy on this patch and haven't put it in the kernel for that reason, so I put it in CVS to see if it would cause problems it looks like it has... You can revert drm_os_linux.h to version 1.30 and see if it still works fine.. Alan, The old code uses schedule_timeout and signal_pending along with a waitqueue, I don't think it has been deprecated in anyway.. as in what is in the kernel is what I consider the current code and Christoph hasn't complained :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X server steals DRI lock
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 0x8002, with 2 corresponding to the correct DRM context. Upon exit from the polling function, sometimes the X server has stolen the lock, 0x8001, 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. --- 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM_WAIT_ON changed behaviour.
I agree, patch should be reverted. The difference between my change and the previous code, fundamentally, is that mine slept as long as possible relative to the passed in timeout until either a signal or wait-queue event happened; the original code, in contrast, slept for a fixed amount of time (10 ms or 1 jiffy, whichever is longer) up to a specified total time. Okay I reverted it... Dave. You can revert drm_os_linux.h to version 1.30 and see if it still works fine.. Alan, The old code uses schedule_timeout and signal_pending along with a waitqueue, I don't think it has been deprecated in anyway.. as in what is in the kernel is what I consider the current code and Christoph hasn't complained :-) The old code is fine -- I just was trying to consolidate the users of HZ in to one place. Thanks, Nish -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 Radeon 9800 Pro lockups
Vladimir Dergachev wrote: Can you try if reverting revision 1.6 of radeon_cursor.c in X.org CVS makes a difference? Reverting this file to version 1.5 caused the cursor to appear after the lockup, I could move it but everything else was fudged. During this test, I flipped my mouse over to make sure it would not move. It would seem that the cursor is related to the lockups I have experienced. One more suggestion: try turning SilkenMouse off. I am not certain which option does it (I am away at a conference with really poor internet access), search google and the Xorg manuals. Turning this option off might make mouse movements a bit jerkier, but will improve synchronicity in Xserver access to hardware.. I have tried that with no change, this problem does not seem to be mouse-related since I take precautions to get no events from the mouse. Anyway, here is a log of a sample lockup, in my newbie opinion, it would seem to be a locking problem. http://dastyle.net/joe/kern.log.bz2 Cheers, Jonathan signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Re: X server steals DRI lock
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 0x8002, with 2 corresponding to the correct DRM context. Upon exit from the polling function, sometimes the X server has stolen the lock, 0x8001, 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
