I am getting a 100% reproducable lockup on a pull of CVS from this
morning (10 Nov 2002).
When the kernel DRM module is loaded, and I do a ALT-CTRL-KP- to change
resolutions, the system locks up.
Apparently, the card is always reporting busy
(drmCommandNone(DRM_RADEON_CP_IDLE) is always
On Son, 2002-11-10 at 18:56, David D. Hagood wrote:
I am getting a 100% reproducable lockup on a pull of CVS from this
morning (10 Nov 2002).
When the kernel DRM module is loaded, and I do a ALT-CTRL-KP- to change
resolutions, the system locks up.
And probably on VT switches as well? Does
Here's the workaround for the Radeon 7500 lockup. I won't dignify it by
calling it a fix until I've investigated the actual commands being sent and
determined whether there's a better way of fixing it.
--
Tim Smith ([EMAIL PROTECTED])
Imperial Royal Guard foils attempted theft of Palpatine's
On Tuesday 02 Jul 2002 11:57 pm, Michel Dänzer scribed numinously:
On Tue, 2002-07-02 at 23:40, Tim Smith wrote:
On Monday 01 Jul 2002 10:10 pm, Keith Whitwell scribed numinously:
Michel Dänzer wrote:
On Mon, 2002-07-01 at 21:28, Tim Smith wrote:
- BEGIN_RING( 4 );
-
On Wed, 2002-07-03 at 10:06, Tim Smith wrote:
On Tuesday 02 Jul 2002 11:57 pm, Michel Dänzer scribed numinously:
On Tue, 2002-07-02 at 23:40, Tim Smith wrote:
On Monday 01 Jul 2002 10:10 pm, Keith Whitwell scribed numinously:
Michel Dänzer wrote:
On Mon, 2002-07-01 at 21:28,
Tim Smith wrote:
On Tuesday 02 Jul 2002 7:47 am, Keith Whitwell scribed numinously:
On the other hand the response time from you and Michel c who do have
CVS access is very quick, so I only need it if I become a burden to
you :-)
I have no objections to access for you, less work for me. :)
On Monday 01 Jul 2002 10:10 pm, Keith Whitwell scribed numinously:
Michel Dänzer wrote:
On Mon, 2002-07-01 at 21:28, Tim Smith wrote:
- BEGIN_RING( 4 );
- OUT_RING( CP_PACKET0( RADEON_RE_TOP_LEFT, 0 ) );
- OUT_RING( (box-y1 16) | box-x1 );
- OUT_RING( CP_PACKET0(
On Tue, 2002-07-02 at 23:40, Tim Smith wrote:
On Monday 01 Jul 2002 10:10 pm, Keith Whitwell scribed numinously:
Michel Dänzer wrote:
On Mon, 2002-07-01 at 21:28, Tim Smith wrote:
- BEGIN_RING( 4 );
- OUT_RING( CP_PACKET0( RADEON_RE_TOP_LEFT, 0 ) );
- OUT_RING( (box-y1 16) | box-x1
On Sunday 30 Jun 2002 8:49 pm, Keith Whitwell scribed numinously:
Tim Smith wrote:
I found a few other ways of provoking the problem while I was at it,
and dragging an xclock window over the 3D view did it too (with a
window manager and solidmove turned on). In fact, I also managed to
I'm running without PageFlipping, and don't see any SwapBuffers ioctls in my
debug output, so that rules that out.
I got suspicious of the clear ioctl before and put a wait-for-idle (full
blown host-wait) call in after each clear. That didn't fix it either, so I
don't think it's the
On Monday 01 Jul 2002 8:38 pm, Keith Whitwell scribed numinously:
Tim Smith wrote:
On Monday 01 Jul 2002 5:19 pm, Keith Whitwell scribed numinously:
I'm running without PageFlipping, and don't see any SwapBuffers ioctls
in my debug output, so that rules that out.
I got suspicious of the
On Mon, 2002-07-01 at 21:28, Tim Smith wrote:
- BEGIN_RING( 4 );
- OUT_RING( CP_PACKET0( RADEON_RE_TOP_LEFT, 0 ) );
- OUT_RING( (box-y1 16) | box-x1 );
- OUT_RING( CP_PACKET0( RADEON_RE_WIDTH_HEIGHT, 0 ) );
-/* OUT_RING( ((box-y2 - 1) 16) | (box-x2 - 1) );*/
-
This looks good. Have you tested with pageflipping enabled?
Yes. Mind you I usually get notes along the lines of allow 1 current 0
which seems to indicate that it's not getting used. I'm not sure I have
anything that would use it if tuxracer doesn't. Maybe I could dig Quake3
out of
Michel Dänzer wrote:
On Mon, 2002-07-01 at 21:28, Tim Smith wrote:
- BEGIN_RING( 4 );
- OUT_RING( CP_PACKET0( RADEON_RE_TOP_LEFT, 0 ) );
- OUT_RING( (box-y1 16) | box-x1 );
- OUT_RING( CP_PACKET0( RADEON_RE_WIDTH_HEIGHT, 0 ) );
-/* OUT_RING( ((box-y2 - 1) 16) | (box-x2 -
On Monday 01 Jul 2002 9:06 pm, Michel Dänzer scribed numinously:
On Mon, 2002-07-01 at 21:28, Tim Smith wrote:
- BEGIN_RING( 4 );
- OUT_RING( CP_PACKET0( RADEON_RE_TOP_LEFT, 0 ) );
- OUT_RING( (box-y1 16) | box-x1 );
- OUT_RING( CP_PACKET0( RADEON_RE_WIDTH_HEIGHT, 0 ) );
-/*
On Mon, 2002-07-01 at 23:23, Tim Smith wrote:
On Monday 01 Jul 2002 9:06 pm, Michel Dänzer scribed numinously:
On Mon, 2002-07-01 at 21:28, Tim Smith wrote:
- BEGIN_RING( 4 );
- OUT_RING( CP_PACKET0( RADEON_RE_TOP_LEFT, 0 ) );
- OUT_RING( (box-y1 16) | box-x1 );
- OUT_RING(
On Monday 01 Jul 2002 10:10 pm, Keith Whitwell scribed numinously:
Michel Dänzer wrote:
On Mon, 2002-07-01 at 21:28, Tim Smith wrote:
- BEGIN_RING( 4 );
- OUT_RING( CP_PACKET0( RADEON_RE_TOP_LEFT, 0 ) );
- OUT_RING( (box-y1 16) | box-x1 );
- OUT_RING( CP_PACKET0(
On Tue, 2002-07-02 at 00:27, Tim Smith wrote:
On Monday 01 Jul 2002 10:57 pm, Michel Dänzer scribed numinously:
On Mon, 2002-07-01 at 23:23, Tim Smith wrote:
On Monday 01 Jul 2002 9:06 pm, Michel Dänzer scribed numinously:
On Mon, 2002-07-01 at 21:28, Tim Smith wrote:
-
Tim Smith wrote:
I found a few other ways of provoking the problem while I was at it, and
dragging an xclock window over the 3D view did it too (with a window
manager and solidmove turned on). In fact, I also managed to provoke the
lockup by persistently dragging xclock around over a
I found a few other ways of provoking the problem while I was at it, and
dragging an xclock window over the 3D view did it too (with a window
manager and solidmove turned on). In fact, I also managed to provoke the
lockup by persistently dragging xclock around over a maximised glxgears in
On Saturday 29 Jun 2002 4:05 pm, Tim Smith scribed numinously:
In a totally unrelated note, the texture funnies that I reported earlier
do not occur in 24-bit mode, but only in 16-bit mode. Tux Racer shows
this too though in tux racer the problem is still visible in 16bit mode
though less
Michel Dänzer wrote:
On Mon, 2002-06-03 at 23:39, Linus Torvalds wrote:
On Fri, 31 May 2002, Keith Whitwell wrote:
Also note that it actually asks for the pixcache to be flushed *twice* - once
by RADEON_PURGE_CACHE (which writes the RADEON_RB2D_DSTCACHE_CTLSTAT via the
ring) and once in
On Tue, 2002-06-11 at 11:28, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mon, 2002-06-03 at 23:39, Linus Torvalds wrote:
On Fri, 31 May 2002, Keith Whitwell wrote:
Also note that it actually asks for the pixcache to be flushed *twice* - once
by RADEON_PURGE_CACHE (which writes the
On Tue, Jun 11, 2002 at 12:17:18PM +0200, Michel Dänzer wrote:
Then there's the render extension...
That's one of the next items on my list. :)
I wouldn't waste too much time on accelerating the RENDER extension
just yet. Things are still changing, and then there's the lacking
of a test
On Tue, 2002-06-11 at 12:26, Alan Hourihane wrote:
On Tue, Jun 11, 2002 at 12:17:18PM +0200, Michel Dänzer wrote:
Then there's the render extension...
That's one of the next items on my list. :)
I wouldn't waste too much time on accelerating the RENDER extension
just yet. Things are
Seriously, the DRI stuff does live in seperate directories,
with the sole
exception of the 2D driver, many of which have different
maintainers in
the XFree86 project scope. So there is a strong physical
seperation of the
DRI code in the XFree86 tree. So, more than the time that
On Wed, 5 Jun 2002, Tim Smith wrote:
On Friday 31 May 2002 4:54 pm, Tim Smith scribed numinously:
On Friday 31 May 2002 4:12 pm, Keith Whitwell scribed numinously:
Tim Smith wrote:
Me too. Could this be a locking problem? There seem to be two
contexts owned by the same PID in
On Fri, 31 May 2002, Keith Whitwell wrote:
Also note that it actually asks for the pixcache to be flushed *twice* - once
by RADEON_PURGE_CACHE (which writes the RADEON_RB2D_DSTCACHE_CTLSTAT via the
ring) and once in radeon_do_pixcache_flush() which writes the register via MMIO.
Btw, why
On Mon, 2002-06-03 at 23:39, Linus Torvalds wrote:
On Fri, 31 May 2002, Keith Whitwell wrote:
Also note that it actually asks for the pixcache to be flushed *twice* - once
by RADEON_PURGE_CACHE (which writes the RADEON_RB2D_DSTCACHE_CTLSTAT via the
ring) and once in
On Thursday 30 May 2002 10:24 am, Keith Whitwell scribed numinously:
I conclude from this that writing the ring tail register causes the
card to fetch all the commands up until that point and feed them to its
FIFO, which may fill it... It's certainly possible for the FIFO to go
from 64
Obviously :-) Otherwise the trace in my last mail would have indicated a
crash, but it recovered from that.
It does seem like a good idea to know how much we just gave the card to do
though, so we have some idea to how long to wait next time we do wait.
It may be significant is that
Tim Smith wrote:
On Thursday 30 May 2002 9:15 am, Keith Whitwell scribed numinously:
I've attempted some rather pathetic rate-adaption to make everything
slow down when the FIFO gets full. It utterly murders performance but
it did prevent the lockup from occurring. I modified ADVANCE_RING to
On Friday 31 May 2002 2:00 pm, Keith Whitwell scribed numinously:
Tim Smith wrote:
I conclude from this that writing the ring tail register causes the
card to fetch all the commands up until that point and feed them to its
FIFO, which may fill it... It's certainly possible for the FIFO to
On Fri, 31 May 2002, Tim Smith wrote:
I seem to be observing the behaviour that if, on entry to do_cp_idle() the
FIFO is not empty already, it never will be empty and the whole thing goes
pear shaped. Thus, if a big collection of commands is just followed by more
commands this doesn't seem
Linus Torvalds wrote:
On Fri, 31 May 2002, Tim Smith wrote:
I seem to be observing the behaviour that if, on entry to do_cp_idle() the
FIFO is not empty already, it never will be empty and the whole thing goes
pear shaped. Thus, if a big collection of commands is just followed by more
Keith Whitwell wrote:
Linus Torvalds wrote:
On Fri, 31 May 2002, Tim Smith wrote:
I seem to be observing the behaviour that if, on entry to
do_cp_idle() the
FIFO is not empty already, it never will be empty and the whole thing
goes
pear shaped. Thus, if a big collection of commands
I've attempted some rather pathetic rate-adaption to make everything slow
down when the FIFO gets full. It utterly murders performance but it did
prevent the lockup from occurring. I modified ADVANCE_RING to take a
parameter containing a Wild-Ass-Guess of how many commands were being
On Thursday 30 May 2002 9:15 am, Keith Whitwell scribed numinously:
I've attempted some rather pathetic rate-adaption to make everything
slow down when the FIFO gets full. It utterly murders performance but
it did prevent the lockup from occurring. I modified ADVANCE_RING to
take a
I conclude from this that writing the ring tail register causes the card to
fetch all the commands up until that point and feed them to its FIFO, which
may fill it... It's certainly possible for the FIFO to go from 64 slots
free to 0 in one ioctl...
...so maybe what we need is some
On Thursday 30 May 2002 5:55 am, Michael scribed numinously:
On Thu, May 30, 2002 at 04:10:14AM +0100, Michael wrote:
Now X c r a w l s at this point, but switching back to q3 you can play
quake, frame rates seem fine, with just the chattering of continual
*Error* out of fifo messages
On Thu, 2002-05-30 at 11:24, Keith Whitwell wrote:
I conclude from this that writing the ring tail register causes the card to
fetch all the commands up until that point and feed them to its FIFO, which
may fill it... It's certainly possible for the FIFO to go from 64 slots
free to 0
Michel Dänzer wrote:
On Thu, 2002-05-30 at 11:24, Keith Whitwell wrote:
I conclude from this that writing the ring tail register causes the card to
fetch all the commands up until that point and feed them to its FIFO, which
may fill it... It's certainly possible for the FIFO to go from 64
On Tuesday 28 May 2002 1:13 pm, Keith Whitwell scribed numinously:
Tim Smith wrote:
On Tuesday 28 May 2002 8:40 am, Keith Whitwell scribed numinously:
Tim Smith wrote:
I've done some more digging and it would appear to send an enormous
amount of commands via radeon_cp_cmdbuf, all ending
Tim Smith wrote:
On Tuesday 28 May 2002 1:13 pm, Keith Whitwell scribed numinously:
Tim Smith wrote:
On Tuesday 28 May 2002 8:40 am, Keith Whitwell scribed numinously:
Tim Smith wrote:
I've done some more digging and it would appear to send an enormous
amount of commands via
On Wednesday 29 May 2002 11:26 am, Keith Whitwell scribed numinously:
Tim Smith wrote:
On Tuesday 28 May 2002 1:13 pm, Keith Whitwell scribed numinously:
Tim Smith wrote:
On Tuesday 28 May 2002 8:40 am, Keith Whitwell scribed numinously:
Tim Smith wrote:
I've done some more digging and
On Thu, May 30, 2002 at 01:10:48AM +0100, Tim Smith wrote:
Hmmm. The following may be useful information:
I've added some traces to read the free space in the FIFO each time
COMMIT_RING() happens, and also in radeon_do_wait_for_fifo() to trace out
the min/max number of FIFO slots it found
On Thu, May 30, 2002 at 04:10:14AM +0100, Michael wrote:
I'd just set supposedly 28mb of ring buffer too.
^^^ Doh, I'm being dumb, ignore this line...different thing altogether...
--
Michael.
___
Don't miss the 2002 Sprint PCS
Tim Smith wrote:
On Monday 27 May 2002 8:22 pm, Michael scribed numinously:
On Sun, May 26, 2002 at 06:50:11PM +0100, Tim Smith wrote:
The tcl-0-0-branch really doesn't like 2D menus being popped up over
the 3D drawing area; it locks up after a few of these with or without
RADEON_NO_TCL and
Tim Smith wrote:
On Tuesday 28 May 2002 8:40 am, Keith Whitwell scribed numinously:
Tim Smith wrote:
I've done some more digging and it would appear to send an enormous
amount of commands via radeon_cp_cmdbuf, all ending up going via
radeon_emit_packet3_cliprect. Actually I don't think it's
On Sun, May 26, 2002 at 06:50:11PM +0100, Tim Smith wrote:
The tcl-0-0-branch really doesn't like 2D menus being popped up over
the 3D drawing area; it locks up after a few of these with or without
RADEON_NO_TCL and with or without page flipping enabled. Following
Michel's suggestion I've
On Fri, May 24, 2002 at 01:54:52PM -0700, Keith Packard wrote:
We have an agreement in principle for DRI to use the XFree86 CVS tree
instead of their separate tree on sourceforge, but that hasn't happened
for reasons I don't understand. While that won't fix everything, it
I think that's
On Friday 24 May 2002 11:17 am, I wrote:
The XFree 4.2 driver is stable, but drops textures on the floor somwhere.
The CVS code produces correct textures, but locks up under heavy use with
the symptoms described. I've been using the binaries from
dri.sourceforge.net to test this with. I also
d then it still require regular maintenance and management.
Getting DRI into XFree86 CVS seems like a relatively low-overhead way to
reduce the lag between the two systems, perhaps we can try to restart
those discussions.
Well, I confess I was unaware of this, and it's really not my choice,
On Sat, 2002-05-25 at 12:03, Keith Whitwell wrote:
d then it still require regular maintenance and management.
Getting DRI into XFree86 CVS seems like a relatively low-overhead way to
reduce the lag between the two systems, perhaps we can try to restart
those discussions.
Well, I
Tim Smith wrote:
I have a nice, 100% reliable way to lock up my Radeon 7500 using the most
recent CVS. I can do this with Tux Racer, if I play for a couple of
courses, but it's much easier to do using the Neverwinter Nights Toolset
beta running under WINE, because that's really quite
On Friday 24 May 2002 8:49 am, Keith Whitwell scribed numinously:
Tim Smith wrote:
I have a nice, 100% reliable way to lock up my Radeon 7500 using the
most recent CVS. I can do this with Tux Racer, if I play for a couple
of courses, but it's much easier to do using the Neverwinter Nights
What's going to happen to the card if drmDMA() returns EAGAIN rather than
EBUSY, which is what it does in the case where radeon_freelist_get returns
NULL? Should the drm kernel module return EBUSY in that circumstance? None
of the userspace parts seem to check for EAGAIN, but all the
On Friday 24 May 2002 11:31 am, Keith Whitwell scribed numinously:
+ What's going to happen to the card if drmDMA() returns EAGAIN rather
than EBUSY, which is what it does in the case where radeon_freelist_get
returns NULL? Should the drm kernel module return EBUSY in that
circumstance?
On Fri, 24 May 2002, Tim Smith wrote:
Covering about 30 seconds prior to me hitting reset, so the card certainly
seems to be getting rather stuck, because 'done=N' doesn't increment over
that 30 seconds.
Hmm.. I don't know if it is related, but you can get both a Radeon-7500
and a
On Fri, 24 May 2002, Linus Torvalds wrote:
It might even happen with a regular XF-4.2 server (ie switching from using
XF4.2 to DRI CVS tree without rebooting in between), I'll test.
Nope, doesn't happen with regular XF-4.2. But I re-verified that if I run
the gatos drivers first, and then
On Fri, 24 May 2002, José Fonseca wrote:
When doing this you're using the GATOS DRM with the Radeon Mesa X
drivers of DRI CVS. Since the regular X works, it seems that GATOS broke
binary compatibility. Does this happens too when switching GATOS with
XF-4.2?
Note that once I switch away
From: Linus Torvalds [EMAIL PROTECTED]
Date: Fri, 24 May 2002 13:09:18 -0700 (PDT)
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas --
Around 13 o'clock on May 24, Linus Torvalds wrote:
And yes, you don't even need the DRI branch, you can see the lockup even
with gatos - plain XFree CVS (I told Keith Packard about it, I haven't
heard back).
About all I could do was reproduce the problem; I don't have radeon docs
yet to
On Fri, 24 May 2002, Keith Packard wrote:
I submit that we need some sort of plan on how to get this mess resolved;
I'd like to get to a state where 3D and video runs on most chips, and at
least doesn't hang on the others. What I'd like to see is:
+ The kernel driver for the tcl-0-0
On 2002.05.24 21:45 Linus Torvalds wrote:
On Fri, 24 May 2002, Keith Packard wrote:
...
+ The regular DRI GL bits
These have some important fixes missing from the XFree86 tree
while
not incorporating all of the tcl changes which are probably
less
well tested on
Around 13 o'clock on May 24, Linus Torvalds wrote:
Keith, I've got an extra one you could get if actual hw access is the
problem (as opposed to just time, which tends to be the biggest problem
most of the time).
I've got a stack of video cards; I can manage to get another, and I think
I'll
On Fri, 24 May 2002, José Fonseca wrote:
Keith P., even very recentely it was discussed on the Xpert mailing list
that the XFree86 project didn't have the manpower to handle all the
patches that are being submited regularly.
From personal experience, it doesn't get better, it only gets
On Friday 24 May 2002 7:36 pm, Tim Smith scribed numinously:
I've introduced a tiny usleep into the loop in radeon_accel.c to give
syslog a chance and my loghost now produces a couple of thousand lines of
the form
moomintroll kernel: [drm:radeon_freelist_get] skipping buf=23
age=48355
On Fri, May 24, 2002 at 01:35:44PM -0700, Keith Packard wrote:
+ The kernel driver for the tcl-0-0 branch
This gives us the best chance at API compatibility into the future
as people are able to migrate to a tcl GL library, and should
reduce the kernel driver churn a bit.
On 2002.05.24 22:00 Keith Packard wrote:
Around 21 o'clock on May 24, =?iso-8859-1?Q?Jos=E9?= Fonseca wrote:
Keith P., even very recentely it was discussed on the Xpert mailing
list
that the XFree86 project didn't have the manpower to handle all the
patches
that are being submited
On Fri, 2002-05-24 at 20:36, Tim Smith wrote:
I've introduced a tiny usleep into the loop in radeon_accel.c to give syslog
a chance and my loghost now produces a couple of thousand lines of the form
moomintroll kernel: [drm:radeon_freelist_get] skipping buf=23 age=48355
done=48319
Linus Torvalds wrote:
On Fri, 24 May 2002, Keith Packard wrote:
I submit that we need some sort of plan on how to get this mess resolved;
I'd like to get to a state where 3D and video runs on most chips, and at
least doesn't hang on the others. What I'd like to see is:
+ The kernel driver
On Sat, 25 May 2002, Keith Whitwell wrote:
Linus, as this constitues a defacto release of code it's probably good to know
about it when this happens...
It's not a problem, but it does mark a point at which the new interfaces
become public, and it's happened in a different order than the
Linus Torvalds wrote:
On Sat, 25 May 2002, Keith Whitwell wrote:
Linus, as this constitues a defacto release of code it's probably good to know
about it when this happens...
It's not a problem, but it does mark a point at which the new interfaces
become public, and it's happened in a
I have a nice, 100% reliable way to lock up my Radeon 7500 using the most
recent CVS. I can do this with Tux Racer, if I play for a couple of
courses, but it's much easier to do using the Neverwinter Nights Toolset
beta running under WINE, because that's really quite intensive and produces
75 matches
Mail list logo
