On Mon, 18 Apr 2005, Michel [ISO-8859-1] Dänzer wrote:
> On Mon, 2005-18-04 at 18:44 +0200, Geller Sandor 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 :)) The
Dave Airlie wrote:
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
Thomas Hellström wrote:
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
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
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
> 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
>
On Tue, Apr 19, 2005 at 12:03:15AM +0100, Dave Airlie wrote:
>
> >
> > 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
>
>
> 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, s
>
> 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 s
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 ve
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 di
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, someti
On Mon, 2005-18-04 at 18:44 +0200, Geller Sandor 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
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, 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 f
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=3024
[EMAIL PROTECTED] changed:
What|Removed |Added
--
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
On Mon, 2005-18-04 at 14:45 +0200, Geller Sandor wrote:
> 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* sayi
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 wou
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 cu
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 PROTE
> 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 t
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,
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 w
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 i
25 matches
Mail list logo
