Re: OpenGL apps causes frequent system locks

2005-02-14 Thread Geller Sandor
On Thu, 10 Feb 2005, Geller Sandor wrote:

 On Tue, 8 Feb 2005, Michel [ISO-8859-1] D=E4nzer wrote:

  On Mon, 2005-02-07 at 13:40 +0100, Geller Sandor wrote:
  
   Is there any way I can help to track down the problem(s)? My machine
   doesn't have network connection, so I can use only scripts which run in
   the background. With expect and gdb maybe it is possible to get at leas=
 t a
   backtrace from my non-local-interactive machine.
 
  Unfortunately, a backtrace is usually useless for a lockup because all
  it will show you is the X server and/or the client(s) waiting for the
  GPU to become idle, which it never does because it's locked up. The
  problem is finding out what caused it to lock up, and that can be very
  hard and time consuming.
 
  That being said, I too have noticed slightly decreased stability with
  r200 recently. As this seems to have snuck in gradually, binary searches
  to try and isolate the CVS changes causing problems might be a good
  strategy.

 Thanks, I checked out CVS versions 2004-08-31 and 2004-09-30 of the X.org.
 I will test with this two snapshots on the weekend, and if the latter
 crashes while the former doesn't, then I will be able track down which is
 the latest CVS snapshot which works on my machine without crashes.

Unfortunately, I haven't been able to compile older CVS versions. Simply
issued 'cvs co -D 2004-08-31 xc', didn't touch anything, used the 'make
World  world.log 21' command, as usual. The result is in ERR-1 (this is
from the 2004-09-30 snapshot, because I overwrited the 2004-08-31 logfile,
but the results were the same). I used gcc 3.3.5, which is the default
C compiler in Debian sid. (I tried compiling with gcc 2.95, with the same
result). So I disabled Xinerama support and tried again. The result is in
ERR-2. I suppose, that the problem is related to the included headers,
because the programs/Xserver/dix/dispatch file is almost the same as the
version in current CVS, and the programs/Xserver/Xext/panoramiX*.h headers
haven't changed. Current CVS version compiles cleanly. Any suggestions,
how can I make older versions to compile?

  Geller Sandor [EMAIL PROTECTED]

ERR-2
Description: Binary data


ERR-1
Description: Binary data


Re: OpenGL apps causes frequent system locks

2005-02-10 Thread Geller Sandor
On Tue, 8 Feb 2005, Michel [ISO-8859-1] Dnzer wrote:

 On Mon, 2005-02-07 at 13:40 +0100, Geller Sandor wrote:
 
  Is there any way I can help to track down the problem(s)? My machine
  doesn't have network connection, so I can use only scripts which run in
  the background. With expect and gdb maybe it is possible to get at least a
  backtrace from my non-local-interactive machine.

 Unfortunately, a backtrace is usually useless for a lockup because all
 it will show you is the X server and/or the client(s) waiting for the
 GPU to become idle, which it never does because it's locked up. The
 problem is finding out what caused it to lock up, and that can be very
 hard and time consuming.

 That being said, I too have noticed slightly decreased stability with
 r200 recently. As this seems to have snuck in gradually, binary searches
 to try and isolate the CVS changes causing problems might be a good
 strategy.

Thanks, I checked out CVS versions 2004-08-31 and 2004-09-30 of the X.org.
I will test with this two snapshots on the weekend, and if the latter
crashes while the former doesn't, then I will be able track down which is
the latest CVS snapshot which works on my machine without crashes.

  Geller Sandor [EMAIL PROTECTED]


---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: OpenGL apps causes frequent system locks

2005-02-09 Thread Mike Mestnik
I'm using the new prebuilt debs that include an Xorg server and I get a
hardlock just after mode swich, befour the desktop shows.  There is no
usefull debuging I have been able todo, exept to say commenting out the
dri Xmod stopes the problem.  

2005.01.26-2 from John Lightsey [EMAIL PROTECTED].

Untill now I thought it was just me and my r200.

