AMD Catalyst 9.1 Brings OpenGL 3.0

[nbi1]

Working catalyst 9.1 with 4850: http://pastebin.com/m26fcd18f

Edit: Oops, please remove the Modeline and the Gamma lines from the monitor section, these are specific to my old CRT.

Like you I have a 4850. We might even have the same model although I doubt it (mine is the 512MB HIS version from TigerDirect).

I can't for the life of me get 8.12 or 9.1 working with Debian Lenny despite having followed standard procedures which were successful for others (such as building and installing the kernel module via module assistant).

Could you please post your kernel's .config and the output from `lsmod`?
Many thanks.

[nbi1]

What you are missing is the reset of /etc/ati, I usually purge that dir completely after uninstalling *fglrx*/*amdx* packages before installing new ones. All this is done automatically with

http://kanotix.com/files/install-fglrx-debian.sh

Thanks, but that didn't help. As you may recall I've been wrestling with ATI under Debian Lenny for some time. I have tried using your script previously but the results are exactly the same as when I followed the accepted manual procedures: everything builds and installs cleanly but when boot completes I'm left with a mangled X display (which btw is always mangled in exactly the same way). Most of the time I can exit this mangled X display via ctrl-Alt-BS to get to a text tty so at least it isn't a hard lockup as some have reported. Until I see the .config and `lsmod` output from a working 4850 configuration I don't think I can make progress on this.

[nbi1]

Same old shit. Clean build and install results in the same failure mode: mangled X display. When I look at /var/log/Xorg.0.log what do I see? Same culprits as before:

drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: Open failed
drmOpenByBusid: drmOpenMinor returns -19
(WW) fglrx(0): Failed to open DRM connection
(EE) fglrx(0): [FB] Can not get FB MC address range.

(EE) fglrx(0): atiddxDriScreenInit failed, GPS not been initialized.
(WW) fglrx(0): ***********************************************
(WW) fglrx(0): * DRI initialization failed! *
(WW) fglrx(0): * (maybe driver kernel module missing or bad) *
(WW) fglrx(0): * 2D acceleraton available (MMIO) *
(WW) fglrx(0): * no 3D acceleration available *

(EE) fglrx(0): XMM failed to open CMMQS connection.

(EE) fglrx(0): PPLIB: PPLIB is not initialized!.
(EE) fglrx(0): PPLIB: swlPPLibNotifyEventToPPLib() failed!
(EE) fglrx(0): ulEventType = 0000000c, ulEventData = 00000001

So I figured lets see what happens when I try loading the fglrx module (which built cleanly btw) from the command line:

modprobe fglrx
[fglrx] Maximum main memory to use for locked dma buffers: 5755 MBytes
[fglrx] vendor: 1002 device: 9442 count: 1
[fglrx] ioport: bar 4, base 0xd800, size: 0x100
[fglrx] Driver built-in PAT support is enabled successfully
[fglrx:firegl_init_module] *ERROR* firegl_stub_register failed
FATAL: Error inserting fglrx (/lib/modules/2.6.28N/misc/fglrx.ko): Operation not permitted

That's just swell. WTF is this firegl stuff?? Is some code which has nothing to do with my HW preventing correct driver operation??

Bridgman are you paying attention?

[bridgman]

That's just swell. WTF is this firegl stuff?? Is some code which has nothing to do with my HW preventing correct driver operation??

Bridgman are you paying attention?

Don't worry about the FireGl stuff. Fglrx *is* the FireGL driver.

Let me read through your previous posts before I reply about the rest.

[bridgman]

The packaging scripts for Debian include instructions for building the kernel module in a Debian-specific way.

I don't know if the instructions are correct and I don't know if you already know about them, but you didn't mention them in your summary of steps taken and you are having problems with the kernel module, so I thought I would post the link :

http://www.phorogit.com/index.php?p=...134080e9ecb5ea

I think this file shows up on your disk when you generate a Debian package, but not sure.

[nbi1]

The packaging scripts for Debian include instructions for building the kernel module in a Debian-specific way.

I don't know if the instructions are correct and I don't know if you already know about them, but you didn't mention them in your summary of steps taken and you are having problems with the kernel module, so I thought I would post the link :

http://www.phorogit.com/index.php?p=...134080e9ecb5ea

I think this file shows up on your disk when you generate a Debian package, but not sure.

That's close to a commonly accepted procedure. Posting #38 at this link:

http://www.computerbase.de/forum/showthread.php?p=5267351

seems to yield the most positive results. Note that this is based on the Debian Installation Guide's recommendations.

At this point I don't think the problem lies with the procedure. The ATI driver software appears to be fragile and sensitive to something in the runtime environment so that it succeeds only in the most pristine environments and only for a few select linux distros that ATI has deemed worthy of attention. Basically I regard this as a swindle on the part of ATI, but I am at fault for falling victim to it. Years ago I got burned by ATI but after doing some homework decided to give them a second chance. Well as the saying goes "fool me once shame on you, fool me twice....."

The time has come to ditch my HD 4850 and go nVidia which I should've to begin with. Having been driven to this debacle I will never buy another ATI product and will do my utmost to prevent others from making the same mistake.

[bridgman]

...only in the most pristine environments and only for a few select linux distros that ATI has deemed worthy of attention.

It's probably more appropriate to say "that the bulk of ATI's Linux customers have deemed worthy of attention", but I understand your point.

We have been increasing focus on consumer users over the last year, starting with Ubuntu (IIRC you already had the driverw working on Ubuntu ?) and the "fragility" you talk about, which IMO is more related to the installer being not quite sufficiently sophisticated yet, will disappear over time. Given the complaints I'm already hearing about the "relatively old" kernel and Xorg in Lenny I suspect the install issues will turn out to be pretty trivial.

That said, depending on how much you want to live on the leading edge of Linux and X development, you may eventually find that the open source drivers actually do a better job of making you happy than anyone's binary driver. Good luck with whatever direction you take.

[Kano]

Of course lenny is not too new for the driver

[bridgman]

It doesn't look like the major components should be too new anyways... so I imagine we just need some more tweaking of the packaging scripts. Not my area of expertise though.

[Kano]

Debian packageing was broken in too many drivers, I had to add workarounds / patches for em in order to install em. Therefore I switched over to use the Ubuntu packageing on Debian. This also prevents the driver from repository updates which use the Debian package name. Now the Ubuntu packageing relies on dkms. Informer dkms was optional, now you have to use it. Therefore I install dkms before and then use the Ubuntu packageing - no big trick behind that. If somebody does not like to use my script but wants to do that manually just fetch latest dkms deb from Ubuntu. m-a prepare could be used before to be sure that the kernel headers and some build tools are installed. I had to fix some issues with Ubuntu packageing too, but basically it works much better than the crappy Debian one. And dkms is nice to have too (which i also use for nvidia now).