Bug 8079 - r300 freezes system in agp-mode but not when glxgears etc. is running
Summary: r300 freezes system in agp-mode but not when glxgears etc. is running
Status: RESOLVED INVALID
Alias: None
Product: DRI
Classification: Unclassified
Component: General (show other bugs)
Version: DRI git
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-30 19:58 UTC by Dark Shadow
Modified: 2007-06-27 03:44 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg configuration file (mergedfb, agp, dri, glx) (16.11 KB, text/plain)
2006-08-30 20:06 UTC, Dark Shadow
no flags Details
kernel messages (67.31 KB, text/plain)
2006-08-30 20:06 UTC, Dark Shadow
no flags Details
lspci -v (6.41 KB, text/plain)
2006-08-30 20:07 UTC, Dark Shadow
no flags Details
xorg log file (no freeze because of glxgears running all the time) (69.07 KB, text/plain)
2006-08-30 20:10 UTC, Dark Shadow
no flags Details

Description Dark Shadow 2006-08-30 19:58:27 UTC
This is very strange indeed:

I. Start X with r300 driver in AGP 8x mode, launch firefox, evolution etc. and
wait a few minutes. X and keyboard will lock up, but mouse pointer can still be
moved. Same symptoms like those described in several forums (gentoo, ubuntu,
...) and some other bug reports here. I've found no info from the log files.

II. Start X, no config changes. Start glxgears and watch the gears moving. Start
browser, mail,... The system will not freeze. Not while glxgears are causing the
cpu to waste resources. If I move glxgears to an invisible workspace in fluxbox,
the behaviour is as described in I. The system will not freeze as long as
xscreensaver-demo is running, too.

III. Start X, using "BusType" "PCI" option. System is stable but of course a bit
more slowly. At least I don't have to start glxgears.

Workaround: Changing various AGP and driver options will not make any
difference, only disabling glx or setting BusType PCI will help.

Build date and platform: I'm using  libdrm, xf86-ati-driver, x11-drm, mesa and
mesa-progs from git sources on gentoo-2.6.17-r4 x86.

Using vesafb instead of the radeonfb kernel option didn't help as
https://bugs.freedesktop.org/show_bug.cgi?id=6573 suggests.

So I've got opengl and agp working somehow, and as long as I keep my graphics
card busy, it will not make my system crash. Currently, glxgears is running and
I'm getting tired of it. If there is any information I can provide, I would be
glad doing so to help you solve this bug.

I'll provide xorg.conf and Xorg.0.log files, along with lspci and kernel log.
Comment 1 Dark Shadow 2006-08-30 20:06:02 UTC
Created attachment 6755 [details]
xorg configuration file (mergedfb, agp, dri, glx)
Comment 2 Dark Shadow 2006-08-30 20:06:42 UTC
Created attachment 6756 [details]
kernel messages
Comment 3 Alex Deucher 2006-08-30 20:07:55 UTC
Can you try with the latest radeon ddx?  This may be related to keeping the CP
clock forced on:
http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=commit;h=4b1904017caa976c138594a86e75feaf470e72b5
Comment 4 Dark Shadow 2006-08-30 20:07:57 UTC
Created attachment 6757 [details]
lspci -v
Comment 5 Dark Shadow 2006-08-30 20:10:26 UTC
Created attachment 6758 [details]
xorg log file (no freeze because of glxgears running all the time)