--- Geller Sandor [EMAIL PROTECTED] wrote:

 On Sun, 6 Feb 2005, Richard Stellingwerff wrote:
 
  On Sun, 06 Feb 2005 13:45:47 -0500, Michel Dänzer [EMAIL PROTECTED]
 wrote:
   Does it also happen without either or all of the options in the
 radeon
   device section?
 
  I just removed the AGPFastWrite and DynamicClocks options. The crashes
  still happen though.
 
 Looks like not only I have problems with the radeon driver. I update the
 X.org, drm, Mesa CVS once a week, but haven't found a working
 combination
 since 4-5 months...
 
 I don't intend to start a flame-war, but is there anybody who can use
 the
 r200 driver without X crashes? I'm testing X.org CVS regularly (almost
 on
 every weekend) with my RV280, with the latest linux 2.6 kernel.
 
 I checked out X.org on last Saturday, played with Descent3 for some
 minutes, it didn't crashed. Good. Restarted X, started Descent3 again,
 it
 crashed almost immediately, as expected :(( That's why I have a
 'shutdown
 -r 5' in the background, when I test X.org CVS...
 
 Compiled Mesa CVS, installed the libraries and the driver, started D3.
 (Descent3 looks great, textures are visible, thanks to Eric Anholt's
 projected texture patch which is in Mesa CVS) The game crashed X in a
 few
 seconds. This was expected too :((
 
 I tried out other OpenGL-based games, unfortunately, I can crash X with
 almost every game I have - it is only a matter of time. I tried setting
 color depth to 16 bit, changed the AGP to 1x in the system BIOS, none of
 these helped.
 
 Last time I used the 2.6.11-rc3 linux kernel, X.org CVS (updated on
 20050205), Mesa CVS (20050205, linux-x86-dri target). I didn't built the
 drm module, I used the kernel's radeon drm module. I used to test the
 drm
 compiled from the CVS version, but I found out, that it is only a matter
 of time to crash the X server, so I skipped the drm CVS test. Of course
 the real tests will be these:
 
 1. build and install everything from CVS, if the X server can be
 crashed,
  go to step 2, otherwise be happy :))
 2. use the X.org CVS version with the stock kernel's drm, if X still
  crashes, go to step 3. Otherwise use the  X.org CVS, live without
  projected textures...
 3. use the X.org and Mesa CVS versions. If X still crashes, then the bug
  can be in X.org or Mesa or in drm - I'm not able to trace down the
  problem.
 
 Unfortunately all 3 scenarios give the same result: X crashes.
 
 Is there any way I can help to track down the problem(s)? My machine
 doesn't have network connection, so I can use only scripts which run in
 the background. With expect and gdb maybe it is possible to get at least
 a
 backtrace from my non-local-interactive machine.
 
 Regards,
 
   Geller Sandor [EMAIL PROTECTED]
 
 
 ---
 This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
 Tool for open source databases. Create drag--drop reports. Save time
 by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
 Download a FREE copy at http://www.intelliview.com/go/osdn_nl
 --
 ___
 Dri-devel mailing list
 Dri-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dri-devel
 





__ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail


---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: OpenGL apps causes frequent system locks

2005-02-08 Thread Geller Sandor
On Mon, 7 Feb 2005, Roland Scheidegger wrote:

 Geller Sandor wrote:
 I just removed the AGPFastWrite and DynamicClocks options. The crashes
 still happen though.
 
 
  Looks like not only I have problems with the radeon driver. I update the
  X.org, drm, Mesa CVS once a week, but haven't found a working combination
  since 4-5 months...
 
  I don't intend to start a flame-war, but is there anybody who can use the
  r200 driver without X crashes? I'm testing X.org CVS regularly (almost on
  every weekend) with my RV280, with the latest linux 2.6 kernel.
 I suspect that quite the contrary, almost noone has crashes. This is
 probably part of the problem, if they happen only for few people with
 very specific configurations, none of the developers can reproduce it
 and it will just remain unfixed.

OK, I assumed, that this is the case. That's why I want to get some
backtraces, but my problem is, that my console is dead, and I don't have
network connection to my own machine to run gdb. I'm going to write some
scripts with gdb and expect to get backtraces from the X server and the
Descent3 game. I will report back if I can produce backtraces, but
unfortunately, I'm using my machine only on the weekends, so expect some
delay.

Regards,

  Geller Sandor [EMAIL PROTECTED]


---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: OpenGL apps causes frequent system locks

2005-02-08 Thread Michel Dänzer
On Mon, 2005-02-07 at 13:40 +0100, Geller Sandor wrote:
 
 Is there any way I can help to track down the problem(s)? My machine
 doesn't have network connection, so I can use only scripts which run in
 the background. With expect and gdb maybe it is possible to get at least a
 backtrace from my non-local-interactive machine.

Unfortunately, a backtrace is usually useless for a lockup because all
it will show you is the X server and/or the client(s) waiting for the
GPU to become idle, which it never does because it's locked up. The
problem is finding out what caused it to lock up, and that can be very
hard and time consuming.

That being said, I too have noticed slightly decreased stability with
r200 recently. As this seems to have snuck in gradually, binary searches
to try and isolate the CVS changes causing problems might be a good
strategy.


-- 
Earthling Michel Dnzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer


---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: OpenGL apps causes frequent system locks

2005-02-07 Thread Geller Sandor
On Sun, 6 Feb 2005, Richard Stellingwerff wrote:

 On Sun, 06 Feb 2005 13:45:47 -0500, Michel Dnzer [EMAIL PROTECTED] wrote:
  Does it also happen without either or all of the options in the radeon
  device section?

 I just removed the AGPFastWrite and DynamicClocks options. The crashes
 still happen though.

Looks like not only I have problems with the radeon driver. I update the
X.org, drm, Mesa CVS once a week, but haven't found a working combination
since 4-5 months...

I don't intend to start a flame-war, but is there anybody who can use the
r200 driver without X crashes? I'm testing X.org CVS regularly (almost on
every weekend) with my RV280, with the latest linux 2.6 kernel.

