PROBLEM: Hangup with Radeon9200 accel. Does not happen when not using agpgart or disabling CPU internal cache.

PROBLEM: Hangup with Radeon9200 accel. Does not happen when not using agpgart or disabling CPU internal cache.

[Juanjo García Carré]

-Foreword: I am not complaining; just hoping to help in developing
a better kernel.

-Symptom: When accelerating graphics, the machine freezes completely
(no response to emergency sys req keys or net access).
As a consequence, NOTHING GETS LOGGED (sorry).

-How to reproduce:
1) Use the following hardware:
Radeon 9200 AGP graphics card.
CPU PentiumII Deschutes  (Tried the same card on an
Athlon machine -all the rest being equal- and the problem did not happen).
baseplate Tyan (This means Intel 440BX chipset)

2) Enable in BIOS the CPU internal cache to
"Write Back" mode.
(Either "Write Thru" or "Disabled" will eliminate the problem,
at the expense of an extremely low performance).

3) Use ANY Linux-2.6.0-test kernel, or ANY
Linux-2.4 kernel, (in which case you will need 
an updated version for the radeon module).

4) Use XFree86 4.3.0 or over (for radeon acceleration support) with ANY
dri version (older or newest).
I have tried the latest DRI CVS without success.

5) In the XF86Config-4 file, specify the chipset of a Radeon 9100 or
another radeon for which acceleration is already supported (I know this is not
the factor to blame, since -as I said before- it works on an Athlon machine).

6) In the XF86Config-4 file, make sure the option ForcePCIMode is off
(when it is enabled, everything works fine and you need no agpgart
module, but performance is halved).
_ALL_ the other options are indifferent in order to reproduce the
problem, (even the option to use the XFree GPL radeon driver or the propietary
FireGL drivers from Ati).

7) Make sure the agpgart module (and the intel_agp module for 2.6
kernels) are loaded before launching XFree.

8) Launch X. Everything seems to work; glxinfo says Yes as to direct
rendering. Now launch an OpenGL application, like glxgears:
It runs for some instants, then becomes blocked, as does the rest of the
system.

Observation: When a big Graphics Aperture Size (256MB) is specified in
BIOS (thus adopted by the agpgart module) and a small one (4MB) in the
XF86Config-4 file, then the time until crash is considerably increased.
(Does this mean anything to you?)

Please reply with Cc to  juanjo@eurogaran.com  because I am not
suscribed to any kernel mailing list.

Thank you.

Re: PROBLEM: Hangup with Radeon9200 accel. Does not happen when not using agpgart or disabling CPU internal cache.

[Erik Andersen]

On Mon Oct 20, 2003 at 12:01:23PM +0200, Juanjo García Carré wrote:
> 7) Make sure the agpgart module (and the intel_agp module for 2.6
> kernels) are loaded before launching XFree.
> 
> 8) Launch X. Everything seems to work; glxinfo says Yes as to direct
> rendering. Now launch an OpenGL application, like glxgears:
> It runs for some instants, then becomes blocked, as does the rest of the
> system.

I added this to my /etc/X11/XF86Config-4 to prevent my system
from locking solid as you describe.  This forces XFree86 to drive
my Radeon 9200 as if it were a Radeon 9000.  Before upgrading X,
I had to use 0x4242 to drive my card as a Radeon 8500.

Section "Device"
        Identifier      "ATI Radeon"
        Driver          "radeon"
        Option          "AGPMode"  "4"
        Option          "EnablePageflip"  "1"
        ChipID          0x4964
        #ChipID         0x4242
EndSection

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: PROBLEM: Hangup with Radeon9200 accel. Does not happen when not using agpgart or disabling CPU internal cache.

[Juanjo García Carré]

Sorry to tell you that the proposed work-around
         ChipID          0x4964
did not work.

Thanks a lot for your time and advice.

Re: PROBLEM: Hangup with Radeon9200 accel. Does not happen when not using agpgart or disabling CPU internal cache.

[Juanjo García Carré]

 

I finally managed to find the cause of the problem:

- It was not software.
Sorry for the unnecessary annoyance, people from the kernel and XFree lists! 
I will try to compensate by telling you what happened, just in case
you would face anything similar.

- It was neither the hardware.

- It was BIOS, but...
	- It was not a problem with BIOS settings.
	- It was not a problem of BIOS version.
	- The BIOS in fact can work perfectly.

Intrigued ?
Be prepared for one of the strangest stories of computer malfunction:

I bought a recent graphics card (Radeon 9200) for a not so recent
computer (Pentium2 with Intel440BX chipset).

I found Linux freezed completely whenever I tried to use acceleration,
which did not happen when using Windows with the same machine, nor the
same card on another -dissimilar- machine.
So I begun to search for flaws in the IntelAGP kernel module and/or the
Direct Rendering Interface, something that proved unsuccesful.
(I deeply thank everyone who tried to help me with this).

Frustrated, I decided to flash the BIOS with the latest version from the
manufacturer and... It worked !!!

But... Wait!... Isn't this the same BIOS version that was already installed?

Didn't I tried to load default and fail-safe settings with no positive result?

Mmmmm.... Let's see... Let's try changing some parameters....
It stops working again !!!

Let's return those parameters to their previous values... NO SUCCESS.

This is the bizarre part:

IT COULD NOT BE MADE TO WORK AGAIN, REGARDLESS OF THE PARAMETERS SETTINGS,
unless CMOS was cleared using the motherboard jumper.

I checked the fenomenon a dozen times. Moreover, after enough fiddling with
the bios parameter settings, even Windows begins to freeze
(always regardless of the concrete values introduced)
until CMOS is hard-reset again.

Possible explanations:
1- The system does not truly restart after changing values.
This possibility was easy to discard by powering off, waiting 2 minutes
and then powering on.
2- Values saved and shown later by the BIOS do not correspond in fact
to real ones.
3- The BIOS gets somehow corrupted when changing its parameters.
4- The BIOS is slowly getting corrupted by aging:
We all know today's hardware decomposes with time. I have seen
circuit boards that became pastous, sticky, degraded in only a couple of
years. (Learn the lesson. Don't throw away your old hardware!)
If this is so, in the future I will see how not even the jumper
erasing method will work.

For those interested, the "magic BIOS" corresponds to:

BasePlate:    Tyan    Mod. S1846 Tsunami ATX   2.00.04 031320011030
BIOS:         Ami     686 AMIBIOS (c)1999 AE12 4885
BIOS chip:    WinBond W29C020-90