The card is an ATI Radeon 9500 Pro 128 MB.
Comment 6 Alex Deucher 2006-08-30 20:16:57 UTC
(In reply to comment #3)
> Can you try with the latest radeon ddx?  This may be related to keeping the CP
> clock forced on:
> 

nevermind.  looks like you are already using 6.6.2.
Comment 7 Michel Dänzer 2006-08-31 01:41:53 UTC
(In reply to comment #0)
> The system will not freeze. Not while glxgears are causing the cpu to waste
> resources.

FWIW, I doubt it's the CPU that matters but more likely the GPU. Tweaking the
driconf settings vblank_mode and fthrottle_mode may help reduce CPU usage while
hopefully preserving the same effect. Also, making the window smaller may
preserve the effect as well. I know it's still an ugly workaround, but maybe
this'll make it a little more bearable. :)


> Workaround: Changing various AGP and driver options will not make any
> difference, only disabling glx or setting BusType PCI will help.

So you've tried commenting out all AGP options, BackingStore, ColorTiling,
EnablePageFlip and DynamicClocks?

PS: Why do you set NoMTRR?
Comment 8 Dark Shadow 2006-08-31 07:42:15 UTC
(In reply to comment #7)
> (In reply to comment #0)
> > The system will not freeze. Not while glxgears are causing the cpu to waste
> > resources.

> FWIW, I doubt it's the CPU that matters but more likely the GPU. Tweaking the
> driconf settings vblank_mode and fthrottle_mode may help reduce CPU usage while
> hopefully preserving the same effect. Also, making the window smaller may
> preserve the effect as well. I know it's still an ugly workaround, but maybe
> this'll make it a little more bearable. :)

fthrottle_mode=0, vblank_mode=0: 100% CPU usage, but no freezes.
fthrottle_mode=0, vblank_mode=3: 0% CPU usage, even with big window. Freezes
after a while.

fthrottle_mode=1, vblank_mode=0: CPU usage is very low. After a few minutes,
both monitors suddenly go blank (switch off), keyboard is dead, I have to push
the reset button. Nothing in log files.
fthrottle_mode=1, vblank_mode=3: 0% CPU usage. Again, freezes.

fthrottle_mode=2, vblank_mode=0: System seems to run stable (testing for at
least 25 minutes now). But this is strange: CPU usage is at medium level (around
55-70%) at normal size. When I resize the glxgears window so that it becomes
smaller, CPU usage *increases* to around 80-90%.  Now I increase the window so
that it is bigger than the standard size. CPU usage goes down to 10-25%. I have
no clue why, this makes no sense to me. When I increase the window once more,
CPU usage will slightly go up again. A nearly full-size window will consume
about 50% cpu resources. However, the smaller the glxgears window, the more
responsive the other applications become; a bigger glxgears window makes
everything else become a bit slower.
fthrottle_mode=2, vblank_mode=3: 0% CPU usage. Freezes.

So far, fthrottle_mode=2, vblank_mode=0 seems to be the best option. I'm not
quite sure this is 100% stable though, but until now it works. If it freezes,
I'll report this of course.

I agree this is not a problem with the CPU usage, but it seems to be somehow
related to it. Generating high CPU usage without OpenGL applications still
freezes the system. Maybe, now at least we can narrow the problem to a specific
module? I actually don't expect it to be Mesa but I have no knowledge of these
things...

Is there anything else I could try?

> > Workaround: Changing various AGP and driver options will not make any
> > difference, only disabling glx or setting BusType PCI will help.

> So you've tried commenting out all AGP options, BackingStore, ColorTiling,
> EnablePageFlip and DynamicClocks?
Yes, but to be on the safe side, I've tried it again. It didn't help though.
These options are on when using BusType PCI and don't have any bad influence there.

> PS: Why do you set NoMTRR?
For no particular reason. I've just searched for solutions on various forums and
tried out all the options I could find. I have turned it off now, but it doesn't
make any difference either.
Comment 9 Dark Shadow 2006-08-31 13:51:35 UTC
(In reply to comment #8)

> So far, fthrottle_mode=2, vblank_mode=0 seems to be the best option. I'm not
> quite sure this is 100% stable though, but until now it works. If it freezes,
> I'll report this of course.

Update: The system crashed with these settings while performing emerge --sync in
background on tty1.

> fthrottle_mode=0, vblank_mode=0: 100% CPU usage, but no freezes.
But this seems safe. No freezes even when emerging packages... so far.
Comment 10 Tormod Volden 2006-12-08 03:33:25 UTC
Can you try setting AGP speed to 8x in your BIOS settings? This is reported to
help for people having similar problems in Ubuntu https://launchpad.net/bugs/67487
I wonder if this is the same issue, or if a new bug should be filed here for
that Ubuntu issue. (There is a lot of noise in that bug report, but it boils
down to 9200-9800 AGP cards.)
Comment 11 Tormod Volden 2006-12-12 11:11:46 UTC
Sorry, I meant 4x (instead of 8x).
Comment 12 Dark Shadow 2007-06-27 03:44:13 UTC
I just want to let you know that this was indeed a hardware failure. The ATI card exhibited the same issues on another computer, while a Nvidia card works fine.

Thanks for your help so far.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.