I checked out X.org on last Saturday, played with Descent3 for some
minutes, it didn't crashed. Good. Restarted X, started Descent3 again, it
crashed almost immediately, as expected :(( That's why I have a 'shutdown
-r 5' in the background, when I test X.org CVS...

Compiled Mesa CVS, installed the libraries and the driver, started D3.
(Descent3 looks great, textures are visible, thanks to Eric Anholt's
projected texture patch which is in Mesa CVS) The game crashed X in a few
seconds. This was expected too :((

I tried out other OpenGL-based games, unfortunately, I can crash X with
almost every game I have - it is only a matter of time. I tried setting
color depth to 16 bit, changed the AGP to 1x in the system BIOS, none of
these helped.

Last time I used the 2.6.11-rc3 linux kernel, X.org CVS (updated on
20050205), Mesa CVS (20050205, linux-x86-dri target). I didn't built the
drm module, I used the kernel's radeon drm module. I used to test the drm
compiled from the CVS version, but I found out, that it is only a matter
of time to crash the X server, so I skipped the drm CVS test. Of course
the real tests will be these:

1. build and install everything from CVS, if the X server can be crashed,
 go to step 2, otherwise be happy :))
2. use the X.org CVS version with the stock kernel's drm, if X still
 crashes, go to step 3. Otherwise use the  X.org CVS, live without
 projected textures...
3. use the X.org and Mesa CVS versions. If X still crashes, then the bug
 can be in X.org or Mesa or in drm - I'm not able to trace down the
 problem.

Unfortunately all 3 scenarios give the same result: X crashes.

Is there any way I can help to track down the problem(s)? My machine
doesn't have network connection, so I can use only scripts which run in
the background. With expect and gdb maybe it is possible to get at least a
backtrace from my non-local-interactive machine.

Regards,

  Geller Sandor [EMAIL PROTECTED]


---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: OpenGL apps causes frequent system locks

2005-02-07 Thread Roland Scheidegger
Geller Sandor wrote:
I just removed the AGPFastWrite and DynamicClocks options. The crashes
still happen though.

Looks like not only I have problems with the radeon driver. I update the
X.org, drm, Mesa CVS once a week, but haven't found a working combination
since 4-5 months...
I don't intend to start a flame-war, but is there anybody who can use the
r200 driver without X crashes? I'm testing X.org CVS regularly (almost on
every weekend) with my RV280, with the latest linux 2.6 kernel.
I suspect that quite the contrary, almost noone has crashes. This is 
probably part of the problem, if they happen only for few people with 
very specific configurations, none of the developers can reproduce it 
and it will just remain unfixed.
For reference, I never get crashes with the r200 driver (on a rv250), at 
least none which I can't directly reference to my own faults when 
playing around with the driver... At least since the state submit fixes 
half a year ago the driver seems quite solid for me. Except the hard 
lockup I got for some very odd reason when I used a gart size of 64MB, 
though that was on a r100.

Roland

---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: OpenGL apps causes frequent system locks

2005-02-07 Thread Philipp Klaus Krause
Geller Sandor schrieb:
1. build and install everything from CVS, if the X server can be crashed,
 go to step 2, otherwise be happy :))
