[Dri-devel] Strange slowdown with DRI drivers after reboot on Radeon VE
Hello! I've found out the strange things in DRI-CVS! My regular upgrade of Xfree86 and DRI looks like this: 1. I do checkout of both Xfree86-CVS and DRI-CVS 2. After installing and executing of Xfree86-CVS - glxgears shows me 430 FPS 3. After installing and execuring of DRI-CVS - glxgears shwos me 420 FPS 4. After reboot DRI-CVS shows me 360 FPS only! It seems that DRI-CVS doesn't configure some registers or something similar. Means that before reboot - DRI works with hardware which was configured by Xfree86 drivers but after reboot it is not able to configure video card properly. I've attached 3 dumps of Radeon's registers. These dump were generated with using of slightly modified by me 'gfxdump' utility from old-gatos CVS (at linuxvideo.org). Could please someone to investigate this problem? I'm using Xfree86-CVS and DRI-CVS at 14 dec 2002. WBR! Nick xfree86.dmp.bz2 Description: Binary data dri_after_xfree86.dmp.bz2 Description: Binary data slowdown(dri_after_reboot).dmp.bz2 Description: Binary data
[Dri-devel] Stop Dreaming And Start Making Money
72 Hours To Success
If you are a motivated and qualified communicator
I will personally demonstrate to you a system
that will make you $1,000 per week or more! This is
NOT mlm.
Call our 24 hour pre-recorded number to get the
details. Don't waste another minute! Call Now!
1-801-693-2530
I need people who want to make serious money. Make
the call and get the facts.
** Invest 2 minutes in yourself now! **
1-801-693-2530
_
You are receiving this message as someone who is interested in
online or offline business opportunities. If this email has reached you
in error, please accept our apologies and send a blank email to:
[EMAIL PROTECTED] and your name will be taken out from our
data base. Please allow at least 24-48 hours.
6702qLGL7-416PtvF2187CbBF8-671l28
1949diyy5-793gVIl15N¬±ùÞµéX¬²'²Þu¼ØFæ ¬*zÁ«y«QzÊhÈXÈ·®{hºÇ²¢ê飫jÓ
ÛOz·è®f§qà¨x
©çzXm¶ÿ z÷!jyÞàü:âuëÞf¢)à+-¸z÷¥+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèýÚâuëÞ
Re: [Dri-devel] ATI Radeon fifo problem...
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] I attempt to enable acceleration, X attempts to start, but I see a corrup= By acceleration, do you mean any acceleration or the DRI? DMA is only relevant for the latter. My mistake - what I mean by accerleration is putting the entry 'Option accel' in the 'Section Device' portion of my XF86Config-4 file for the ATI Radeon video driver. Having accel here causes the problems (as various extra features are loaded) as opposed to having noaccel here, when these extra features are not loaded. (In this case extra features refers to things that pertain to using various hardware features to speed up the display.) 00:01.0 PCI bridge: ATI Technologies Inc U1/A3 AGP Bridge [IGP 320M] (rev= 01) (prog-if 00 [Normal decode]) Hmm, seems to be some kind of integrated chipset? Maybe you can get agpgart working with agp_try_unsupported. I have seen an email on the debian-laptops list between (I suspect) some kernel developers referring to the ATI IGP 320 hardware stating that it was currently not totally supported. (I think they said something like ATI have not released the specs. yet, so the support has to be implemented the hard way.) My machine is an HP Pavillion ze4125 notebook. Thus is it possible tha the chipset is an integrated one. The laptop manual implies it is an integrated chipset (for some definition of integrated, which it does not specify...). When I use agp_try_unsupported=1 I get the same message in kern.log: Dec 15 12:07:17 marvin kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann Dec 15 12:07:17 marvin kernel: agpgart: Maximum main memory to use for agp memory: 408M Dec 15 12:07:17 marvin kernel: agpgart: unsupported bridge Dec 15 12:07:17 marvin kernel: agpgart: no supported devices found. b) The ATI Mobility U1 is sufficiently different from the other ATI Mobil= ity chips to cause a kernel panic on auto-detect. Not sure how autodetection by 'the kernel' (do you mean the DRM?) would cause a panic, you'd have to provide more information to tell. Again, my mistake for being unclear. When the option accel is used, and I start XFree (using startx), I see the screen switch to tty7, but stay blank. After a few seconds a single short beep is emitted. Then the caps-lock leds flashes on and off. The system stops responding to keyboard input and does not respond to ssh requests, not orderly shutdown (but ctrl-alt-backspace or ctrl-alt-delete or a brief press on the power button). Hence the kernel is no longer responding. When I reboot and look in the XFree.log file, it ends at the point when the list of the supported ATI chipsets is printed and the entries where the driver is attempting to load the ATI driver. Thus I presume that at this point the ATI software is loaded which has to identify the chipset and this detection mechanism causes the freeze. I have also tried a chipid of 0x4966 (Radeon 9000) in the XF86Config-4 file with the Option accel and this suffers the same timeout on the FIFO error. (I read a report that the Radeon Mobility U1 was supposed to be software-compatible with this chip.) Regards, Jason. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] PROBLEM: 2.4.{19,20} fails to resume if radeon.o is loaded
On Sat, Dec 14, 2002 at 06:04:06PM -0800, [EMAIL PROTECTED] wrote: after about a dozen reboots and half a dozen fscks, I finally was able to pinpoint the reason of why my laptop (ThinkPad X22 (2662XXK)) wasn't able to resume after suspend. The DRM module 'radeon.o' somehow prevents a successful resume (but not the suspend). Only after I made that module unavailable to the modutils, my laptop now successfully completes suspend/resume cycles. http://www.google.com/search?q=dri+radeon+resume Yields: http://cpbotha.net/dri_resume.html This is applicable only if you're interested in suspending/resuming with active DRI, which it doesn't seem you are. So it's just FYI :) -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] ATI Radeon fifo problem...
On Sun, 15 Dec 2002 [EMAIL PROTECTED] wrote: [...] 00:01.0 PCI bridge: ATI Technologies Inc U1/A3 AGP Bridge [IGP 320M] (rev 01) (prog-if 00 [Normal decode]) Hmm, seems to be some kind of integrated chipset? Maybe you can get agpgart working with agp_try_unsupported. I have seen an email on the debian-laptops list between (I suspect) some kernel developers referring to the ATI IGP 320 hardware stating that it was currently not totally supported. (I think they said something like ATI have not released the specs. yet, so the support has to be implemented the hard way.) My machine is an HP Pavillion ze4125 notebook. Thus is it possible tha the chipset is an integrated one. The laptop manual implies it is an integrated chipset (for some definition of integrated, which it does not specify...). When I use agp_try_unsupported=1 I get the same message in kern.log: Dec 15 12:07:17 marvin kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann Dec 15 12:07:17 marvin kernel: agpgart: Maximum main memory to use for agp memory: 408M Dec 15 12:07:17 marvin kernel: agpgart: unsupported bridge Dec 15 12:07:17 marvin kernel: agpgart: no supported devices found. As you can see, there's no agpgart support for ATI's IGP chipsets yet, which means right now you'd probably only be able to get 2D accel (with MMIO) at best. b) The ATI Mobility U1 is sufficiently different from the other ATI Mobility chips to cause a kernel panic on auto-detect. Not sure how autodetection by 'the kernel' (do you mean the DRM?) would cause a panic, you'd have to provide more information to tell. Again, my mistake for being unclear. When the option accel is used, and I start XFree (using startx), I see the screen switch to tty7, but stay blank. After a few seconds a single short beep is emitted. Then the caps-lock leds flashes on and off. The system stops responding to keyboard input and does not respond to ssh requests, not orderly shutdown (but ctrl-alt-backspace or ctrl-alt-delete or a brief press on the power button). Hence the kernel is no longer responding. When I reboot and look in the XFree.log file, it ends at the point when the list of the supported ATI chipsets is printed and the entries where the driver is attempting to load the ATI driver. Thus I presume that at this point the ATI software is loaded which has to identify the chipset and this detection mechanism causes the freeze. I have also tried a chipid of 0x4966 (Radeon 9000) in the XF86Config-4 file with the Option accel and this suffers the same timeout on the FIFO error. (I read a report that the Radeon Mobility U1 was supposed to be software-compatible with this chip.) All the initial reviews I saw on IGP 320M said it's a Radeon VE/7000 core (no TCL), but mention a possible new revision coming at the end of this year or beginning of 2003. Also the Radeon IGP pages on ATI's site just call it a RADEON core and don't mention Charisma EngineTM, which is their name for TCL (see the Radeon 7500 page), although the features page refers to a broad line of chips that are pin-compatible: http://mirror.ati.com/technology/hardware/radeonigp/features.html http://mirror.ati.com/technology/hardware/radeonigp/rigp320m.html You might want to try a Radeon 7000/VE or Radeon Mobility (M6?) ChipID. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [PATCH] i810 cleanup
This takes some of the stuff that was recently submitted to the xfree86.org for the i830 and tries to move the i810 along similiar lines... is all cosmetic apart from a new define for the FRONTBUFFER command this is what they call it in the i815 spec anyways. I'm submitting the equivalent patch to xfree86 (well slightly changed) for their tree also. Then I'll start moving over the i830 page flipping code from the xfree86 tree into an i810 driver. Anyone want to sync up our i830 with xfree86's? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person dri_diff Description: Binary data
Re: [Dri-devel] [PATCH] i810 cleanup
doh doh!! wasn't sync'ed properly with the tree (damn firewall!!)... this diff is a bit better and doesn't remove functionality... Dave. Dave Airlie said: This takes some of the stuff that was recently submitted to the xfree86.org for the i830 and tries to move the i810 along similiar lines... is all cosmetic apart from a new define for the FRONTBUFFER command this is what they call it in the i815 spec anyways. I'm submitting the equivalent patch to xfree86 (well slightly changed) for their tree also. Then I'll start moving over the i830 page flipping code from the xfree86 tree into an i810 driver. Anyone want to sync up our i830 with xfree86's? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person dri_diff Description: Binary data
Re: [Dri-devel] Joining development
Rudnev A.D. wrote: Hello! My name if Rudnev Alexey, I have been developing Linux OpenGL-based (and also writing my own graphics engines,independent of Mesa) applications for quite a long time .I also have some expirience in developing(adapting existing to my configuration) video drivers for Linux platform. So I think I could be useful for futher development of DRI and Mesa. Please,Send me conditions of joining development or some other place, where I could find such information. Rundev A.D. ,[EMAIL PROTECTED] Rudnev, No conditions. The sources are available from Source Forge. Post any patches you make to this list. There is lots of good developer documentation at http://dri.sf.net -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] problems with CVS head and i810
Dave Airlie said: Which application is this? glxgears from RH4.2 blows it away also!! I might try constucting a brand new root file system for my development system using the DRI tree, I'm currently running X etc from the DRI tree in my home directory (un-installed). Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-devel][PATCH] Segfault in DRI Xserver extension
Felix,
Thanks for finding and fixing this vulnerability in the DRI extension.
I'm copying the xpert list on this fix, because it looks like their may
be other extensions with the same vulnerability. For example:
xc/programs/Xserver/Xext/panoramiX.c: line 991
Felix Kühling wrote:
On Thu, 12 Dec 2002 22:26:23 +
Keith Whitwell [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
Hi,
while I was messing around with my query programme I found this: if I
specify an invalid screen as argument to XF86DRIGetClientDriverName the
Xserver segfaults. I had a quick look at xc/xc/Xserver/GL/dri/xf86dri.c.
stuff-screen is used as array index without checking. I'm not sure
though, where would be the right place to fix it.
Other functions in xf86dri.c must be affacted, too. They use
stuff-screen in the same way.
Those functions should validate any information they receive over the wire, as
soon as is feasible.
The problem is that the request records are all different. So we can't
check stuff-screen in ProcXF86DRIDispatch. We have to do it in each
request separately.
The attached patch does just that. While I grepped around to see how
other extensions check this I found one more potential problem in
programs/Xserver/GL/glx/glxcmds.c and two suspicious casts of screen
from unsigned to int (screen is always unsigned in the request records).
They are fixed in the attached patch as well.
Regards,
Felix
__\|/_____ ___ ___
__Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_Felix___\Ä/\ \_\ \_\ \__U___just not everything
[EMAIL PROTECTED]o__/ \___/ \___/at the same time!
Index: dri/xf86dri.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/GL/dri/xf86dri.c,v
retrieving revision 1.10
diff -u -r1.10 xf86dri.c
--- dri/xf86dri.c 29 Oct 2002 20:28:57 - 1.10
+++ dri/xf86dri.c 13 Dec 2002 15:51:57 -
@@ -155,6 +155,11 @@
REQUEST(xXF86DRIQueryDirectRenderingCapableReq);
REQUEST_SIZE_MATCH(xXF86DRIQueryDirectRenderingCapableReq);
+if (stuff-screen = screenInfo.numScreens) {
+ client-errorValue = stuff-screen;
+ return BadValue;
+}
+
rep.type = X_Reply;
rep.length = 0;
rep.sequenceNumber = client-sequence;
@@ -184,6 +189,10 @@
REQUEST(xXF86DRIOpenConnectionReq);
REQUEST_SIZE_MATCH(xXF86DRIOpenConnectionReq);
+if (stuff-screen = screenInfo.numScreens) {
+ client-errorValue = stuff-screen;
+ return BadValue;
+}
if (!DRIOpenConnection( screenInfo.screens[stuff-screen],
hSAREA,
@@ -221,6 +230,10 @@
REQUEST(xXF86DRIAuthConnectionReq);
REQUEST_SIZE_MATCH(xXF86DRIAuthConnectionReq);
+if (stuff-screen = screenInfo.numScreens) {
+ client-errorValue = stuff-screen;
+ return BadValue;
+}
rep.type = X_Reply;
rep.length = 0;
@@ -242,6 +255,10 @@
{
REQUEST(xXF86DRICloseConnectionReq);
REQUEST_SIZE_MATCH(xXF86DRICloseConnectionReq);
+if (stuff-screen = screenInfo.numScreens) {
+ client-errorValue = stuff-screen;
+ return BadValue;
+}
DRICloseConnection( screenInfo.screens[stuff-screen]);
@@ -258,6 +275,10 @@
REQUEST(xXF86DRIGetClientDriverNameReq);
REQUEST_SIZE_MATCH(xXF86DRIGetClientDriverNameReq);
+if (stuff-screen = screenInfo.numScreens) {
+ client-errorValue = stuff-screen;
+ return BadValue;
+}
DRIGetClientDriverName( screenInfo.screens[stuff-screen],
(int *)rep.ddxDriverMajorVersion,
@@ -295,6 +316,11 @@
REQUEST(xXF86DRICreateContextReq);
REQUEST_SIZE_MATCH(xXF86DRICreateContextReq);
+if (stuff-screen = screenInfo.numScreens) {
+ client-errorValue = stuff-screen;
+ return BadValue;
+}
+
rep.type = X_Reply;
rep.length = 0;
rep.sequenceNumber = client-sequence;
@@ -329,6 +355,10 @@
{
REQUEST(xXF86DRIDestroyContextReq);
REQUEST_SIZE_MATCH(xXF86DRIDestroyContextReq);
+if (stuff-screen = screenInfo.numScreens) {
+ client-errorValue = stuff-screen;
+ return BadValue;
+}
if (!DRIDestroyContext( screenInfo.screens[stuff-screen],
stuff-context)) {
@@ -348,6 +378,11 @@
REQUEST(xXF86DRICreateDrawableReq);
REQUEST_SIZE_MATCH(xXF86DRICreateDrawableReq);
+if (stuff-screen = screenInfo.numScreens) {
+ client-errorValue = stuff-screen;
+ return BadValue;
+}
+
rep.type = X_Reply;
rep.length = 0;
rep.sequenceNumber = client-sequence;
@@ -378,6 +413,10 @@
REQUEST(xXF86DRIDestroyDrawableReq);
DrawablePtr pDrawable;
REQUEST_SIZE_MATCH(xXF86DRIDestroyDrawableReq);
+if (stuff-screen = screenInfo.numScreens) {
+ client-errorValue = stuff-screen;
+ return BadValue;
+}
if (!(pDrawable = (DrawablePtr)SecurityLookupDrawable(
(Drawable)stuff-drawable,
@@ -409,6 +448,11 @@
