I tried installing Ubuntu Gutsy, and the included ati driver (something like 6.6.193) locked up. Downgrading to older driver fixed the problem. stable: Debian 6.6.3 ati driver package broken: 6.6.193, 6.7.192, 6.7.194 (current) The lockup happens within a few minutes, usually running Firefox and browsing some moderately graphics intensive site like launchpad.net makes it lock up quite fast. Sometimes the system locks up completely, sometimes mouse or the ACPI power button works. In some cases the power button did not do anything but I am not sure I had anything configured on it. Sometimes slight display corruption appears. The displayed picture does not update until poweroff. For X logs see https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/139210 Tested on two systems with recent ~ 2.6.21 Linux kernel, one old i440BX with Radeon 9000, other some Via chipset with Sempron CPU and Radeon 9250. The newest driver tested only on the later.
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"
Created attachment 11767 [details] 6.6.3 log (from the same Ubuntu system as the other logs)
Created attachment 11783 [details] log in pci mode Appears to work in PCI mode, at least does not lock up right away
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.
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?
(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?
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).
The current Git driver defaults to 1x again with non-v3 AGP cards.
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
Created attachment 13160 [details] [review] log with new driver on the K8 system
(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).
(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.
(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.
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.
(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?
Created attachment 21000 [details] lspci output
Created attachment 21001 [details] dmedecode output (might be relevant) this system defaults to 8x (not configurable in bios) but works only with 4x
committed: c0bcea9150ef215fa614733cef9a5b71a55a33bd Thanks.
The BX chipset is still broken: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/370205
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
Created attachment 27529 [details] Logs in etch where it was working without tweeks Logs on etch where it used to work
Created attachment 27530 [details] config file without tweaking AGPMode that used to work config file without tweaking AGPMode that used to work
(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
(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.
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.