2. use the X.org CVS version with the stock kernel's drm, if X still
 crashes, go to step 3. Otherwise use the  X.org CVS, live without
 projected textures...
3. use the X.org and Mesa CVS versions. If X still crashes, then the bug
 can be in X.org or Mesa or in drm - I'm not able to trace down the
 problem.
Unfortunately all 3 scenarios give the same result: X crashes.
Is there any way I can help to track down the problem(s)? My machine
doesn't have network connection, so I can use only scripts which run in
the background. With expect and gdb maybe it is possible to get at least a
backtrace from my non-local-interactive machine.
I have the same problems with a rv250. It started about three or four
month ago. I always used the xlibmesa-gl1-dri-trunk Debian package and
the DRM that's included in the kernel. I'm now running 2.6.11-rc3
(which gave ma a ~10% increase in glxgears fps, but didn't help with
stability). Before these problems appeared (I don't remember if it
started with a kernel update or a DRI update) GL applciations wouldn't
crash, even when running for days. With fglrx stability back then was
as bad as it is today with DRI. I haven't tried fglrx since.
Maybe we should try to track down which changes introduced the
stability problems.
Philipp
---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: OpenGL apps causes frequent system locks

2005-02-07 Thread Alan Swanson
On Mon, 2005-02-07 at 19:24 +0100, Roland Scheidegger wrote:
 Geller Sandor wrote:
  I don't intend to start a flame-war, but is there anybody who can use the
  r200 driver without X crashes? I'm testing X.org CVS regularly (almost on
  every weekend) with my RV280, with the latest linux 2.6 kernel.
 I suspect that quite the contrary, almost noone has crashes. This is 
 probably part of the problem, if they happen only for few people with 
 very specific configurations, none of the developers can reproduce it 
 and it will just remain unfixed.
 For reference, I never get crashes with the r200 driver (on a rv250), at 
 least none which I can't directly reference to my own faults when 
 playing around with the driver... At least since the state submit fixes 
 half a year ago the driver seems quite solid for me. Except the hard 
 lockup I got for some very odd reason when I used a gart size of 64MB, 
 though that was on a r100.

I'd have to agree with Roland. I don't have any problems on either my
R200 or my rv250 using Mesa/DRM CVS (with X.org 6.8.1 approximately).

Hell, I'm finding the R200 driver is just getting better and faster.

(Both of which use a GART of 64Mb without problems, though which
 is slightly pointless  currently after recent discussions. ;-)

-- 
Alan.

One must never be purposelessnessnesslessness.


signature.asc
Description: This is a digitally signed message part


Re: OpenGL apps causes frequent system locks

2005-02-07 Thread Adam K Kirchhoff
Roland Scheidegger wrote:
Geller Sandor wrote:
I just removed the AGPFastWrite and DynamicClocks options. The crashes
still happen though.

Looks like not only I have problems with the radeon driver. I update the
X.org, drm, Mesa CVS once a week, but haven't found a working 
combination
since 4-5 months...

