[RV280] X locks up - wrong agp mode

[Michal Suchanek]

Binary package hint: xserver-xorg-video-ati

It seems the agp mode for this system is detected wrong for this system.

The installation locks up unless I switch to the console during the non-interactive part and after installation X locks up very fast with all the effects enabled.

Setting AGPMode to 1 resolves the issue.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
MediaBuild: Ubuntu 9.04 "Jaunty Jackalope" - Release i386 (20090420.1)
Package: xserver-xorg-video-radeon 1:6.12.1-0ubuntu2
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersion: Linux version 2.6.28-11-generic (buildd@palmer) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009
SourcePackage: xserver-xorg-video-ati
Uname: Linux 2.6.28-11-generic i686
UnreportableReason: This is not a genuine Ubuntu package

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge [8086:7190] (rev 03)
     Subsystem: Creative Labs Device [1102:8027]
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV280 [Radeon 9200] [1002:5961] (rev 01)
     Subsystem: PC Partner Limited Device [174b:7c13]

[Airlied-freedesktop (airlied-freedesktop)]

can you post a log from your 6.6.3 working driver?

also do Option "BusType" "PCI"
in the driver section help..

what about
Option "RenderAccel" "off"

[Michal Suchanek (hramrach)]

Created an attachment (id=11767)
6.6.3 log (from the same Ubuntu system as the other logs)

[Michal Suchanek (hramrach)]

Created an attachment (id=11783)
log in pci mode

Appears to work in PCI mode, at least does not lock up right away

[Michal Suchanek (hramrach)]

ouch, the older card is radeon 9200, not 9000. That was in another box.

I'm running the 9200 in pci mode for some time now, and I did not notice any problems.

[Michal Suchanek (hramrach)]

It appears to work with AGP 1x as well.

I read somewhere that setting these old radeons to higher AGP modes (or modes other than that set by the BIOS) causes trouble. Did the default change from 1x to 2x recently?

[Sroland-vmware (sroland-vmware)]

