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 messag
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 troubl
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 c
On 18 Feb 2002 12:48:41 +0100 Michel Dänzer <[EMAIL PROTECTED]> wrote:
> 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
> >
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
> http://www.ge
On Mit, 2002-02-13 at 09:38, Kamil Toman wrote:
> > I think this is only a symptom of the chip locking up, causing the DRM
> > to run out of buffers. I wish the problems which actually cause these
> > were logged. ;(
>
> I see, okay I tried to insmod with full debug. From one session where I
> we
On Po, 2002-02-18 at 12:56, Michel Dänzer wrote:
>
> This log doesn't even show the radeon_freelist_get error; the X server
> waits in vain for the CP to go idle.
Yes, the radeon_freelist_get error is probably another thing.
> I don't see anything bad leading up
> to that, but I don't know the
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 programmer's guide trying to u
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 an
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 hand
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 mes
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 re
"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
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 mai
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 m
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 a
> 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 somethi
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 the
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. Whi
On Mon, Feb 18, 2002 at 07:38:01PM +0100, Michel Dänzer 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 hard
Today IRC meeting is starting now at irc.openprojects.net #dri-devel.
Regards,
José Fonseca
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
___
Dri-devel mailing list
My xchat log for today's meeting is attached.
--
Leif Delgass
http://www.retinalburn.net
dri-devel_meeting-20020218.txt.gz
Description: dri-devel_meeting-20020218.txt.gz
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 t
>
>> 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 much but busy loop. (The DRM uses a loop with udelay()
>actually; see r128_do_cce_idle() in r128_cce.c)
Can't th
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
Dieter Nützel wrote:
>
> 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 playi
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 `sis_alloc.o'.
Stop.
make[4]: Leaving directory `/db2/xfree/xc/xc/lib/GL/
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,
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 `sis_
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 `sis_alloc.o'.
> Stop.
> make[4]:
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 c
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
> 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 Dänzer 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
> d
37 matches
Mail list logo