I don't intend to start a flame-war, but is there anybody who can use 
the
r200 driver without X crashes? I'm testing X.org CVS regularly 
(almost on
every weekend) with my RV280, with the latest linux 2.6 kernel.
I suspect that quite the contrary, almost noone has crashes. This is 
probably part of the problem, if they happen only for few people with 
very specific configurations, none of the developers can reproduce it 
and it will just remain unfixed.
For reference, I never get crashes with the r200 driver (on a rv250), 
at least none which I can't directly reference to my own faults when 
playing around with the driver... At least since the state submit 
fixes half a year ago the driver seems quite solid for me. Except the 
hard lockup I got for some very odd reason when I used a gart size of 
64MB, though that was on a r100.

Roland
Agreed, for the most part.  I use an 8500 and 9200 at work and at home.  
I regularly update my Mesa tree and build new version of the r200 
driver.  The only problems I've experienced is if I leave xscreensaver 
up and running all night, randomly choosing from the OpenGL 
screensavers...  I'll sometimes (once a week, maybe) find X locked 
solid, and only a reboot will get it working again.  The XiG drivers do 
this as well, the only difference being that I am able to just kill the 
GL screensavers that are locked up and get my display back :-)

I think perhaps the biggest culprit for this problem with the Mesa 
drivers is that I run a MergedFB desktop at 2560x1024, and each screen 
is supposed to display it's own screensaver, but that's just speculation.

Adam

---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: OpenGL apps causes frequent system locks

2005-02-07 Thread Richard Stellingwerff
I might be wrong, but the fglrx driver reported my card as being a
R280. It even ran at 8x AGP (A R280 feature, I've read). However, the
DRI radeon driver reports the cards as being a R250 running at 4x AGP.

I'm using an Acer laptop (Acer Ferrari 3000) with Ati Radeon Mobility
9200 M9+ 128MB.

I'd really like to have a stable system, but I'm not sure what to do
to figure out why it crashes. Are there some procedures I can follow
to determine the cause?


---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: OpenGL apps causes frequent system locks

2005-02-07 Thread Philipp Klaus Krause
Adam K Kirchhoff schrieb:
Agreed, for the most part.  I use an 8500 and 9200 at work and at home.  
I regularly update my Mesa tree and build new version of the r200 
driver.  The only problems I've experienced is if I leave xscreensaver 
up and running all night, randomly choosing from the OpenGL 
screensavers...  I'll sometimes (once a week, maybe) find X locked 
solid, and only a reboot will get it working again.
I have the sam eproblem with the GL screensavers. It wasn't there three
month ago. Many OpenGL applications work fine, but some just crash.
To reproduce the crashes gl-117 (a free fighter plane simulator)
seems to be the fastest way. It usually crashes within a few seconds.
Three month ago I had never seen it crash with the DRI drivers, even
when it ran for an hour.
Philipp

---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: OpenGL apps causes frequent system locks

2005-02-07 Thread Dave Airlie

Okay can we open a bug on this, attaching xorg.conf and Xorg.0.log to
it...

I'm running r200, both 8500LE and 9200 cards at home and work without
issue, except a recent bug report where if you run
gears/euphoria/gtk-pixbufdemo it locks after a good while (hours...) as
tracking that sort of bug takes forever, I'm waiting to until I have
forever time availabble to me :-).. but as I'm already tracking a
week-long crash on my M7 system for a job, I can't commit my test
system...

Dave.


On Mon, 7 Feb 2005, Philipp Klaus Krause wrote:

 Adam K Kirchhoff schrieb:

 
  Agreed, for the most part.  I use an 8500 and 9200 at work and at home.  I
  regularly update my Mesa tree and build new version of the r200 driver.  The
  only problems I've experienced is if I leave xscreensaver up and running all
  night, randomly choosing from the OpenGL screensavers...  I'll sometimes
  (once a week, maybe) find X locked solid, and only a reboot will get it
  working again.

 I have the sam eproblem with the GL screensavers. It wasn't there three
 month ago. Many OpenGL applications work fine, but some just crash.
 To reproduce the crashes gl-117 (a free fighter plane simulator)
 seems to be the fastest way. It usually crashes within a few seconds.
 Three month ago I had never seen it crash with the DRI drivers, even
 when it ran for an hour.

 Philipp



 ---
 SF email is sponsored by - The IT Product Guide
 Read honest  candid reviews on hundreds of IT Products from real users.
 Discover which products truly live up to the hype. Start reading now.
 http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
 --
 ___
 Dri-devel mailing list
 Dri-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dri-devel