(In reply to comment #5)
> It appears to work with AGP 1x as well.
>
> I read somewhere that setting these old radeons to higher AGP modes (or modes
> other than that set by the BIOS) causes trouble. Did the default change from 1x
> to 2x recently?
It changed from 1x to whatever was set before (excluding fast writes) by the BIOS by default, since there were some problems with the old scheme.
Since this works for you with AGP 1x, it indeed looks like AGP 2x doesn't work stable for your setup. Which is pretty weird, I've never heard of BX chipset making trouble with AGP 2x (I've certainly used that), nor that 9200 would be problematic with AGP 2x. (That is, unless you overclock the FSB to 133 on these boards which will give you 89Mhz AGP instead of 66, or have one of those with a AGPFS jumper which will give 100Mhz AGP clock at 100Mhz FSB if set wrong). The only radeons I know of being problematic with AGP are some early radeon 9700 which had problems with some chipsets at AGP 8x speed.
Just to clarify, you have two different rv280-based cards which don't work stable at AGP 2x but work at AGP 1x in two completely different boards?

[Michal Suchanek (hramrach)]

I have two different cards (9200 and 9250) in two different boards (BX chipset and some K8 chipset) which show the same symptoms.

I have switched the system with BX board to 1x which works but I haven't tested the fix on the K8 system because it is not in use.

The BX board does only 100Mhz (and 66Mhz) fsb but I am not sure if there is some AGP jumper that needs tweaking. There is nothing like that mentioned in the manual. It says something about cpu frequency selection jumpers but this appears to be configurable in the bios. The cpu runs at the expected frequency (6x100 because it is a 6x133 PIII).

[Michel-tungstengraphics (michel-tungstengraphics)]

The current Git driver defaults to 1x again with non-v3 AGP cards.

[Michal Suchanek (hramrach)]

I am not sure this solves anything. On the K8 system the card appears as AGP v3 device and is swiched to 4x by the old driver and to 8x by the new driver. There is readonly (grayed out) setting for AGP mode which is fixed at 8x.

Does the card appear as different AGP version on different system? Or did they change that between 9200 and 9250?

[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 20
[drm] Initialized radeon 1.25.0 20060524 on minor 0
ip_tables: (C) 2000-2006 Netfilter Core Team
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
[drm] Setting GART location based on new memory map
[drm] Loading R200 Microcode
[drm] writeback test succeeded in 1 usecs
eth0: no IPv6 routers present
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode
[drm] Loading R200 Microcode
agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode

[Michal Suchanek (hramrach)]

Created an attachment (id=13160)
log with new driver on the K8 system

[Sroland-vmware (sroland-vmware)]

(In reply to comment #9)
> Does the card appear as different AGP version on different system? Or did they
> change that between 9200 and 9250?
Yes certainly, this not only depends on the card but also the host. BX is AGP V1, with rates supported 1x,2x, and the K8 chipset apparently is V3. You cannot switch a AGP V3 system to 1x mode since it only supports rate 4x and 8x. The card supports all 3 AGP versions (the K8 chipset certainly would support V2 too, but if the bios doesn't support switching it to V2 manually you can't change that after bootup).

[Michel-tungstengraphics (michel-tungstengraphics)]

(In reply to comment #9)
> I am not sure this solves anything.

It should at least fix the default behaviour on one of your machines.

> On the K8 system the card appears as AGP v3 device and is swiched to 4x by
> the old driver and to 8x by the new driver.

So does it work with Option "AGPMode" "4" with the new driver?

> There is readonly (grayed out) setting for AGP mode which is fixed at 8x.

Maybe it can only be changed depending on some other settings?

We changed the default to leaving the rate unchanged because there were reports of failure with 4x but success with 8x when the latter is set in the BIOS. If it's the other way around on some systems like yours, we're screwed... unless we're missing something.

[Michal Suchanek (hramrach)]

(In reply to comment #12)
> (In reply to comment #9)
> > I am not sure this solves anything.
>
> It should at least fix the default behaviour on one of your machines.

yes, and it will hopefully also fix the r100 crash.

>
> > On the K8 system the card appears as AGP v3 device and is swiched to 4x by
> > the old driver and to 8x by the new driver.
>
> So does it work with Option "AGPMode" "4" with the new driver?

Yes, it worked for a while. I tried only from a live cd but I was able to browse the web which usually crashes very fast when the setting is incorrect.

>
> > There is readonly (grayed out) setting for AGP mode which is fixed at 8x.
>
> Maybe it can only be changed depending on some other settings?

None I am aware of. The settings in the AGP section of the bios do not change the value and do not enable changing it.

>
> We changed the default to leaving the rate unchanged because there were reports
> of failure with 4x but success with 8x when the latter is set in the BIOS. If
> it's the other way around on some systems like yours, we're screwed... unless
> we're missing something.

fwiw there is a report of Radeon 7200 crashing at >1x and Radeon 9600 crashing at 8x in the referenced launchpad bug. But there are no details.

Generally if changing the bios setting makes a difference we are probably missing something because the gart driver should be able to change the mode as well.

It may be even that the bios is defective and does not set up the card properly for 8x, and the gart driver does not do it either.

Unfortunately I probably do not have access to enough hardware (and enough time) to find out which part is broken. Either of board/chipset/bios/card/driver can be sub-spec or broken, or some combination.

[Michal Suchanek (hramrach)]

Actually this is not fixed.

I was able to reproduce the lockup with a recent live CD on the K8 system.

Problem resolved by pulling out the AGP card and using just the onboard video.

It looks like this won't be resolved until the driver can work without relying on the BIOS to set up the card because different BIOSes do different things.

[agd5f (agd5f)]

(In reply to comment #14)
> Actually this is not fixed.
>
> I was able to reproduce the lockup with a recent live CD on the K8 system.
>
> Problem resolved by pulling out the AGP card and using just the onboard video.
>
> It looks like this won't be resolved until the driver can work without relying
> on the BIOS to set up the card because different BIOSes do different things.
>

At this point we are adding quirks to set the proper agp modes on specific GPU/chipset combinations. Are there AGP modes that works for your specific setups?

[Michal Suchanek (hramrach)]

Created an attachment (id=21000)
lspci output

[Michal Suchanek (hramrach)]

Created an attachment (id=21001)
dmedecode output (might be relevant)

this system defaults to 8x (not configurable in bios) but works only with 4x

[agd5f (agd5f)]

committed: c0bcea9150ef215fa614733cef9a5b71a55a33bd

Thanks.

[Michal Suchanek (hramrach)]

Binary package hint: xserver-xorg-video-ati

It seems the agp mode for this system is detected wrong for this system.

The installation locks up unless I switch to the console during the non-interactive part and after installation X locks up very fast with all the effects enabled.

Setting AGPMode to 1 resolves the issue.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
MediaBuild: Ubuntu 9.04 "Jaunty Jackalope" - Release i386 (20090420.1)
Package: xserver-xorg-video-radeon 1:6.12.1-0ubuntu2
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersion: Linux version 2.6.28-11-generic (buildd@palmer) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009
SourcePackage: xserver-xorg-video-ati
Uname: Linux 2.6.28-11-generic i686
UnreportableReason: This is not a genuine Ubuntu package

[Michal Suchanek (hramrach)]

The BX chipset is still broken:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/370205

[sly (liste-letuffe)]

Just a ping to confirm the problem still exists with same behaviour and fresh driver comming from git right now.

I known this board is rather old and interest might be lower, but in any case someone use this page to get a work around, here is my report :
(Feel free to ask additionnal information)

(Config is debian lenny's X.Org X Server 1.4.2
Release Date: 11 June 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux Debian (xorg-server 2:1.4.2-10.lenny2)
)
Drivers is 6.12.99 manually compiled

logs :
(II) LoadModule: "radeon"
(II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so
(II) Module radeon: vendor="X.Org Foundation"
        compiled for 1.4.2, module version = 6.12.99
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 2.0
(...)
(--) Chipset ATI Radeon 9200SE 5964 (AGP) found
(...)
(==) RADEON(0): Using AGP 8x

xorg.conf :
With a basic section of
Section "Device"
        Identifier "Carte vidéo générique"
        Driver "radeon"
EndSection

lspci :
01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (Secondary) (rev 01)

Trying to force Option "AGPMode" "1" gives :
(EE) RADEON(0): Illegal AGP Mode: 1 (valid values: 4, 8), leaving at 8x

Setting :
Option "AGPMode" "4"
Solves the problem

It looks a regression to me because this machine has been doing well for a few years with etch with same config and with logs :
X Window System Version 7.1.1
(...)
(WW) RADEON(0): [dri] detected radeon kernel module version 1.19 but 1.23 or newer is required for full memory mapping.
(...)
(II) Module radeon: vendor="X.Org Foundation"
        compiled for 7.1.1, module version = 4.2.0
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 1.0

[sly (liste-letuffe)]

Created an attachment (id=27529)
Logs in etch where it was working without tweeks

Logs on etch where it used to work

[sly (liste-letuffe)]

Created an attachment (id=27530)
config file without tweaking AGPMode that used to work

config file without tweaking AGPMode that used to work

[agd5f (agd5f)]

(In reply to comment #19)
> The BX chipset is still broken:
>
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/370205
>

quirk committed:
69b5e5496f10a9f566d2e563862c96cb41952eb6

[agd5f (agd5f)]

(In reply to comment #20)

> Setting :
> Option "AGPMode" "4"
> Solves the problem

quirk committed:
43db263d301082e84e9bc304816bcbb206fe280e

>
> It looks a regression to me because this machine has been doing well for a few
> years with etch with same config and with logs :
> X Window System Version 7.1.1
> (...)
> (WW) RADEON(0): [dri] detected radeon kernel module version 1.19 but 1.23 or
> newer is required for full memory mapping.
> (...)
> (II) Module radeon: vendor="X.Org Foundation"
> compiled for 7.1.1, module version = 4.2.0
> Module class: X.Org Video Driver
> ABI class: X.Org Video Driver, version 1.0
>

It used to work because older versions of the driver defaulted to the lowest AGP mode (1x or 4x). The default behavior was later changed to leave the AGP mode as set by the bios which proved more reliable in most instances. There are exceptions like your board. Now we add quirks for specific problematic combinations.

[Tormod Volden (tormodvolden)]

Michal, a quirk for your hw combination was now added upstream. You can find test packages at https://launchpad.net/~xorg-edgers/+archive/drivers-only

[Michal Suchanek (hramrach)]

2009/7/11 Tormod Volden <email address hidden>:
> Michal, a quirk for your hw combination was now added upstream. You can
> find test packages at https://launchpad.net/~xorg-edgers/+archive
> /drivers-only
>
> ** Changed in: xserver-xorg-video-ati (Ubuntu)
>       Status: Confirmed => Fix Committed

Unfortunately I cannot test the patch because the mainboard no longer works.

Thanks

Michal

[Bryce Harrington (bryce)]

Since the hardware is no longer available for doing troubleshooting with, we'll have to close the bug for now. However please feel free to reopen if you or anyone else has the same HW and can reproduce this issue using the latest development version of Ubuntu and is willing to do some troubleshooting with it.

[Michal Suchanek (hramrach)]

2009/8/1 Bryce Harrington <email address hidden>:
> Since the hardware is no longer available for doing troubleshooting
> with, we'll have to close the bug for now.  However please feel free to
> reopen if you or anyone else has the same HW and can reproduce this
> issue using the latest development version of Ubuntu and is willing to
> do some troubleshooting with it.
>

This is not going to be completely resolved until the X server can
determine the correct AGP mode from the hardware state.

Currently it guesses it, and sometimes guesses wrong so some hardware
configurations are broken.