[Dri-devel] Re: [GATOS]Re: R128PutImage eating too much CPU, round 2 :-]
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 > data transfer to actually finish. So it took less CPU waiting, but the > result was potentially incorrect. Indeed, when you called a 2D accel function while DMA was in progress, it caused a total system lockup. Still, the CPU load is a too high price to pay, there must be another way. > If the CPU usage is really a problem, an interrupt is probably the way > to go; don't know if and how the chip supports that though. Sounds good. Mit freundlichen Grüßen Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- My mind is like a steel trap - rusty and illegal in 37 states. msg02906/pgp0.pgp Description: PGP signature
Re: [Dri-devel] Pseudo DMA?
> 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 slower chipset- well, > it really sickens me. What's the mach64 card going to end up being like > performance wise? Raster wise - exactly the same. Geomtry wise - a bit worse, but maybe there are some good opts in mesa 4.0 to make up some of the difference. > Are there any cards out there that don't have seriously borked DMA models > that we have to do intrinsically inefficient things just to secure the > driver? I had hoped that the i810 would be a workable chipset for the pilot > project with my employer's planned product offerings- it would be a slow > chip, but it would allow me a way of demoing some 3D games, etc. on a set-top > box system. Now, well... The i810 is seriously raster bound for most games, I'd be suprised if it made much difference in those situations. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
"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 insecure commands > > onto the ring, where they may then be executed... > > I didn't see that in the documentation. If it's only working from the > premise that the command stream is untrusted, it's supposed to stop operation > at that point. Since the ring buffers are supposed to be in system memory, > I'd have thought that if you controlled the buffers so that the rings are > NEVER accessable to the user from the driver they couldn't be used to ammend > commands to it (real memory access...) with a batch buffer. I'll re-read > things since you're claiming different from what I got from it. The rings are in agp space. It's a bug in the security model of the i810, it's arcane, but believe me it's real. > > In addition to unmapping the buffer, the i810 kernel module emits commands > > into the buffer itself, ensuring that the data can only be interpreted as > > vertices. Eg, imagine receiving a buffer full of bogus commands from a > > spoofing app - the kernel module unmaps it from userspace, then writes at > > the top of the buffer a command that says: "emit the next 4096 (or > > whatever) bytes as a tristrip". No commands from the app can ever be > > executed. > > If the commands don't allow any access to anything system memory-wise (which > is what you're doing in the command to start the buffer) then they can't > overwrite anything or be used to snag memory that doesn't belong to the app. > I'd have to double check the source code- I didn't see anything that parsed > vertex info into DMA commands in the driver layer. I'd expect that if it's > entirely as you claim it is. Let me try to summarize: There are commands that access the system memory, but you can only emit them from the ring. You can get them onto the ring via the blitter from batch buffers. Unless the batch buffers are unmapped from userspace after they are submitted to the ring, an untrusted app can overwrite them with the blit-to-ring commands while they are queued for execution. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
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 > > `../../../../../../lib/GL/dri/drm/sis_drm.h', needed by `sis_alloc.o'. > > Stop. > > make[4]: Leaving directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv/sis' > > make[3]: *** [all] Error 2 > > make[3]: Leaving directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv' > > make[2]: *** [all] Error 2 > > make[2]: Leaving directory `/db2/xfree/xc/xc/lib/GL' > > make[1]: *** [all] Error 2 > > make[1]: Leaving directory `/db2/xfree/xc/xc/lib' > > make: *** [all] Error 2 > > > > Any clue? Is it FAQ? > > No idea... Did you follow the compilation guide? It looks sort of like you didn't do 'make World' and just did make. > > The main point of this letter: could someone please consider the > > possibility of periodical publishing mach64.tar.gz using the method of > > Gatos project: just XFree modules and drm kernel modules (I think, for > > libGL.* will go there too). The building of the whole tree is time- and > > space-consuming task, so these builds could simplify the life for > > "ordinary but adventurous people" like me. Is it wrong idea? I do not > > think it is very difficult to hack little shell script which makes this > > archive... > > Why limit this to the mach64 driver? We don't build binaries for > anything else, and some might argue that other drivers are used more > than this one and are thus more worthy of having pre-built binaries :-) If someone wants to take the role of release manager, that would be great. The job is just to keep your CVS tree up to date with all the drivers, build it all (and report any problems), and release make releases to the download page at regular intervals. It isn't a tough job. We even had people make the packaging tools a while back. All it takes is some bandwidth and cycles, which could be run in the middle of the night. So, for those of you looking to help, here's another suggestion. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
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 can > emit a batch buffer with blit commands in it that blit insecure commands > onto the ring, where they may then be executed... The documentation lends the idea that it doesn't convert them to no-ops, but rather does the rough equivalent of a segfault, signalling an interrupt on the bus. The hole you describe is an interesting issue though- hadn't thought of that one. Has there been an actual test to see if it was doable from an unsecured batch buffer? I couldn't find any discussion in the list archives as to whether this is a theoretical exploit or an actual one for this chip. > In addition to unmapping the buffer, the i810 kernel module emits commands > into the buffer itself, ensuring that the data can only be interpreted as > vertices. Eg, imagine receiving a buffer full of bogus commands from a > spoofing app - the kernel module unmaps it from userspace, then writes at > the top of the buffer a command that says: "emit the next 4096 (or > whatever) bytes as a tristrip". No commands from the app can ever be > executed. Ok, I see what the code's doing there- missed it in both my passes over it (Don't know how I missed it- if it'd been a snake...). So the mesa side of things isn't supposed to write in the very first part of the buffer to allow for the insertion of that command, then. Is it a good thing to un-map it _after_ you write in the command at the head of the batch buffer? I'd think it'd leave a loophole in there (because they could sneak in another command in the place of the one the driver is placing)- difficult to exploit, but there all the same. 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 slower chipset- well, it really sickens me. What's the mach64 card going to end up being like performance wise? Are there any cards out there that don't have seriously borked DMA models that we have to do intrinsically inefficient things just to secure the driver? I had hoped that the i810 would be a workable chipset for the pilot project with my employer's planned product offerings- it would be a slow chip, but it would allow me a way of demoing some 3D games, etc. on a set-top box system. Now, well... -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
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]: Leaving directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv/sis' > make[3]: *** [all] Error 2 > make[3]: Leaving directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/db2/xfree/xc/xc/lib/GL' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/db2/xfree/xc/xc/lib' > make: *** [all] Error 2 > > Any clue? Is it FAQ? No idea... > The main point of this letter: could someone please consider the > possibility of periodical publishing mach64.tar.gz using the method of > Gatos project: just XFree modules and drm kernel modules (I think, for > libGL.* will go there too). The building of the whole tree is time- and > space-consuming task, so these builds could simplify the life for > "ordinary but adventurous people" like me. Is it wrong idea? I do not > think it is very difficult to hack little shell script which makes this > archive... Why limit this to the mach64 driver? We don't build binaries for anything else, and some might argue that other drivers are used more than this one and are thus more worthy of having pre-built binaries :-) -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Complain and request for Mach64 binaries a la Gatos
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_alloc.o'. > Stop. > make[4]: Leaving directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv/sis' > make[3]: *** [all] Error 2 > make[3]: Leaving directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/db2/xfree/xc/xc/lib/GL' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/db2/xfree/xc/xc/lib' > make: *** [all] Error 2 > > Any clue? Is it FAQ? No clue. The only thing I noticed unusual is that you're not building on a seperate lndir tree, but I don't see how that could affect the build. If you really want to know make a 'find /db2/xfree/ -name sis_drm.h' to see were that file went to and compare to the path were make is trying to get it. > > The main point of this letter: could someone please consider the > possibility of periodical publishing mach64.tar.gz using the method of > Gatos project: just XFree modules and drm kernel modules (I think, for > libGL.* will go there too). The building of the whole tree is time- and You don't need to build the whole tree. You could just went to xc/lib/GL/mesa/src/drv/mach64 and do 'cvs update', 'make' and 'su -c "make install"'... > space-consuming task, so these builds could simplify the life for ...although space-consuming is indeed, unfortunately. > "ordinary but adventurous people" like me. Is it wrong idea? I do not > think it is very difficult to hack little shell script which makes this > archive... Since your not only a "ordinary but adventurous people" but a rather persistent one as well I'm going to do what ask for! :-) I'll post here when it's done. > > Cheers, > > Sergey > Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [GATOS]Re: R128PutImage eating too much CPU, round 2 :-]
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 took less CPU waiting, but the > result was potentially incorrect. > > > If the CPU usage is really a problem, an interrupt is probably the way > to go; don't know if and how the chip supports that though. It is quite capable of raising an interrupt on DMA completion; it's a bit in GEN_INT_CNTL, IIRC. You can also generate an interrupt when the gui engine is idle. R C -- They said it was *daft* to build a space station in a swamp, but I showed them! It sank unto the swamp. So I built a second space station. That sank into the swamp too. My third space station sank into the swamp. So I built a fourth one. That fell into a time warp and _then_ sank into the swamp. But the fifth one... stayed up! --Monty Python/Babylon 5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [GATOS]Re: R128PutImage eating too much CPU, round 2 :-]
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 much but busy loop. > 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 transfer to actually finish. So it took less CPU waiting, but the result was potentially incorrect. If the CPU usage is really a problem, an interrupt is probably the way to go; don't know if and how the chip supports that though. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Complain and request for Mach64 binaries a la Gatos
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/mesa/src/drv/sis' make[3]: *** [all] Error 2 make[3]: Leaving directory `/db2/xfree/xc/xc/lib/GL/mesa/src/drv' make[2]: *** [all] Error 2 make[2]: Leaving directory `/db2/xfree/xc/xc/lib/GL' make[1]: *** [all] Error 2 make[1]: Leaving directory `/db2/xfree/xc/xc/lib' make: *** [all] Error 2 Any clue? Is it FAQ? The main point of this letter: could someone please consider the possibility of periodical publishing mach64.tar.gz using the method of Gatos project: just XFree modules and drm kernel modules (I think, for libGL.* will go there too). The building of the whole tree is time- and space-consuming task, so these builds could simplify the life for "ordinary but adventurous people" like me. Is it wrong idea? I do not think it is very difficult to hack little shell script which makes this archive... Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Wolfenstein on 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 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 mesa-4-0-branch hang whole system after intro. > > > > I've didn't run with debug, so can't say line xxx. > > > > I'll try with the fix. > > > > > > Where can I get Wolfenstein from? I thought it was an Id game > > > but I don't see it on their website. > > > > Yes, it is an Id game. > > You can grep the Linux playfile or the Linux demo at Id's ftp site or many > > mirrors. > > > > ftp://ftp.idsoftware.com/idstuff/wolf/linux > > > > I tried the wolfspdemo-linux-1.1b.x86 version (112,4 MB). > > TDFX driver solved!!! > > I was hit but the outstanding Glide3 3DNow! texture bug (texdown seg > faults)... > After a recompilation of Glide3 _without_ 3DNow! enabled Wolfenstein (RTCW) > runs without a hitch. > > Sorry for my false alarm. Cool. I have Wolfenstien running on my system with Voodoo3 and it seems to work fine. I was afraid this was going to be a really ellusive bug. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Wolfenstein on r128
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 message. > > > > How do other drivers handle the same point? > > > > > > Latest tdfx trunk and mesa-4-0-branch hang whole system after intro. > > > I've didn't run with debug, so can't say line xxx. > > > I'll try with the fix. > > > > Where can I get Wolfenstein from? I thought it was an Id game > > but I don't see it on their website. > > Yes, it is an Id game. > You can grep the Linux playfile or the Linux demo at Id's ftp site or many > mirrors. > > ftp://ftp.idsoftware.com/idstuff/wolf/linux > > I tried the wolfspdemo-linux-1.1b.x86 version (112,4 MB). TDFX driver solved!!! I was hit but the outstanding Glide3 3DNow! texture bug (texdown seg faults)... After a recompilation of Glide3 _without_ 3DNow! enabled Wolfenstein (RTCW) runs without a hitch. Sorry for my false alarm. -Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: R128PutImage eating too much CPU, round 2 :-]
> >> 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 the kernel block and wait for an interrupt ? >> and calling another X function until it's finished causes X to "hang" >> and this "eats" CPU time. > >It might be a good idea to test if XSync alone causes the same >behaviour. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
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 ring, where they may then be executed... I didn't see that in the documentation. If it's only working from the premise that the command stream is untrusted, it's supposed to stop operation at that point. Since the ring buffers are supposed to be in system memory, I'd have thought that if you controlled the buffers so that the rings are NEVER accessable to the user from the driver they couldn't be used to ammend commands to it (real memory access...) with a batch buffer. I'll re-read things since you're claiming different from what I got from it. > In addition to unmapping the buffer, the i810 kernel module emits commands > into the buffer itself, ensuring that the data can only be interpreted as > vertices. Eg, imagine receiving a buffer full of bogus commands from a > spoofing app - the kernel module unmaps it from userspace, then writes at > the top of the buffer a command that says: "emit the next 4096 (or > whatever) bytes as a tristrip". No commands from the app can ever be > executed. If the commands don't allow any access to anything system memory-wise (which is what you're doing in the command to start the buffer) then they can't overwrite anything or be used to snag memory that doesn't belong to the app. I'd have to double check the source code- I didn't see anything that parsed vertex info into DMA commands in the driver layer. I'd expect that if it's entirely as you claim it is. -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Meeting log for 2002-02-18
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
[Dri-devel] Today IRC meeting is starting now
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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [GATOS]Re: R128PutImage eating too much CPU, round 2 :-]
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 hardware > > problem, I also had this before I upgraded the motherboard, just wasn't able > > to reproduce it predictably (now I CAN reproduce it anytime). > What has changed since then is that the CCE is now used for 2D > acceleration with DRI, and the info->accel->Sync() function waits for > the CCE to go idle. I have a feeling you found it. > My first question is: Can you trust top? Basically not, but this is such a large amount and I don't understand why a simple XSync should make a difference of 25% if it wasn't "guilty"? Surprisingly, the numbers are rougly the same as back in August, before we made the DMACopyStuff422, even if now I have 40% faster CPU. Don't you think it is a strange coincidence? This would indicate that about the same real time is being wasted waiting for something, although we got rid of the stupid memcpy. > Or could it be that CPU time from the client gets accounted to X? No. It is client-independent. > It doesn't make too much sense that whether the client 'does something' has > influence on the amount of CPU X uses, does it? No, it really doesn't, but if SOMETHING is calling X functions while XSync is pending, it would explain it. > > Zdenek's (aviplay maintainer) and my current theory is that calling the > > XvShmPutImage returns before it is actually run. > If you look at the code, you see that it returns after it has memcpy'd > the data to the framebuffer (without DRI) / after it has fired the > indirect DMA buffers for the image transfer (with DRI). Aha, so the assumption is correct. > > 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. Why is it so more difficult to do this correctly with CCE when it worked without? I'll look at the code. > (The DRM uses a loop with udelay() actually; see r128_do_cce_idle() in > r128_cce.c) Ok, I'll grep for it and try some magic :-) > > and calling another X function until it's finished causes X to "hang" > > and this "eats" CPU time. > It might be a good idea to test if XSync alone causes the same > behaviour. Yes it might, but I'm too lazy, I'll simply write some code and hope it solves the problem :-) Mit freundlichen Grüßen Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- The computer revolution is over. The computers won. msg02890/pgp0.pgp Description: PGP signature
[Dri-devel] Re: [GATOS]Re: R128PutImage eating too much CPU, round 2 :-]
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 >a) creates unnecessary PCI traffic >b) wastes time.. This (wasting while waiting) is exaxtly what IMHO is causing this. > The solution to this would be to not submit new frames faster than > graphics card can handle them. Actually, I reproduced it now with mplayer (sdl or xv) with only twm running. mplayer eats 20%, X also. DMA is working. This sucks and I doubt it is sending it faster than it should (I vaguely remember my card should be able to get 3 times 25fps dvd size at 16bpp). The tested video is 24 fps 640x480. It also happens with smaller ones, but X eats less. > Peter - Am I right in thinking that you have Rage128 card ? Yes. > Can you write a simple program to measure just how fast can you pump frames > into overlay ? I could but I'm lazy :-) I really think it is what Michel (?) said in other email, that XSync is doing busy-loop while waiting for the transfer to finish. I could rewrite it to do usleep. I don't care really if it takes 10ms more to wait. I'll report later. > Vladimir Dergachev Mit freundlichen Grüßen Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Press every key to continue. msg02889/pgp0.pgp Description: PGP signature
[Dri-devel] Re: [GATOS]Re: R128PutImage eating too much CPU, round 2 :-]
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 assumption > > that all XFree operation has been finished and player continues with > > handling another frame. > > > > However for now it looks like XFree is actually returning sonner than > > all pending operations (image transfers) are finished - as mplayer > > is waiting in this stage then usually nothing tragical will happen > > as long as you have fast enough CPU so mplayer could wait enough time > > before it will decide it's about right time to decode next frame. > > (might be simulated in aviplay as well - but as avifile has some > > threaded prechaching it will show this behaviour instantly and you > > do not have to turn on any postprocessing level). > > > > Aviplay almost immeditally after return from XSync call > > wakes up decoding thread - if all the memory transfers would be > > finished by this time everything would be just fine - however > > if the Xserver is still transfering the memory then there will be > > noticable slowdown as both operation will be completed slower then > > they could be if these operation would be running in serial. > > > > Quit noticable is this on SMP machine where XFree is accessing memory > > at the same time as decoder is decoding next frame. > > But I still don't understand why _X_ should hog the CPU: > > - Without DRI, XvShmPutImage() itself only returns after it has > memcpy()'d the data > > - With DRI, it might be possible that XSync doesn't really wait for the > DMA transfer to complete (maybe PutImage should set > info->accel->NeedToSync ?), but then it would be the graphics chip > still accessing RAM, not X > > > I'm very curious what the solution for this is gonna be. :) 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 a) creates unnecessary PCI traffic b) wastes time.. The solution to this would be to not submit new frames faster than graphics card can handle them. Peter - Am I right in thinking that you have Rage128 card ? Can you write a simple program to measure just how fast can you pump frames into overlay ? Vladimir Dergachev > > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > > ___ > Gatos-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/gatos-devel > ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: R128PutImage eating too much CPU, round 2 :-]
> 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 -
but it definitely shouldn't be something like 50%.
On my box when I use avibench for some file - then complete play time
is ~55s - 40s takes decoder ~14s XSync time - which really means around
25% CPU load for the XFree server - in this case there is only one
thread which is rendering and another one which reads file.
>
> 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()
I'd have expect some IRQ handler ???
--
.''`. Which fundamental human right do you want to give up today?
: :' : Debian GNU/Linux maintainer - www.debian.{org,cz}
`. `' Zdenek Kabelac kabi@{debian.org, users.sf.net, fi.muni.cz}
`- When in doubt, just blame the Euro. :)
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: R128PutImage eating too much CPU, round 2 :-]
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 player continues with > handling another frame. > > However for now it looks like XFree is actually returning sonner than > all pending operations (image transfers) are finished - as mplayer > is waiting in this stage then usually nothing tragical will happen > as long as you have fast enough CPU so mplayer could wait enough time > before it will decide it's about right time to decode next frame. > (might be simulated in aviplay as well - but as avifile has some > threaded prechaching it will show this behaviour instantly and you > do not have to turn on any postprocessing level). > > Aviplay almost immeditally after return from XSync call > wakes up decoding thread - if all the memory transfers would be > finished by this time everything would be just fine - however > if the Xserver is still transfering the memory then there will be > noticable slowdown as both operation will be completed slower then > they could be if these operation would be running in serial. > > Quit noticable is this on SMP machine where XFree is accessing memory > at the same time as decoder is decoding next frame. But I still don't understand why _X_ should hog the CPU: - Without DRI, XvShmPutImage() itself only returns after it has memcpy()'d the data - With DRI, it might be possible that XSync doesn't really wait for the DMA transfer to complete (maybe PutImage should set info->accel->NeedToSync ?), but then it would be the graphics chip still accessing RAM, not X I'm very curious what the solution for this is gonna be. :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: R128PutImage eating too much CPU, round 2 :-]
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 multithreaded player like aviplay or set high postprocessing level to > mplayer), suddenly X eats 26% CPU. Even worse, if I disable dri (so that DMA > isn't used for this function), it eats up to 50% !!!. > > 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 > problem, I also had this before I upgraded the motherboard, just wasn't able > to reproduce it predictably (now I CAN reproduce it anytime). What has changed since then is that the CCE is now used for 2D acceleration with DRI, and the info->accel->Sync() function waits for the CCE to go idle. > You can reproduce it anytime as well, find a high quality divx and run a > player (aviplay or mplayer), and run top over ssh, or perhaps even in another > window. You'll notice that with no postprocessing and reasonably fast cpu (> > 500MHz), everything is ok, but when you turn the postprocessing to the max, X > will eat horribly lot of CPU. Setting postprocessing is easy, in aviplay you > 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. 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? > Zdenek's (aviplay maintainer) and my current theory is that calling the > XvShmPutImage returns before it is actually run. If you look at the code, you see that it returns after it has memcpy'd the data to the framebuffer (without DRI) / after it has fired the indirect DMA buffers for the image transfer (with DRI). > 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) > and calling another X function until it's finished causes X to "hang" > and this "eats" CPU time. It might be a good idea to test if XSync alone causes the same behaviour. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: R128PutImage eating too much CPU, round 2 :-]
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 maintainer) and my current theory is that calling the
> XvShmPutImage returns before it is actually run. A player then does XSync, so
> that I can actually see the picture appear on screen, and calling another X
> function until it's finished causes X to "hang" and this "eats" CPU time.
To cleanup this information noice a bit -
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 player continues with
handling another frame.
However for now it looks like XFree is actually returning sonner than
all pending operations (image transfers) are finished - as mplayer
is waiting in this stage then usually nothing tragical will happen
as long as you have fast enough CPU so mplayer could wait enough time
before it will decide it's about right time to decode next frame.
(might be simulated in aviplay as well - but as avifile has some
threaded prechaching it will show this behaviour instantly and you
do not have to turn on any postprocessing level).
Aviplay almost immeditally after return from XSync call
wakes up decoding thread - if all the memory transfers would be
finished by this time everything would be just fine - however
if the Xserver is still transfering the memory then there will be
noticable slowdown as both operation will be completed slower then
they could be if these operation would be running in serial.
Quit noticable is this on SMP machine where XFree is accessing memory
at the same time as decoder is decoding next frame.
Ok I hope now it should be more clear.
--
.''`. Which fundamental human right do you want to give up today?
: :' : Debian GNU/Linux maintainer - www.debian.{org,cz}
`. `' Zdenek Kabelac kabi@{debian.org, users.sf.net, fi.muni.cz}
`- When in doubt, just blame the Euro. :)
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
"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 programmer's guide trying to understand why > it's acceptable to send commands mixed with the verticies to it (since that > is the same boat we're in with the RagePRO), and we might be doing too much > in one aspect, and not enough in others. Someone should look over my > shoulder here and see if I'm plain flat missing something... 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 ring, where they may then be executed... In addition to unmapping the buffer, the i810 kernel module emits commands into the buffer itself, ensuring that the data can only be interpreted as vertices. Eg, imagine receiving a buffer full of bogus commands from a spoofing app - the kernel module unmaps it from userspace, then writes at the top of the buffer a command that says: "emit the next 4096 (or whatever) bytes as a tristrip". No commands from the app can ever be executed. > > The mapping/unmapping doesn't seem to buy us much in the way of protection > and is slow. According to the documentation from Intel, the chip is designed > to handle these situations for us. While I know the chip is slow, is it > really needed to do this operation which is a very big bottleneck on > performance? Yes, unfortunately. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] R128PutImage eating too much CPU, round 2 :-]
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 reproduce it also with mplayer with -vo xv. 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 multithreaded player like aviplay or set high postprocessing level to mplayer), suddenly X eats 26% CPU. Even worse, if I disable dri (so that DMA isn't used for this function), it eats up to 50% !!!. 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 problem, I also had this before I upgraded the motherboard, just wasn't able to reproduce it predictably (now I CAN reproduce it anytime). You can reproduce it anytime as well, find a high quality divx and run a player (aviplay or mplayer), and run top over ssh, or perhaps even in another window. You'll notice that with no postprocessing and reasonably fast cpu (> 500MHz), everything is ok, but when you turn the postprocessing to the max, X will eat horribly lot of CPU. Setting postprocessing is easy, in aviplay you 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. Zdenek's (aviplay maintainer) and my current theory is that calling the XvShmPutImage returns before it is actually run. A player then does XSync, so that I can actually see the picture appear on screen, and calling another X function until it's finished causes X to "hang" and this "eats" CPU time. Parameters to SDL_Init don't change anything and as I said, I am able to reproduce it with plain XvShmPutImage as well. This is most probably not XF86 related but specific to r128, because I don't remember upgrading X in between. In my hunt to exterminate this problem I upgraded to XF86 4.2.0 (I had cvs 4.1.99 or something like that 'till then), and cvs gatos from about a week a go. This didn't change anything. So, I'd be very happy if someone could tell me if Zdenek's and my assumption is right (that XvShmPutImage on r128 returns immediately and this was introduced around November last year), and how to fix it (or even perhaps fix it himself/herself, though I'm confident with a little hint I can do it myself). Thank you for your attention, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- The best things in life are free, but the expensive ones are still worth a look. msg02882/pgp0.pgp Description: PGP signature
Re: [Dri-devel] [PATCH] Wolfenstein on r128
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. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Wolfenstein on r128
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 handle the same point? > > > > Latest tdfx trunk and mesa-4-0-branch hang whole system after intro. > > I've didn't run with debug, so can't say line xxx. > > I'll try with the fix. > > Where can I get Wolfenstein from? I thought it was an Id game > but I don't see it on their website. Yes, it is an Id game. You can grep the Linux playfile or the Linux demo at Id's ftp site or many mirrors. ftp://ftp.idsoftware.com/idstuff/wolf/linux I tried the wolfspdemo-linux-1.1b.x86 version (112,4 MB). [snip] > > Third: > > Mesa/xdemos> ./wincopy > > glXMakeContextCurrent failed in Redraw() > > glXMakeContextCurrent failed in Redraw() > > glXMakeContextCurrent failed in Redraw() > > [snip] > > > > Should this work with hardware acceleration? > > It didn't work even with setenv LIBGL_ALWAYS_INDIRECT 1. > > > > Fourth: > > Should we see Mesa-4.0.2 in the trunk, soon? > > Not until after I release 4.0.2 (maybe in a week or so). OK, thanks. > PS: Deiter, Dieter! ;-) > there's no need to address your messages to Keith and > I and the DRI list since we're on the list. I know you're probably > trying to get my attention but I'm working full-time on another > project and don't have much time for DRI stuff right now. Yes, sorry! -Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Wolfenstein on r128
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? > > Latest tdfx trunk and mesa-4-0-branch hang whole system after intro. > I've didn't run with debug, so can't say line xxx. > I'll try with the fix. Where can I get Wolfenstein from? I thought it was an Id game but I don't see it on their website. > Second: > /home/nuetzel> cd /opt/VTK/vtk/graphics/examplesCxx/ > Directory: /opt/VTK/vtk/graphics/examplesCxx > graphics/examplesCxx> ./Normals > * XMesaCloseFullScreen * > > I get this with all mesa-4-0-branch "versions" and now with the trunk. > We had this with early devel branches before. But not with the trunk. That's just a debug message, I'll disable it. > Third: > Mesa/xdemos> ./wincopy > glXMakeContextCurrent failed in Redraw() > glXMakeContextCurrent failed in Redraw() > glXMakeContextCurrent failed in Redraw() > [snip] > > Should this work with hardware acceleration? > It didn't work even with setenv LIBGL_ALWAYS_INDIRECT 1. > > Fourth: > Should we see Mesa-4.0.2 in the trunk, soon? Not until after I release 4.0.2 (maybe in a week or so). -Brian PS: Deiter, there's no need to address your messages to Keith and I and the DRI list since we're on the list. I know you're probably trying to get my attention but I'm working full-time on another project and don't have much time for DRI stuff right now. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Wolfenstein on r128
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 mesa-4-0-branch hang whole system after intro. I've didn't run with debug, so can't say line xxx. I'll try with the fix. Second: /home/nuetzel> cd /opt/VTK/vtk/graphics/examplesCxx/ Directory: /opt/VTK/vtk/graphics/examplesCxx graphics/examplesCxx> ./Normals * XMesaCloseFullScreen * I get this with all mesa-4-0-branch "versions" and now with the trunk. We had this with early devel branches before. But not with the trunk. Third: Mesa/xdemos> ./wincopy glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() glXMakeContextCurrent failed in Redraw() [snip] Should this work with hardware acceleration? It didn't work even with setenv LIBGL_ALWAYS_INDIRECT 1. Fourth: Should we see Mesa-4.0.2 in the trunk, soon? Regards, Dieter ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Pseudo DMA?
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 understand why it's acceptable to send commands mixed with the verticies to it (since that is the same boat we're in with the RagePRO), and we might be doing too much in one aspect, and not enough in others. Someone should look over my shoulder here and see if I'm plain flat missing something... While we keep someone from altering the buffer while it's being operated upon by the engine (unmapping the buffer), there is nothing keeping someone from submitting bogus commands to the instruction parser on the chip directly from the user side of things. However, there's the something of the equivalent of user versus kernel space operation with this chip (and we are using it) that keeps the outside world from using it to DMA things, etc. that they're not supposed to so long as you deny them access to the ring buffer. We are doing that, but unfortunately, the driver doesn't seem to use the interrupt framework built into the chip to reset itself after an error has occured (we're using it only to handle DMA flushes in the driver according to comments in the code and my reading of the code in question)- which it has to do to continue operation after a protection violation, according to the programmer's guides. The mapping/unmapping doesn't seem to buy us much in the way of protection and is slow. According to the documentation from Intel, the chip is designed to handle these situations for us. While I know the chip is slow, is it really needed to do this operation which is a very big bottleneck on performance? -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: Re: [Dri-devel] Radeon 7500 instability]
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 radeon driver well yet. Let's hope Keith > will spot something. :) What seems weird to me is the sequence: Feb 11 14:13:50 whale kernel: [drm:radeon_lock] 1 (pid 2715) requests lock (0x0003), flags = 0x Feb 11 14:13:50 whale kernel: [drm:radeon_lock] 1 has lock Feb 11 14:13:50 whale kernel: [drm:radeon_ioctl] pid=2715, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 Feb 11 14:13:50 whale kernel: [drm:radeon_cp_idle] radeon_cp_idle Feb 11 14:13:50 whale kernel: [drm:radeon_do_cp_idle] radeon_do_cp_idle Feb 11 14:13:50 whale kernel: [drm:radeon_ioctl] pid=2715, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 <-- repeating idle, stripped ---> Feb 11 14:13:50 whale kernel: [drm:radeon_cp_idle] radeon_cp_idle Feb 11 14:13:50 whale kernel: [drm:radeon_do_cp_idle] radeon_do_cp_idle Feb 11 14:13:50 whale kernel: [drm:radeon_ioctl] pid=3719, cmd=0x4008642a, nr=0x2a, dev 0xe200, auth=1 Feb 11 14:13:50 whale kernel: [drm:radeon_lock] 3 (pid 3719) requests lock (0x8001), flags = 0x Feb 11 14:13:50 whale kernel: [drm:radeon_ioctl] pid=2715, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 Feb 11 14:13:50 whale kernel: [drm:radeon_cp_idle] radeon_cp_idle Feb 11 14:13:50 whale kernel: [drm:radeon_do_cp_idle] radeon_do_cp_idle Feb 11 14:13:50 whale kernel: [drm:radeon_ioctl] pid=2715, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 and nothing happens anymore - it seems much as deadlock to me. It would also explain why is the bug harder to encounter with full logging. Side note: to eliminate a hw problem I've updated to lastest BIOS (mobo Asus a7v133). It was quite suprising that the stability increased substantialy - the mean time of lockup increased from 4 minutes to about 1.5 hour [even though only Athlon XP support and no bugfixes were declared]. But all problems I described before still exist but it's more bearable now ;) > > > The situation was: X start, quake3 demo, < 5 min if playing, hangup to blank > > screen. > > 'Blank screen' sounds like the chip went into a bad state... > > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > > -- Kamil Toman ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: Re: [Dri-devel] Radeon 7500 instability]
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 > were able to ssh back to black-screened machine I ripped off the kernel > messages. I put the logs on a web site > http://artax.karlin.mff.cuni.cz/~toman/x/syslog.msg.bz2 > > It's quite complete session (~200kB compressed, 16Megs uncompressed) since > I don't know what is and what is not important. I hope I'll help a bit. This log doesn't even show the radeon_freelist_get error; the X server waits in vain for the CP to go idle. I don't see anything bad leading up to that, but I don't know the radeon driver well yet. Let's hope Keith will spot something. :) > The situation was: X start, quake3 demo, < 5 min if playing, hangup to blank > screen. 'Blank screen' sounds like the chip went into a bad state... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon7500 + irongate agp chipset: are the problems being worked on?
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.gentoo.org . All of the stuff surrounding this issue is > posted there. mem=nopentium doesn't help here (it did when I had a GeForce card + nvidia drivers). Regards, Tilman -- Get GKrellM Newsticker @ http://gk-newsticker.sourceforge.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon7500 + irongate agp chipset: are the problems being worked on?
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 > > - Quake3 freezes in the main menu, and the animated Quake logo isn't > > displayed correctly). Maybe this helps you in finding the problem(?). > > The trunk has been updated to Mesa 4; are you just using the new DRM or > everything from CVS? If the former, please try the latter. Hehe, I only used the newer DRM module. I'll try to update everything. Regards, Tilman -- Get GKrellM Newsticker @ http://gk-newsticker.sourceforge.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon7500 + irongate agp chipset: are the problemsbeing worked on?
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 correctly). Maybe this helps you in finding the problem(?). The trunk has been updated to Mesa 4; are you just using the new DRM or everything from CVS? If the former, please try the latter. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon7500 + irongate agp chipset: are the problems being worked on?
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 when I turn the AGP speed down from 4x to 1x, > though > reducing the aperature size has helped a little. > > I'm willing to do some debugging, and maybe a bit of patchwork, but I > could use some hints as to how to get started debugging a system that > hangs the CPU. > > -Andy > Since the system hangs, I think that using a remote debugger or even a remote kernel debugger wont be of any good for now. I would suggest trying to turn on the display of every debug information option available, or even add some debug statments to the code yourself, and then look to the logs and see what the cause may be. When you're more sure were the problem is, you can then try using a remote kernel debugger to step trhough the code and understand the failure mechanism, or simply add even more debug output statements. Oh, and of course, having a journaled file system. Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon7500 + irongate agp chipset: are the problemsbeing worked on?
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 message "[drm:radeon_freelist_get] *ERROR* retruning NULL! Perhaps this is related? -Andy On Sun, 2002-02-17 at 18:43, Lance Stringham wrote: > 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 when I turn the AGP speed down from 4x to 1x, though > > reducing the aperature size has helped a little. > > > > I'm willing to do some debugging, and maybe a bit of patchwork, but I > > could use some hints as to how to get started debugging a system that > > hangs the CPU. > > > > -Andy > > > > On Sun, 17 Feb 2002, Tilman 'Trillian' Sauerbeck wrote: > > > > > >>On Sat, 16 Feb 2002 23:11:22 -0500 (EST) Vladimir Dergachev ><[EMAIL PROTECTED]> wrote: > >> > >> > >>>I am seeing the exact same thing with 440BX.. > >>>If you have Descent try running it with -t argument - it works fine in my > >>>setup. > >>> > >>I don't have Descent 3 and I don't want to download the demo, as I'm only on 56k >modem here (d/l is about 50 MB) > >> > >>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 correctly). Maybe this helps >you in finding the problem(?). > >> > >>Regards, > >>Tilman > >> > >> > >> > > > > > > ___ > > Dri-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > > > > > 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.gentoo.org . All of the stuff surrounding this issue is > posted there. > > -Lance Stringham > [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
