If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

HD 2600 PRO AGP - driver problems

01-12-2008, 06:25 PM

Recently I've installed a Sapphire HD2600Pro AGP card instead of my beloved nVidia 7600GS (I needed to help my family where another video card broke). I was able to install the Windows XP drivers - although only the ones provided on CD worked. But in Linux it's hopeless. Let me explain.

After installing Catalyst 7.12 drivers in Ubuntu 7.10 the X.org is unable to turn on the high resolution mode on my LCD (1680x1050 @ Samsung SyncMaster 2232), and only the failsafe X kicks in. The Xorg.0.log shows no signs of errors (EE), serious warnings (WW) and the like. I've checked my xorg.conf many times and having a 5+ years of experience with various distros (including Gentoo for example, where you have to basically write xorg.conf or you have no X at all) I must say that the xorg.conf is rather fine.

My suspicions started to rise when the downloaded from AMD/ATI site display drivers refused to install in Windows XP (I've tried 7.12, 7.11 and 7.10). The installer simply stated that it was unable to detect the hardware. But hey, drivers from supplied CD worked! I did a simple "diff -u" on the *.INF files from the different drivers releases and it occured to me that in every ATI driver some generic information was missing.

If your AGP card is not supported by the latest ATI drivers...
Sometimes the drivers don't get updated for every card for every driver release, so you need to edit a couple files to add your card. Run the installer, and continue until you extract the driver into a folder under C:\ATI\SUPPORT\. At the next opportunity, cancel the installation and navigate to the C:\ATI\SUPPORT\ folder in Windows Explorer. Edit the files as follows, and you can then run C:\ATI\SUPPORT\{Current Version}\Driver\setup.exe.

When I re-checked the differences in *.INF files I've found it became obvious that the Sapphire released the drivers that include support for "9587 device", but the original ATI Catalyst drivers DO NOT.

Using the above procedure I was able to install the 7.12 drivers in Windows XP for this problematic HD2600Pro AGP card. But in Linux I begin to feel that this is hopeless. Especially if the source of this problem is the same: some missing descriptions in the binary, closed driver that prevent correct device detection.

This graphics chip is designed with PCI-E in mind and is "backported" to work with the AGP bus. What's sad is that this is the best chip in market, budget wise, for AGP at the moment! (there are HD2400 & HD2600 cards, in Pro & XT variants). And the ATI driver doesn't work in Linux and the product is not even registered in the PCI ID database...

Comment

The information you found from Saphire is really helpful with regards to the windows installer problem.
I also filed a ticket with ATI support for that "no compatible hardware found" error so perhaps that triggered them to write this KB article.
-edit- I forgot to mention that the ATI help I got for that issue was abysmally bad. They told me to download and try the 7-7 catalyst bundle. Not only did it result in the same error, but when I verified in the readme, it was clear that the bundle was from a time when the HD2xxx cards hadn't even been released yet.
The later response I got from the support guy suggested he thought I had a RADEON 1950 AGP card even though I clearly wrote I had a HD2600XT in each and every update I made to the ticket.

I did find another way to circumvent the problem in Windows XP. After a failed catalyst install, remember where you told the program to unpack the drivers. (Usually C:\ATI). Just go to Windows device manager (under right-click "My Computer", select 'properties' or via the control panel),
browse to the entry for the 2600 (XT in my case) Display Adapter,
right-click, select properties and then click the "update drivers" button on the 'driver' tab.
(this probably works in Vista too but I didn't test that).

Once in that dialog, say no to any of the automagic detection options and choose the "I will tell windows what driver to install" and "browse" and "select a different location" options (can't remember the correct order, sorry)

Browse (in my example) to C:\ATI\support\7-12_xp32_dd_ccc_wdm_enu_55811\Driver\Driver\xp_inf directory and have XP accept the inf file there.
Select the HD2600 Pro or XT from that list (no difference between a PCIe or AGP card there it seems) and roll with it.
Windows will protest that it's not certified for your hardware, but just confirm / overrule.
It has worked fine for me.

p.s. I also can't get fgrlx working on my hd2600xt agp. I either get a black=screen freeze or a half-way through the screen build-up freeze. I haven't tried lowering my resolution yet but with the radeonhd driver and randr turned off, I don't have to so I'll suffer with that some more.

p.s. the ATI links you posted didn't work directly, but while browsing the support site, I found another interesting one: apparently there's a potential directx problem.
If you browse any support topic, and then, in the address bar of the browser, you change the ID= bit into ID=31542 instead, you find some links to as yet untested / unreleased catalyst 8-1 driver packages at the bottom of that page! (Downloading them as I write this [;-)] )

Comment

here is the xorg.conf that is generated by default after the installation of the latest ATI driver.

If I reeboot with that driver I will get a black screen and a frozen computer. So ..... What's wrong with it??

1st, your xorg.conf contains two, conflicting, "screen" sections. One still invokes "device1" which is the section containing a reference to the radeonhd drvier.
The other invokes "aticonfig-Device[0]" which contains a reference to fglrx.

The latter one SHOULD be the one that gets loaded but it is probably a good idea to clean up your xorg.conf to remove all those references that are tied in to the "screen" invocation with Identifier "screen1".

2nd. You are probably hitting the same problem that I've been hitting with almost any fglrx driver since release build 8.42 or so (Catalyst 7-9 linux equivalent, they didn't switch to 7-?? numbering until 7-11) with my HD2600XT AGP (and no driver before 8.42 supported the HD2xxx series cards):
a hanging X screen.
Usually it blacks out showing nothing but with 7-11 / 8.433 I managed to get it working somewhat, until the first button on screen had to be drawn (the Greeter login button) at which point the rest of the screen would be filled with white in 64x64 pixel blocks. And hang the system.
Apparently the fglrx driver doesn't like resolutions other thant multiples of 64 by multiples of 64, which might explain the hang but I've no idea how to force it down from the 1600x1200 that I usually run my display at.
Probably add the proper MOdes line to xorg.conf but at this point I've decided not to bother any longer.
I should probably go back to that driver and try with 1280x1024, but I have radeonhd working in 1600x1200, so why bother?
I'll just wait until the developers of radeonhd add support for 3D / OpenGL.
I need the 1600x1200 more (photo editing and the like) than I need the 3d accel (GoogleEarth being the only app I used to use that truly needs it).
Until then, I've given up on fglrx on my shiny new but seemingly rather unsupported AGP card.

Comment

Apparently the fglrx driver doesn't like resolutions other than multiples of 64 by multiples of 64, which might explain the hang but I've no idea how to force it down from the 1600x1200 that I usually run my display at.
Probably add the proper MOdes line to xorg.conf but at this point I've decided not to bother any longer.

As I understand it, only the workstation code paths (ie the ones which run on FireGL parts) have the 64-pixel issue. Your card should not care about having H resolution be a multiple of 64 pixels.

[EDIT] Looks like there is a workaround for the 64-bit issue -- using a slightly wider virtual screen which *is* a multiple of 64 even if your physical screen is not.