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
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
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,
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
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
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
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
http://bugme.osdl.org/show_bug.cgi?id=4513
[EMAIL PROTECTED] changed:
What|Removed |Added
Owner|[EMAIL PROTECTED] |[EMAIL PROTECTED]
|bugs.osdl.org
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.
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,
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
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
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
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,
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
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
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
17 matches
Mail list logo
