I have attempted using the mem=nopentium option. I'm still getting
lockups. I noticed the last couple of times that the lockup occurred
simultaneously with a key press (but not mouse movement). This may be a
red herring, though.
Noticeably, /var/log/messages reports receiving the kernel
On 2002.02.17 21:15 Andrew Schwerin wrote:
I'm running with a Radeon VE and having a similar problem. All apps that
use DRI eventually (within 10 minutes, often less than 1 minute) lock up
the system. I've got an A7A266. Contrary to the experience of the
users,
I've had more trouble
On Son, 2002-02-17 at 12:50, Tilman 'Trillian' Sauerbeck wrote:
Anyway, I updated my DRI CVS directory but the Radeon DRM module works
even worse: Every GLX app freezes my system now (e.g. running glxgears
- Quake3 freezes in the main menu, and the animated Quake logo isn't
displayed
On Sun, 17 Feb 2002 18:43:19 -0800 Lance Stringham [EMAIL PROTECTED] wrote:
There is an issue with AGP on Athlon chipsets, have you tried passing
the mem=nopentium option to the kernel on boot? For more information
about the issue with AGP go to the Gentoo linux site at
Keith Whitwell wrote:
Michel Dänzer wrote:
On Son, 2002-02-17 at 18:08, Marc Dietrich wrote:
Wolfenstein crashes after playing the intro at line 494 in
r128_texstate.c with an assert t failed message.
How do other drivers handle the same point?
Latest tdfx trunk and
Dieter Nützel wrote:
Keith Whitwell wrote:
Michel Dänzer wrote:
On Son, 2002-02-17 at 18:08, Marc Dietrich wrote:
Wolfenstein crashes after playing the intro at line 494 in
r128_texstate.c with an assert t failed message.
How do other drivers handle the same point?
Brian Paul wrote:
Dieter Nützel wrote:
Keith Whitwell wrote:
Michel Dänzer wrote:
On Son, 2002-02-17 at 18:08, Marc Dietrich wrote:
Wolfenstein crashes after playing the intro at line 494 in
r128_texstate.c with an assert t failed message.
How do other drivers
On Mon, Feb 18, 2002 at 09:32:29AM -0700, Brian Paul wrote:
Where can I get Wolfenstein from? I thought it was an Id game
but I don't see it on their website.
ftp://ftp.idsoftware.com has the demo linux runtimes.
The main site is http://www.activision.com/games/wolfenstein
--
Michael.
Dear co-developers,
Several months ago I noticed that even if I have working DMA, R128PutImage
still eats lots of CPU, up to 26%, depending on video size. Several weeks ago
I complained about this already, at that time it seemed to be a problem with
aviplay or SDL. But since then I was able to
Frank C. Earl wrote:
On Thursday 14 February 2002 10:33 am, Keith Whitwell wrote:
I haven't had a good look at security on either of these cards, but it's
definitely worth doing, both to find out if we're doing too little and if
we're doing too much.
I've been looking at the i810
On Mon, Feb 18, 2002 at 07:03:29PM +0100, Peter Surda wrote:
Dear co-developers,
turn autoquality off in the config and while playing the file, right-click,
choose properties and slide the slider. With mplayer, use -pp 0 or -pp 4.
-pp 0 means no postprocessing
Zdenek's (aviplay
On Mon, 2002-02-18 at 19:03, Peter Surda wrote:
The best problem description I can give you is this like this: when the player
is doing nothing for some time after returning from calling XvShmPutImage, top
shows X doesn't eat any CPU. However, if it DOES do something (e.g. if I run
a
On Mon, 2002-02-18 at 19:18, Zdenek Kabelac wrote:
I believe this is what is going on:
Movie players usually wait for for XFree operation completition by calling
XSync. Thus when XSync returns to the user space program there is assumption
that all XFree operation has been finished and
My first question is: Can you trust top? Or could it be that CPU time
from the client gets accounted to X? It doesn't make too much sense that
whether the client 'does something' has influence on the amount of CPU X
uses, does it?
Well I've told Peter that XServer should be eating something
On 18 Feb 2002, Michel [ISO-8859-1] Dänzer wrote:
On Mon, 2002-02-18 at 19:18, Zdenek Kabelac wrote:
I believe this is what is going on:
Movie players usually wait for for XFree operation completition by calling
XSync. Thus when XSync returns to the user space program there is
On Mon, Feb 18, 2002 at 02:04:29PM -0500, Vladimir Dergachev wrote:
But I still don't understand why _X_ should hog the CPU:
[cut]
Could it be that X is waiting for the engine to become quiscient ? So if
you scheduled a DMA transfer already it has to busy wait for the card to
finish. Which
On Mon, Feb 18, 2002 at 07:38:01PM +0100, Michel Dnzer wrote:
This must have been introduced roughly in November. I remember it worked
wonderfully right after Michel and I wrote the DMA patch in September, aviplay
was able to eat 99% and X ate nothing. I remember now this isn't a hardware
On Monday 18 February 2002 12:07 pm, Keith Whitwell wrote:
The i810 has a security model that makes insecure commands in batch buffers
into noops. Unfortunately there is a hole in the security model: you can
emit a batch buffer with blit commands in it that blit insecure commands
onto the
Dieter Nützel wrote:
Brian Paul wrote:
Dieter Nützel wrote:
Keith Whitwell wrote:
Michel Dänzer wrote:
On Son, 2002-02-17 at 18:08, Marc Dietrich wrote:
Wolfenstein crashes after playing the intro at line 494 in
r128_texstate.c with an assert t failed
On Mon, 2002-02-18 at 20:47, Peter Surda wrote:
On Mon, Feb 18, 2002 at 07:38:01PM +0100, Michel Dänzer wrote:
A player then does XSync, so that I can actually see the picture appear
on screen,
This could be where X uses all the CPU. While waiting for the CCE to go
idle, it can't do
On Tue, Feb 19, 2002 at 02:21:57AM +0100, Michel Dänzer wrote:
On Mon, 2002-02-18 at 20:47, Peter Surda wrote:
It probably didn't work without. ;) I think when DMA was used for
XvPutImage, but not the CCE yet for 2D, then a Sync didn't wait for the
data transfer to actually finish. So it
Sergey,
On 2002.02.19 00:46 Sergey V. Udaltsov wrote:
Hello all
Just tried to build mach64 branch. Got an error:
make[4]: Entering directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv/sis'
make[4]: *** No rule to make target
`../../../../../../lib/GL/dri/drm/sis_drm.h', needed by
On Monday 18 February 2002 01:07 pm, Keith Whitwell wrote:
A followup here... I'm looking at the i810 documentation and the source tree
now.
The i810 has a security model that makes insecure commands in batch buffers
into noops. Unfortunately there is a hole in the security model: you
On Mon, Feb 18, 2002 at 06:50:36PM -0800, Gareth Hughes wrote:
Sergey V. Udaltsov wrote:
Hello all
Just tried to build mach64 branch. Got an error:
make[4]: Entering directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv/sis'
make[4]: *** No rule to make target
Frank C. Earl wrote:
On Monday 18 February 2002 12:07 pm, Keith Whitwell wrote:
The i810 has a security model that makes insecure commands in batch buffers
into noops. Unfortunately there is a hole in the security model: you can
emit a batch buffer with blit commands in it that blit
Ugh... Ok, I see, I understand. What a shame. Really, it is- the driver as
it stands ends up being SLOWER than a mach64 under Utah-GLX. Yes, Utah-GLX
was less secure, but to be so much slower as to have the same gears framerate
with a PIII-600 as I got with a PII-450 on a supposedly
On Tue, Feb 19, 2002 at 02:21:57AM +0100, Michel Dnzer wrote:
Why is it so more difficult to do this correctly with CCE when it worked
without?
It probably didn't work without. ;) I think when DMA was used for
XvPutImage, but not the CCE yet for 2D, then a Sync didn't wait for the
data
27 matches
Mail list logo