-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: OpenGL apps causes frequent system locks

2005-02-07 Thread Stephane Marchesin
Roland Scheidegger wrote:
I suspect that quite the contrary, almost noone has crashes. This is 
probably part of the problem, if they happen only for few people with 
very specific configurations, none of the developers can reproduce it 
and it will just remain unfixed.
For reference, I never get crashes with the r200 driver (on a rv250), 
at least none which I can't directly reference to my own faults when 
playing around with the driver... At least since the state submit 
fixes half a year ago the driver seems quite solid for me. Except the 
hard lockup I got for some very odd reason when I used a gart size of 
64MB, though that was on a r100.
Here (rv100 with 64MB gart, no fast writes) playing torcs for too long 
causes gpu lockups. I think everything else (ut2003, quake 3, ) runs 
fine.

Stephane


---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


OpenGL apps causes frequent system locks

2005-02-06 Thread Richard Stellingwerff
Hi,

When using OpenGL applications I get frequent X crashes as well as
complete system locks. They happen totally random.

My hardware is an Ati Radeon Mobility 9200 M9+.
 
I'm using archlinux 0.7 with X.org 6.8.1 using the radeon driver. It
might be a configuration error on my part, so my xorg.conf can be
found at http://www.stellingwerff.com/xorg.conf for review.

I want to debug this issue, but I don't know where to start. When the
system locks, I can't ping the machine nor ssh to it, so that doesn't
make thing easier either...

One thing I noticed, is that the system locks up quicker when using
heavyweight OpenGL apps like Quake 3. Light OpenGL stuff generally
doesn't lock things up. This is just my perceiving though, and not
hard facts.


---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: OpenGL apps causes frequent system locks

2005-02-06 Thread Michel Dänzer
On Sun, 2005-02-06 at 19:29 +0100, Richard Stellingwerff wrote:
 
 When using OpenGL applications I get frequent X crashes as well as
 complete system locks. They happen totally random.
 
 My hardware is an Ati Radeon Mobility 9200 M9+.
  
 I'm using archlinux 0.7 with X.org 6.8.1 using the radeon driver. It
 might be a configuration error on my part, so my xorg.conf can be
 found at http://www.stellingwerff.com/xorg.conf for review.

Does it also happen without either or all of the options in the radeon
device section?


-- 
Earthling Michel Dnzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer


---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: OpenGL apps causes frequent system locks

2005-02-06 Thread Richard Stellingwerff
On Sun, 06 Feb 2005 13:45:47 -0500, Michel Dänzer [EMAIL PROTECTED] wrote:
 Does it also happen without either or all of the options in the radeon
 device section?

I just removed the AGPFastWrite and DynamicClocks options. The crashes
still happen though.

First I played some gish. I was able to play it for 15 minutes or so,
after that I got a black screen with vertical lines. See
http://www.stellingwerff.com/crash.jpg for a shot I took.

After that I tried some Neverball for 15 minutes, but no crashes.
Then, I tried Enemy Territory . I never actually got into the game, it
would keep crashing. But unlike before, it would not crash the whole
system. I was able to log in with ssh, where I noticed the following:

X froze completely
et.x86 was using 100% CPU
A little black square is drawn over the panel (I am running ET in
windowed mode).
I am able to kill et.x86, but as a result the 'X' process now starts
using 100% CPU.
I tried killing X, but that results in nothing. I did notice that X
now uses 0 VIRT, 0 RES and 0 SHR memory. The state of the X process is
now 'R'.
dmesg shows nothing, neither does Xorg.0.log.

So  I issue the 'reboot' command, and as a result I'm left with a
completely unresponsive system. Network connections are dead,
everything is. Have to hard-reboot.

Hopefully this sounds familiar to someone...


---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel