Radeon x1600 + FC6, 32 & 64 bit: last driver that works at all is 8.32.5

[time2IPL]

Hi,

On my GA-M55plus-S3G system (Gigabyte), processor == AMD x2 4200, socket am2, two SATA/II drives (it did/does the same thing with one) and one IDE DVD R/W drive, 2Gb RAM (DDR2, dual-channel configuration (4 x 512)) (had same problem w/ 1 Gb), using either the stock Fedora kernels or my own build of them, I've encountered the following problem since v 8.32.5 of the drivers in both x86 mode and in x86_64 mode (I have Fedora Core 6 installed in a dual-boot configuration so I can run in either of the two modes):

after getting the driver to build: by backporting the syscall macros (syscall2, syscall3, etc.) and making whatever other changes turned out to be necessary: for 64-bit linux, for example, I had to copy fireglcontrolpanel to x710_64a/usr/X11R6/bin, from x690_64a; and, after making certain my sources contained linux/config.h and version-$(uname -r).h, adding them if they weren't there, and installing the requisite libstdc++ packages & qt-devel packages on my system; and then, after running the installer with --install, or with --buildpkg Fedora/FC6 - or, in the case of the patched but generally working 8.32.5 drivers I am currently running, "sh ./ati-installer.sh 8.32.5 --install" (or --buildpkg, etc.):

every driver I have tried since 8.32.5 - both on an existing install of Fedora on this system, and on a brand new one (I changed out the drives, did the install, etc.) - every driver since 8.32.5 has failed during the startup process. The last entry X.org makes while using any of them is, apparently, while it's trying to load fglrxdrm:

(II) LoadModule: "int10"
(II) Reloading /usr/lib64/xorg/modules/libint10.so
(II) fglrx(0): Primary V_BIOS segment is: 0xc000
(--) fglrx(0): Chipset: "Radeon X1600 Series" (Chipset = 0x71c2)
(--) fglrx(0): (PciSubVendor = 0x1002, PciSubDevice = 0x2342)
(--) fglrx(0): board vendor info: original ATI graphics adapter
(--) fglrx(0): Linear framebuffer (phys) at 0xe0000000
(--) fglrx(0): MMIO registers at 0xf3000000
(==) fglrx(0): ROM-BIOS at 0x000c0000
(II) Loading sub module "vbe"
(II) LoadModule: "vbe"
(II) Reloading /usr/lib64/xorg/modules/libvbe.so
(II) fglrx(0): VESA BIOS detected
(II) fglrx(0): VESA VBE Version 3.0
(II) fglrx(0): VESA VBE Total Mem: 16384 kB
(II) fglrx(0): VESA VBE OEM: ATI ATOMBIOS
(II) fglrx(0): VESA VBE OEM Software Rev: 9.12
(II) fglrx(0): VESA VBE OEM Vendor: (C) 1988-2005, ATI Technologies Inc.
(II) fglrx(0): VESA VBE OEM Product: RV530
(II) fglrx(0): VESA VBE OEM Product Rev: 01.00
(II) fglrx(0): ATI Video BIOS revision 9 or later detected
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: Open failed
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 9, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 9, (OK)
drmGetBusid returned ''
(II) Loading sub module "fglrxdrm"
(II) LoadModule: "fglrxdrm"
(II) Loading /usr/lib64/xorg/modules/linux/libfglrxdrm.so
(II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
compiled for 7.1.0, module version = 8.36.5
ABI class: X.Org Server Extension, version 0.3

I've tried using the same xorg.conf that's working for the 8.32.5 drivers, and I've tried varying it; the result is always exactly the same. I've tried different versions of the drivers since 8.32.5; the result has always been exactly the same (I can't swear that I've tried every single one that's been released, but I know I've tried several, including 8.36.5 and 8.35.5).

As I stated previously, the card is up and running, as of this moment, with the 8.32.5 drivers and kernel 2.6.20-1.2944. fglrxdrm reports that the drivers are operating using the correct OpenGL (ATI's, not Mesa), glxgears reports sppeds of appx 6,000 fps; with the vesa driver, it cannot attain more than about 900 fps. On exit, I get the following error message in x86_64 mode:

BUG: sleeping function called from invalid context at include/asm/semaphore.h:105
in_atomic():1, irqs_disabled():0

Call Trace:
[<ffffffff883075c4>] :fglrx:__ke_down_struct_sem+0x26/0x3c
[<ffffffff8830b8d0>] :fglrx:drm_getmagic+0x0/0x1a0
[<ffffffff8830b9db>] :fglrx:drm_getmagic+0x10b/0x1a0
[<ffffffff8830b8d0>] :fglrx:drm_getmagic+0x0/0x1a0
[<ffffffff88311383>] :fglrx:firegl_ioctl+0x1c3/0x230
[<ffffffff80241946>] do_ioctl+0x55/0x6b
[<ffffffff8022fd52>] vfs_ioctl+0x266/0x27f
[<ffffffff8024be35>] sys_ioctl+0x59/0x78
[<ffffffff8025c11e>] system_call+0x7e/0x83

[fglrx:firegl_rmmap] *ERROR* map 0xffff81007ed075d8 still in use (map_count=1)
[fglrx:firegl_free_buffer_queue] *ERROR* buffer queue 0xffff81007ed075c0 still mapped (user_handle = 0x00013000)
[fglrx:firegl_rmmap] *ERROR* map 0xffff81007ed07158 still in use (map_count=1)
[fglrx:firegl_free_buffer_queue] *ERROR* buffer queue 0xffff81007ed07140 still mapped (user_handle = 0x00012000)
[fglrx:firegl_rmmap] *ERROR* map 0xffff81007da484d8 still in use (map_count=1)
[fglrx:firegl_free_buffer_queue] *ERROR* buffer queue 0xffff81007da484c0 still mapped (user_handle = 0x00011000)
BUG: sleeping function called from invalid context at include/asm/semaphore.h:105
in_atomic():1, irqs_disabled():0

Call Trace:
[<ffffffff883075c4>] :fglrx:__ke_down_struct_sem+0x26/0x3c
[<ffffffff8830c048>] :fglrx:firegl_remove_all_drawables+0x38/0xf0
[<ffffffff88311a14>] :fglrx:firegl_takedown+0x34/0xc00
[<ffffffff88311174>] :fglrx:firegl_release+0x104/0x150
[<ffffffff802129f8>] __fput+0xbd/0x18a
[<ffffffff8021ab45>] remove_vma+0x49/0x70
[<ffffffff802396fb>] exit_mmap+0xf9/0x117
[<ffffffff8023b8ef>] mmput+0x3c/0x91
[<ffffffff80215651>] do_exit+0x257/0x842
[<ffffffff80248be2>] cpuset_exit+0x0/0x6b
[<ffffffff8025c11e>] system_call+0x7e/0x83

This seems to be fairly harmless; however, it's not giving me a good feeling as to using the 8.32.5 drivers going forward.

I have been testing the system as follows: boot up to runlevel 3 (set in inittab), and start X with "startx" (startx > /dev/null 2>&1 &). When I last ran X.org with drivers of any version other than 8.32.5 - I ran it during that session using "nice", with "top" running on a remote terminal, so I could see what was happening - the X server's CPU utilization shot up over 100%; irqbalance and hald-addon-storage were at the top of top's list also, with CPU utilizations of generally > 50%.

The monitor remained blank but would not go into power-saving mode, which it ordinarily will after 10-15 min.

System CPU utilization was at or near 100% on both cores during the entire time I allowed this experiment to continue (just over 20 minutes). At that point, I killed off the irqbalance process, as it was still between 40-60% userland CPU utilization. X stayed locked up. At that point, I attempted to kill X; it would not respond to kill -9. I was not able to cleanly shut down the system, either; while it acknowledged the reboot request with a "warning: the system is going down for a reboot..." it was not able to reboot after 20 minutes.

At that point, I disabled irqbalance (via chkconfig, and ntsysv, and by booting with "noirqbalance" (FWIW, I am also booting with "iommu=off" and "selinux=0") and tried the experiment again; about the only difference was that irqbalance did not appear in top's list of tasks.

tail /var/log/messages didn't show anything of note, nor did dmesg; there was no indication on either occasion of any activity on hald's part.

I've noticed that other people were having similar, but not identical, problems with various versions of the drivers, all apparently newer than 8.32.5; I hadn't seen anyone post success patching that revision of them .

My hope is that someone knows of a fundamental change that was made in the driver code after the 8.32.5 were released and that this isn't anything major to fix. If that doesn't prove to be the case, can anyone steer me towards where I need to go next with this problem? I had emailed the driver team @ ATI appx 1 1/2 - 2 months ago, never did get a reply.

The fact that the card works at all - with the correct OpenGL provider, in accelerated mode - tells me it's realistic to expect that it could work again, with newer drivers, as they are released; it's also an indication to me that there's a problem here with the drivers that's fundamental.

I would very much like to be able to continue using this card without having to live in fear that every kernel update is going to break something else. I'll gladly provide additional log info, config info, etc.; please just ask.

Thank you,

Larry (time2IPL)

[Michael]

What is the output of:

cat /var/log/Xorg.0.log | grep EE

and grep it for warnings (WW).

Did you compile the Fedora 2.6.20 kernel RPM yourself or used it from a repo?

[time2IPL]

Hi, Michael -

What is the output of:
cat /var/log/Xorg.0.log | grep EE


There aren't any; the only output from the above was "(WW) warning, (EE) error, (NI) not implemented, (??) unknown.". Occasionally, after I run "fireglcontrolpanel", I'll start getting "Error in "atiddxMiscUpdateFile" -4" errors; I hadn't gotten them since I added 'Option "Composite" "Disable"' to xorg.conf. But that's it...


and grep it for warnings (WW).


(WW) fglrx: No matching Device section for instance (BusID PCI:2:0:1) found
(WW) fglrx(0): Option "DynamicClocks" is not used
(WW) fglrx(0): Option "PowerState" is not used
(WW) fglrx(0): Option "VendorName" is not used
(WW) fglrx(0): Option "ModelName" is not used


Did you compile the Fedora 2.6.20 kernel RPM yourself or used it from a repo?

I've tried both. Generally speaking, I "roll my own"; there are a few features (forced preemption, no 4K stacks, NTFS support - nothing too radical) that I like / need that aren't in the stock kernel. But, in the interests of trying to get this to work, I tried (a) installing a stock kernel on this machine, and (b) actually trying a fresh install & starting with the stock kernel. Any pre-built kernels I've used have been from the Fedora repos.

The bad news is that, as with "noirqbalance" && pretty much everything else, I've tried to date, there was no discernible difference between any one and any other.

As far as the error goes (I copied the text of it again below), I set up a loop w/ grep & wc so I could see when & how frequently it was occurring; it seems to happen primarily at server startup and server shutdown, around 2 - 3 X at each (actual # varies w each "startx"). It also occurrs rather infrequently while I'm working in X, but, it doesn't correspond to any particular thing (not that I've been able to find yet, at least).

On those occasions where it's locked up while attempting to load (eg., with the 8.36.5 drivers) there's no EE output. No WW output either. It dies at fglrxdrm, right after drmOpenDevice reports success; the file's not complete as the machine requires a hard reset, but I've managed to flush what was there - 485 lines of it - to disk.

Like I said, at this point, it works; however, that error message has me pretty nervous, and I'm dreading the next Fedora kernel update...

Thanks,
Larry

Apr 22 23:48:28 jupiter kernel: BUG: sleeping function called from invalid context at include/asm/semaphore.h:105
Apr 22 23:48:28 jupiter kernel: in_atomic():1, irqs_disabled():0
Apr 22 23:48:28 jupiter kernel:
Apr 22 23:48:28 jupiter kernel: Call Trace:
Apr 22 23:48:28 jupiter kernel: [<ffffffff883055c4>] :fglrx:__ke_down_struct_sem+0x26/0x3c
Apr 22 23:48:28 jupiter kernel: [<ffffffff883098d0>] :fglrx:drm_getmagic+0x0/0x1a0
Apr 22 23:48:28 jupiter kernel: [<ffffffff883099db>] :fglrx:drm_getmagic+0x10b/0x1a0
Apr 22 23:48:28 jupiter kernel: [<ffffffff883098d0>] :fglrx:drm_getmagic+0x0/0x1a0
Apr 22 23:48:28 jupiter kernel: [<ffffffff8830f383>] :fglrx:firegl_ioctl+0x1c3/0x230
Apr 22 23:48:28 jupiter kernel: [<ffffffff80241946>] do_ioctl+0x55/0x6b
Apr 22 23:48:28 jupiter kernel: [<ffffffff8022fd52>] vfs_ioctl+0x266/0x27f
Apr 22 23:48:28 jupiter kernel: [<ffffffff8024be35>] sys_ioctl+0x59/0x78
Apr 22 23:48:28 jupiter kernel: [<ffffffff8025c11e>] system_call+0x7e/0x83
Apr 22 23:48:28 jupiter kernel:

[time2IPL]

This afternoon, I went back and did some more experimentation (after fixing the lines in /etc/X11/xorg.conf that were generating warnings in Xorg.0.log); specifically, I verified that 8.32.5 is the last version of the driver that will build && install on my machine. When I attempt to build and install 8.33.6, as before, I can get everything to the point where I can "modprobe fglrx"; according to dmesg, the driver loads with no issues / problems. However, after installing the RPMSs generated by --buildpkg Fedora/FC6, and correcting /etc/X11/xorg.conf after installing them (installing the RPMs causes the xorg.conf file to be altered), boom - screen stays blank, server can't be accessed via ssh: can't create new connections, existing connections are unusable - the machine is, for all intents and purposes, locked up, though I can still "ping" it.

The last thing that ever gets written to Xorg.0.log is:

(II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
compiled for 7.1.0, module version = 8.36.5
ABI class: X.Org Server Extension, version 0.3

The machine just sits there with a blank screen, power-saving mode never kicks in, and it's - well - time to IPL ...

One of the things I noticed is that fglrx.ko apparently ends up in two different locations, depending upon whether the installer is run with --install or --buildpkg: the RPMs want to put it in /lib/modules/$(uname -r)/extra/fglrx, while the installer (using --install) puts it in /lib/modules/$(uname -r)/kernel/drivers/char/drm. According to modinfo, nm, etc., they're the same: they contain the same symbols, etc. - but, they're always of two slightly different sizes. I can't, for the life of me, figure out how to modules, built from the same sources, with the same patches, etc., can end up being different sizes - but, then again, the blank screen bit doesn't make any sense to me either.

The main difference that's apparent between the two driver versions (8.33.6 and 8.32.5) is that /lib/modules/fglrx seems to begin to appear in 8.33.6; there seems to have been a fundamental shift towards doing - something - in a different way. As to what, or why - that's as much of a mystery to me as the blank screen and lockup.

The more I see of this, the more this is beginning to look like a fundamental problem with RedHat's (more precisely, the Fedora Project's) build of the X.org X server. Having tried to install the driver on Fedora 7 only furthers those suspicions.

Can anyone offer some insight into what's going on here? Or, even better, has anyone gotten an "ATI Technologies Inc RV530 [Radeon X1600]" w/512Mb RAM to work, on Fedora - FC6, preferably - using the proprietary drivers?

Again, thank you.

- Larry

[time2IPL]

At the risk of seeming in bad form, I'll once more add to my own posts...

After further examination - and "googling" - I've come to several conclusions. From what I've read on this board, I know there are people who know far more about the specifics of these cards and these drivers than I do; I would be most grateful if someone was to share the benefits of their experience(s) with me.

As I mentioned in my last post, the driver seems to have changed, architecturally, between the 8.32.5 and the 8.33.6 releases. Specifically, in the latter release, there's now a /lib/modules/fglrx directory, which contains what I'm guessing is the kernel driver.

The 8.32.5 driver also appears to have been a change from previous drivers; at least, from what I've read and seen, it addressed items and issues that were "open" - some for a significant time period - prior to its release.

I noticed in the "un-closed" portions of firegl_public.c that a transition to the work / task queue API was made; it appears that the first attempts at using it were made in the 8.33.6 drivers; the 8.34.8 drivers looked to be committed to its use. My question from before still stands: is enough of the driver source "open" that it's realistic to think that I'll be able to continue using the 8.32.5 code? And, if so, could someone please tell me where to look to eliminate the sleep-with-resource-held / busy-wait / etc. errors that I get at startup, shutdown, and occasionally while X is running.

Lastly, I'm assuming that I'm doing this correctly. The process should be simply:

sh ./ati-installer-name.run --buildpkg Fedora/FC6 (in my case)

followed by

rpm -e `rpm -qa | egrep "^ATI.*"`
rpm -e `rpm -qa | egrep "^kernel-module.*ATI.*"`

then

rpm -Uvh --force *.rpm

Followed by a system reboot; my system is configured to boot up to runlevel 3. At which point, I log in, and, at a shell prompt:

startx > /dev/null 2>&1 &

That's the procedure I've been following since I bought this card ("ATI Technologies Inc RV530 [Radeon X1600]") and first installed it. At that time, it installed on FC6 with nothing more than sh ./ati-installer-name --install, from what I can recall.

Just to be sure, I'm asking: there's no reason why the process I described above shouldn't work for versions of the driver after 8.32.5 as well (like 8.33.6) - correct? I appreciate everyone's time and effort, and I hope it works out that I'll be able to use this card; however, it's not looking good at this point, and I really can't justify spending any more time attempting to fix it, particularly when I'm more interested in doing so than the vendor is.

I felt this was worth one final attempt.

Thank you,

Larry

[wimex]

Hi,

I have a similar machine. My system has an Asrock motherboard, with an AMD 64 X2 3800+, and a Radeon x1600. I've tried everything:

1. Ubuntu/7.04 & Xorg 7.2 & Ati 8.36.5 -> crash (not blank screen, just crash), but can't remember to the error
2. openSUSE 10.2 & Xorg 7.2RC2 & Ati 8.36.5 -> blank screen
3. openSUSE 10.2 & Xorg 7.2 & Ati 8.36.5 -> blank screen
4. openSUSE 10.2 & Xorg 7.2 & Ati 8.32.5 & framebuffer on -> blank screen
5. openSUSE 10.2 & Xorg 7.2 & Ati 8.32.5 & framebuffer off -> works, but blank screen when i'm back from a text console

I've tried to turn off DRI (blank screen), turn off every module (blank screen again), change resolution/refresh rate (blank)...
I think, there is no way to make it working...

Here is my kernel log:
$ X&
Apr 25 19:01:28 home kernel: [fglrx] Internal AGP support requested, but kernel AGP support active.
Apr 25 19:01:28 home kernel: [fglrx] Have to use kernel AGP support to avoid conflicts.
Apr 25 19:01:28 home kernel: [fglrx] AGP detected, AgpState = 0x1f00421b (hardware caps of chipset)
Apr 25 19:01:28 home kernel: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
Apr 25 19:01:28 home kernel: agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
Apr 25 19:01:28 home kernel: agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
Apr 25 19:01:28 home kernel: [fglrx] AGP enabled, AgpCommand = 0x1f004312 (selected caps)
Apr 25 19:01:28 home kernel: [fglrx] total GART = 67108864
Apr 25 19:01:28 home kernel: [fglrx] free GART = 51113984
Apr 25 19:01:28 home kernel: [fglrx] max single GART = 51113984
Apr 25 19:01:28 home kernel: [fglrx] total LFB = 268435456
Apr 25 19:01:28 home kernel: [fglrx] free LFB = 250605568
Apr 25 19:01:28 home kernel: [fglrx] max single LFB = 250605568
Apr 25 19:01:28 home kernel: [fglrx] total Inv = 268435456
Apr 25 19:01:28 home kernel: [fglrx] free Inv = 268435456
Apr 25 19:01:28 home kernel: [fglrx] max single Inv = 268435456
Apr 25 19:01:28 home kernel: [fglrx] total TIM = 0
Gone back to the text console, because I wanted to start an xterm, so $ xterm -display :1
Ctrl+Alt+F7:
Apr 25 19:01:53 home kernel: X[4590] trap int3 rip:2b372808170f rsp:7fff85a89c80 error:0

[time2IPL]

Hi,

I have a similar machine. My system has an Asrock motherboard, with an AMD 64 X2 3800+, and a Radeon x1600. I've tried everything:


Just out of curiosity, is yours PCI-e or AGP?
I'm asking more out of curiosity than anything else; from what I've read and seen, that doesn't make a whole lot of difference.
What does seem to is the fact that this card (and, presumably, yours) is an "ATI Technologies Inc RV530 [Radeon X1600]". Here's my "educated guess" on what's going on here: the open source "radeon" driver won't work with your card or mine - or a few others that use a new graphics engine / GPU / etc. My point is that there's something in particular about our cards (actually, several cards in the same series) that precludes the radeon driver's functioning; other, older "radeon"s work with it. And, my card works with the ATI drivers up to - and including - v 8.32.5.

Some fundamental changes were made to the drivers between 8.32.5 and 8.32.6. One of the more obvious being that a lot of things were moved around; specifically, there's no /lib/modules/fglrx directory created by any driver prior to 8.33.6; if you look at the build scripts, you'll see others in fairly short order.

There are some obvious differences in the code between the two versions as well - together with some striking similarities. Below is a diff I ran against firegl_public.c from 8.32.5 && 8.33.6 - as far as I can tell, the difference between them is the addition of code to use "Kernel Abstraction Services", or KAS. I searched for info on KAS and found relatively little; it's apparently an ATI thing. I did, however, find an article on this very site (PHORONIX) that essentially reiterates my previous statement: "In fglrx 8.32.5 the firegl_public.c file was 4182 lines long where as today's release is now approximately 4495 lines -- with this additional code being largely attributed to adding Kernel Abstraction Services (KAS) with Symmetric Multi-Processing (SMP) support." The diff I ran against the two files showed no other apparent differences than that code.

Looking at the code, and what it does, got me wondering; it claims to add SMP support to the driver. I'm wondering if our x2's aren't confusing it. The code makes extensive use of spin locks; when my X server locks up, CPU utilization X 2 is 100%, but in system space, not user. There seems to be a fairly easy way to disable this added support; I'll try it after I post this and will report back...


1. Ubuntu/7.04 & Xorg 7.2 & Ati 8.36.5 -> crash (not blank screen, just crash), but can't remember to the error
2. openSUSE 10.2 & Xorg 7.2RC2 & Ati 8.36.5 -> blank screen
3. openSUSE 10.2 & Xorg 7.2 & Ati 8.36.5 -> blank screen
4. openSUSE 10.2 & Xorg 7.2 & Ati 8.32.5 & framebuffer on -> blank screen
5. openSUSE 10.2 & Xorg 7.2 & Ati 8.32.5 & framebuffer off -> works, but blank screen when i'm back from a text console


Well... at least you were able to get it to work - maybe not properly, but at least to some extent - to me, that begs the question "what's different between our kernels / systems / etc.?" I'm not familiar with SUSE; are you at all familiar with Fedora?

As far as I know, every major vendor takes the kernel.org sources, patches them, and releases them as their "official kernel"; somewhere in that patch set, or somewhere in the CONFIG_ options for the kernel, or both, may well lie the answer. Or, this is purely an X issue, and there's a difference between the way the two vendors build Xorg. Or, it might be neither; parts of the driver were, after all, compiled with an older version of gcc.

What version of gcc is SUSE using? gcc -v on my Fedora machine reports "Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)"

I started a build of the Fedora kernel with framebuffer support turned off ("CONFIG_FB is not set"). I'll try that, too, and will post the results here.


I've tried to turn off DRI (blank screen), turn off every module (blank screen again), change resolution/refresh rate (blank)...
I think, there is no way to make it working...

Here is my kernel log:
$ X&
Apr 25 19:01:28 home kernel: [fglrx] Internal AGP support requested, but kernel AGP support active.
Apr 25 19:01:28 home kernel: [fglrx] Have to use kernel AGP support to avoid conflicts.
Apr 25 19:01:28 home kernel: [fglrx] AGP detected, AgpState = 0x1f00421b (hardware caps of chipset)
Apr 25 19:01:28 home kernel: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
Apr 25 19:01:28 home kernel: agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
Apr 25 19:01:28 home kernel: agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
Apr 25 19:01:28 home kernel: [fglrx] AGP enabled, AgpCommand = 0x1f004312 (selected caps)
Apr 25 19:01:28 home kernel: [fglrx] total GART = 67108864
Apr 25 19:01:28 home kernel: [fglrx] free GART = 51113984
Apr 25 19:01:28 home kernel: [fglrx] max single GART = 51113984
Apr 25 19:01:28 home kernel: [fglrx] total LFB = 268435456
Apr 25 19:01:28 home kernel: [fglrx] free LFB = 250605568
Apr 25 19:01:28 home kernel: [fglrx] max single LFB = 250605568
Apr 25 19:01:28 home kernel: [fglrx] total Inv = 268435456
Apr 25 19:01:28 home kernel: [fglrx] free Inv = 268435456
Apr 25 19:01:28 home kernel: [fglrx] max single Inv = 268435456
Apr 25 19:01:28 home kernel: [fglrx] total TIM = 0
Gone back to the text console, because I wanted to start an xterm, so $ xterm -display :1
Ctrl+Alt+F7:
Apr 25 19:01:53 home kernel: X[4590] trap int3 rip:2b372808170f rsp:7fff85a89c80 error:0
[/QUOTE]

My dmesg contains some very different numbers; I'm not sure exactly what they mean, though. My system memory == 2Gb, and the X1600 has 512Mb on it. Maybe someone else can shed some light on this for us?

[fglrx] Maximum main memory to use for locked dma buffers: 1880 MBytes.
[fglrx] total GART = 532676608
[fglrx] free GART = 516685824
[fglrx] max single GART = 516685824
[fglrx] total LFB = 267911168
[fglrx] free LFB = 238039040
[fglrx] max single LFB = 238039040
[fglrx] total Inv = 268435456
[fglrx] free Inv = 268435456
[fglrx] max single Inv = 268435456
[fglrx] total TIM = 0

I'm also seeing in your notes that there is, in fact, a DRI issue or conflict of some sort... Interesting, as the last thing my X server logs before it dies is that it's loading libfglrxdrm.so.

I also can't help but wonder if the bugs I'm seeing now (dmesg) don't get worse under the next release of the driver; kernel-space CPU utilization gets pegged on both cores, some of the file system components (for ex. hald_addon_storage) go nuts... Of course, if you're sleeping holding a spinlock, mis-using a sempahore, or otherwise creating some sort of deadlock state within a device driver - well, that would do it.

If anyone from ATI happens to be listening in to this discussion: come on, guys; not enough could have possibly changed between 8.32.5 of the driver and 8.33.6 that it should be very difficult to pick out why a system would, potentially, go from "working" to "not working at all". Particularly given what was added (eg., KAS support).

wimex, I'll try those two things tomorrow and post the results here; who knows, maybe we'll get lucky. I'm not betting on it though; I think this is a problem that ATI is fully aware of and choosing not to acknowledge or address, at least, not yet. Sorry, guys, but too many things point in that direction.

- Larry

[wimex]

Just out of curiosity, is yours PCI-e or AGP?
I'm asking more out of curiosity than anything else; from what I've read and seen, that doesn't make a whole lot of difference.
What does seem to is the fact that this card (and, presumably, yours) is an "ATI Technologies Inc RV530 [Radeon X1600]". Here's my "educated guess" on what's going on here: the open source "radeon" driver won't work with your card or mine - or a few others that use a new graphics engine / GPU / etc. My point is that there's something in particular about our cards (actually, several cards in the same series) that precludes the radeon driver's functioning; other, older "radeon"s work with it. And, my card works with the ATI drivers up to - and including - v 8.32.5.

Its an AGP version... (This: Sapphire Radeon X1600 PRO 512M DDR2 AGP, if it helps)


Well... at least you were able to get it to work - maybe not properly, but at least to some extent - to me, that begs the question "what's different between our kernels / systems / etc.?" I'm not familiar with SUSE; are you at all familiar with Fedora?

No... I'm just using SUSE because i've read, that it supports Xgl well... also that's why I've tried Ubuntu first.


As far as I know, every major vendor takes the kernel.org sources, patches them, and releases them as their "official kernel"; somewhere in that patch set, or somewhere in the CONFIG_ options for the kernel, or both, may well lie the answer. Or, this is purely an X issue, and there's a difference between the way the two vendors build Xorg. Or, it might be neither; parts of the driver were, after all, compiled with an older version of gcc.

I think, this is my kernel config (I'm not sure, i've found it in /usr/src/linux/.config.running, i've never used suse before)
http://www.rogepost.com/n/4098187088


What version of gcc is SUSE using? gcc -v on my Fedora machine reports "Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)"

$ gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix=-4.1 --enable-version-specific-runtime-libs --without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)


My dmesg contains some very different numbers; I'm not sure exactly what they mean, though. My system memory == 2Gb, and the X1600 has 512Mb on it. Maybe someone else can shed some light on this for us?

I have 1Gb system memory, and the x1600 has 512Mb. My PC uses only 880Mb for DMA buffers... but don't think it's important


[fglrx] Maximum main memory to use for locked dma buffers: 1880 MBytes.
[fglrx] total GART = 532676608
[fglrx] free GART = 516685824
[fglrx] max single GART = 516685824
[fglrx] total LFB = 267911168
[fglrx] free LFB = 238039040
[fglrx] max single LFB = 238039040
[fglrx] total Inv = 268435456
[fglrx] free Inv = 268435456
[fglrx] max single Inv = 268435456
[fglrx] total TIM = 0


I've googled for them:

GART: Program that checks the motherboard chipset and determines which GART driver bundle to install on ATI video cards. I can remember, that in windows, there were an option called SmartGART. It could reset the card if there were errors.
I couldn't find anything about the others.


If anyone from ATI happens to be listening in to this discussion: come on, guys; not enough could have possibly changed between 8.32.5 of the driver and 8.33.6 that it should be very difficult to pick out why a system would, potentially, go from "working" to "not working at all". Particularly given what was added (eg., KAS support).


I don't think they are listening... so keep trying! (=

[time2IPL]

http://www.phoronix.net/forums/newreply.php?do=newreply&p=7522

Hey; sorry it took me a day to get this done - I covered a lot of ground though, and may actually have something workable here. Anyone who knows differently, please jump in and correct me; in the process of testing everything out, I realized that the bulk of the driver relesaes from 8.32.5 on (excluding the newest ones, which I'm not 100% on yet) are simply bug fix releases, and if your card isn't impacted by a particular bug, then you might as well be using 8.32.5.

I built a kernel with CONFIG_FB turned off; can't say as I'm noticing any real difference as a result. Everything works though, and since I don't use VGA console modes anyway - I personally think they suck; I've fought with several systems now that, for various reasons, wouldn't boot up because of "issues" with framebuffer consoles - redhat has a thing that hides system messages from us poor dumb users called "rhgb", which uses this mode; I usually disable it. I know Mandriva has similar, am pretty sure SUSE still does.

What I don't understand is why that would affect X. Unless it's an indirect or consequential sort of interaction / thing. The more I think about it ...

So, I have 1280x1024x24. I've managed to get Google Earth working. glxgears is showing good numbers. Basically, life is good - again - like it was back when the 2.6.18 kernel was current, before all this crap started. As far as I can tell the main diff between our cards is mine's not made by Sapphire. I don't know if that affects the chipset that it uses or not.

Its an AGP version... (This: Sapphire Radeon X1600 PRO 512M DDR2 AGP, if it helps)


No... I'm just using SUSE because i've read, that it supports Xgl well... also that's why I've tried Ubuntu first.


I think, this is my kernel config (I'm not sure, i've found it in /usr/src/linux/.config.running, i've never used suse before)
http://www.rogepost.com/n/4098187088


Yeah, that's it... Nothing horrible caught my eye about it, though there were a few things that were a little unusual. The timer frequency was 250hz, as opposed to the usual 1000hz for a destkop; also, forced preemption wasn't on. It appeared to be building the kernel with DRI - but, then, virtually every stock kernel is built with DRI (with the older ATI drivers you had to rebuild the kernel w/ AGP as a module && DRI in the kernel off. Leaving out radeon support alltogether was usually recommended too though I don't remember if that was an absolute must).

There was one other thing that caught my attention; SUSE is allowing you to pick a memory model that's not discontiguous and not sparse. I have no idea what the purpose of that memory model is; in 64-bit mode, as far as I knew, there were pretty much two choices (sparse or not sparse). If you get the chance, would you look through their Kconfig files and their patches and see what the heck that is?

From what I can gather, SUSE and RedHat are relatively similar - they're both udev based, both RPM based, both do a full System V Init - most of the system files seem to be in the same places - unfortunately, the last time I used SUSE at all was in appx. 1999; I remember them being relatively similar to RH at the time, and not disliking their distro, just not feeling compelled to move away from RedHat at that time.


$ gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix=-4.1 --enable-version-specific-runtime-libs --without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)


That looks ok; at least, I don't see anything there that looks way out there. I'm still tempted to drop down to an older rev of gcc just to see if it makes any difference at all...

It made sense to me that you would need the compat libs for the older drivers; what are they doing new development on, though, I wonder?


I have 1Gb system memory, and the x1600 has 512Mb. My PC uses only 880Mb for DMA buffers... but don't think it's important

That's normal; by default, you're not gonna get the full 1Gb unless you patch your kernel so that you do - at which point you generally end up screwing up other things.


I've googled for them:

GART: Program that checks the motherboard chipset and determines which GART driver bundle to install on ATI video cards. I can remember, that in windows, there were an option called SmartGART. It could reset the card if there were errors.
I couldn't find anything about the others.



I don't think they are listening... so keep trying! (=

The abbreviations make sense to me, it's the numbers beside them that don't. Your GART is the interface between your motherboard and your AGP graphics card; it's more of an API than it is a pure hardware interface. It handles the memory mapping / address translation between the video memory and the system memory.

Don't sweat that one; at least for the time being we've gotten all there is to get out of those #s.

Like I said, at this point, I have the 8.32.5 drivers - and have written down step by step instructions that have given me reproducible results on two different machines. I would be glad to toss them up on a web site. Can't promise they'll work though...

At least part of the problem between versions is with libGL.so - when I install 8.33.6, libGL.so.1.2 gets trashed (0 bytes). There were some other oddities with some of the symbolic links, too. I had the X server running without DRI support; the problem seemed to be conflicting modules (libdrm.so from the Xorg server seemed to be colliding with libfglrdrm). Particularly with the new "modular X server" I have no idea how to tell it to use one and not the other. Can anyone offer any advice w respect to this?

I also noticed that the libGL.so.1.2 libraries in the 8.32.5 and 8.33.6 were the same. Which makes the fact that, when I installed the RPMs the 8.33.6 installer built on my system, that they were different from the ones that the 8.32.5 installer built, make absolutely no sense at all. At that point I saw several postings in various forums where other users had stated they had experienced similar problems, including one with a link to a libGL.so.1.2 from heaven-knows-where to go download - which I obviously didn't do.

There were a few installer issues in the 8.32.5 installer (with X.org 7.10 && kernel 2.6.20) that were easy fixes; can anyone confirm that the 8.36.6 installer has problems?

At this point, I feel like I'm actually getting somewhere with this. It's a bit ridiculous to have to resort to using strace && xtrace, other people's notes & observations, etc. to install a closed source driver though. I'll say this much; unless that driver is opened up, I will not be buying any more ATI product. Not when there are open alternatives. I'm simply not willing to pull my hair out debugging something when the vendor refuses to do their part.

Good luck, wimex; let me know if you want me to post that.

[time2IPL]

Hi, Michael -

I think I have a handle on the proprietary ATI drivers at this point: I know where the various pieces of the drivers are supposed to be for the 8.32.5 driver. While the overall structure of the driver doesn't seem to have changed much from version to version, certain aspects of the driver do change. For example, 8.32.5 puts libGL.so.1.2 in /usr/lib64/fglrx and /usr/lib/fglrx; later versions (for example, 8.34.8) put those libs in /usr/lib64/xorg and /usr/lib/xorg. And, 8.34.8 also creates a script in /etc/profiles.d (ati-fglrx.sh) that sets LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH (see post_drv.sh in the 8.34.8 driver's fglrx_install dir). I also noticed that the libGL.so.1.2 provided in drivers 8.32.5, 8.33.6, 8.34.8, 8.35.5 - and even 8.36.5 - are all exactly the same size - and, from what I can tell (from nm -s and other tools), their contents are the same, too. And, I know those libraries work / are usable: for example, to get Google Earth up and running, I had to copy the libGL.so.1.2 that was included in version 8.25.18 of the driver into the directory in which Google Earth is installed (I think the default is /opt/google-earth).

Unfortunately, the installers for versions 8.33.6, 8.34.8, etc. of the driver don't put everything where it needs to go. Or, they cause other problems - one of them left me with a libGL.so.1.2 that was zero bytes in size; others either didn't make certain sym links, or made some rather interesting ones.
All of that being said, here's my problem / question: 8.32.5 (and drivers before it) being the exception, I cannot get X up and running in ia32 mode or x86_64 mode. I did have to make some adjustments to the scripts in the 8.32.5 driver package and apply some patches to firegl_public.c, but, having done that - and having archived it - I've removed and re-installed the driver, installed the driver on other systems, etc.; it's worked every single time. The procedure I've used to install the driver is:

# start with no left-over RPMs
rm *.rpm
# extract the fglrx-install dir
sh ./ati-driver-installer-8.32.5-x86.x86_64.run --extract
cd fglrx-install
# define syscall2, syscall3, etc. so firegl_public.c compiles
patch -p0 < ../backport__syscall-N.patch
# work-around for "fireglcontrolpanel ! found == rpmbuild failure" issue
mkdir -p ./x710_64a/usr/X11R6/bin
cp ./x700_64a/usr/X11R6/bin/fireglcontrolpanel \
./x710_64a/usr/X11R6/bin/fireglcontrolpanel
# build the packages
sh ./ati-installer.sh 8.32.5 --buildpkg Fedora/FC6
cd ..
# install the packages
rpm -e `rpm -qa | egrep "^ATI-.*$"`
rpm -e `rpm -qa | egrep "^kernel-module-ATI-fglrx.*"
rpm -Uvh --force `ls *.rpm`

I had to do a little prep work prior to this: the patch I'm using in the above is a patch I wrote that defines the macros syscall2, syscall3, etc. - macros that disappeared from the kernel source somewhere between versions 2.6.18 and 2.6.20 of the kernel, and saved in "backport__syscall-N.patch". And, there were a few steps I needed to take to prepare the kernel sources for the build; not doing them resulted in a failed build. They are:

# Make sure linux/config.h is present, even if it's just an empty file
[ -e /usr/src/kernels/$(uname -r)-$(uname -m)/include/linux/config.h ] || \
touch /usr/src/kernels/$(uname -r)-$(uname -m)/include/linux/config.h

# Note that one of these two directories - probably the second - is a symlink
# to the other, which means that only one of these statements should actually
# be necessary.
[ -e /lib/modules/$(uname -r)/build/include/linux/config.h ] || \
touch /lib/modules/$(uname -r)/build/include/linux/config.h

# Older driver code - not sure of cutoff version - looks for a file named:
# linux/version-$(uname -r)
# and will case the build to fail if that file doesn't exist.
[ -e /lib/modules/$(uname -r)/build/include/linux/version-$(uname -r).h ] || \
ln -s /lib/modules/$(uname -r)/build/include/linux/version.h \
/lib/modules/$(uname -r)/build/include/linux/version-$(uname -r).h

As I stated earlier, this procedure works every time I've tried it, and these drivers work nicely. There are a few gotcha's with them, and with every kernel update, I seem to be encountering more and more problems with them, however, so, I would like to get a more recent version of the drivers working.
And that leads me to my question: what I cannot figure out - and I'm hoping someone can help me with: Michael L., in your blog, you alluded to having to do something similar in order to get your system up and running - is, why won't this procedure work with anything newer than 8.32.5? Every time I install a driver package that's newer than 8.32.5 - whether it's on this machine, or on a different one - fresh install or no - the X server starts, the screen goes blank, and - nothing. If I boot up a debugging kernel && run X under nice, the system won't lock up completely, and I can see from, for example, top, that both cores are at very low utilization / user, but at 100% utilization / system. Screen goes blank, stays blank; last thing written to Xorg.0.log is regarding the X server's attempt to load fglrxdrm.

Is there something fundamentally different about the build procedure? Or, if it's a question of files being in the wrong places, etc., could someone please post a listing of what goes where? For example, "ls -l /usr/lib64/fglrx", and "ls -l /usr/lib/fglrx", etc.?
I have been able to get the system to the point where, with a more recent driver, if I mv libdrm.so out of the way, X will start up - albeit without DRI support, running very slowly, etc.; I tried this as (when using drivers > 8.32.5) my Xorg.0.log file always ended with:

(II) Loading sub module "fglrxdrm"
(II) LoadModule: "fglrxdrm"
(II) Loading /usr/lib64/xorg/modules/linux/libfglrxdrm.so
(II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
compiled for 7.1.0, module version = 8.36.5
ABI class: X.Org Server Extension, version 0.3
<note: file ends right here.>

In some of the myriad of postings w/respect to "I can't get my ATI drivers to work", I saw some conjecture as to there being a conflict between libdrm and fglrxdrm. I couldn't figure out any other way to keep libdrm from loading other than to move it out of the way.
I tried "ln -s <path-to-libfglxdrm> <libdrm>"; that didn't work, either - the X server started without DRI, error was regarding a missing symbol / missing functionality resulting in an inablility of the X server to bring up the DRI subsystem.

I also noticed that the scripts in fglrx-install for the drivers going back as far as 8.32.5 make reference to dkms. Anyone know what that's about (not "what's dkms", but "why are they either using it or attempting to accomodate it or ??").

On the occasions that X crashed when loading, there were no errors or warnings present in Xorg.0.log; ordinarily, there aren't any, either.

[time2IPL]

Could it have anything to do with the fact that this is a PCI-e card is in a system with onboard AGP graphics that are disabled in the machine's BIOS? I noticed that the logs, aticonfig, etc. always refer to my monitor as "crt2" although I only have one monitor hooked up to the machine. The drivers are detecting two DACs, though:

(II) Loading sub module "fglrxdrm"
(II) LoadModule: "fglrxdrm"
(II) Loading /usr/lib64/xorg/modules/linux/libfglrxdrm.so
(II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
compiled for 7.1.0, module version = 8.32.5
ABI class: X.Org Server Extension, version 0.3
(--) fglrx(0): VideoRAM: 262144 kByte, Type: DDR2
(II) fglrx(0): PCIE card detected
(II) fglrx(0): board/chipset is supported by this driver (original ATI board)
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Reloading /usr/lib64/xorg/modules/libddc.so
(II) fglrx(0): Connected Display1: CRT on secondary DAC [crt2]

and

(II) fglrx(0): EDID (in hex):
(II) fglrx(0): 00ffffffffffff0010ac0ba04d364639
(II) fglrx(0): 0e0f010368221b78eecaf6a357479e23
(II) fglrx(0): 114f54a54b00714f8180010101010101
(II) fglrx(0): 010101010101302a009851002a403070
(II) fglrx(0): 1300520e1100001e000000ff00553439
(II) fglrx(0): 33313533563946364d0a000000fc0044
(II) fglrx(0): 454c4c204531373346500a20000000fd
(II) fglrx(0): 00384b1f500e000a20202020202000bc
(II) fglrx(0): End of Display1 EDID data --------------------
(II) fglrx(0): Primary Controller - CRT on secondary DAC
(II) fglrx(0): Internal Desktop Setting: 0x00000001
(II) fglrx(0): POWERplay version 3. 1 power state available:
(II) fglrx(0): 1. 500/405MHz @ 0Hz [enable load balancing]


Also, according to the driver, this card has only one power state; that's fine - can anyone tell me what it's talking about though (in the above line: 500/405MHz @ 0Hz [enable load balancing])?
With the older drivers, you used to have to build a kernel with no DRI support; as this kernel has it, and the 8.32.5 drivers work, that wouldn't seem to be it. Or am I missing something there, too?

If someone - particularly someone using Fedora 6, x86_64 - who's got a driver more recent than 8.32.5 running, could post the contents of their various directories so I can see what symlinks need to go where, etc., I'll hopefully be able to get this to the next level. Unfortunately (with respect to drivers - the card itself works nicely) this card is an "RV530 [Radeon X1600]", which means the radeon driver won't work. At this point, having used ldd, trace, and just about every other tool I can think of, I'm at my wits end here.

Supplemental note: as I was about to post this, I had a customer's machine come in with a Radeon 9800; the radeon driver worked fine with this card; however, 3-D apps were horrendously slow, so I installed the proprietary drivers. I ran into the same problem as I did with my machine: the 8.32.5 drivers worked, and anything newer -> blank screen, off the wall CPU utilization (system), server died at same place as mine according to Xorg.0.log.
I'm attaching my xorg.conf here; is there something I'm missing? Like I said, it works fine with the 8.32.5 drivers, no errors or warnings in Xorg.0.log, except for:

(WW) fglrx: No matching Device section for instance (BusID PCI:2:0:1) found
(WW) fglrx(0): Option "VendorName" is not used
(WW) fglrx(0): Option "ModelName" is not used

I've taken out the VendorName and ModelName options - which aticonfig put there in the first place - no difference. I only have one monitor hooked up to the system, which is why - I'm relatively certain, anyway - I'm getting the second warning.
Or do I need to have two device, display, screen etc. sections in xorg.conf always anyway (I did try that; it didn't seem to make a difference either - but, I could have had something misconfigured).
If there's anyone who has the ATI drivers working, on Fedora Core 6, driver version > 8.32.5, if you would please post an ls -lR of /usr/lib64, etc. and tell me how you got the thing working, I would greatly appreciate it.
Here's the dmesg output from my system; I have no idea what the numbers mean & can't find a reference that explains them either; I did notice that, on posts from others using FC6, their "TIM" was "0", too.

[fglrx] Max. locked buffer memory: 3770 MBytes
[fglrx] Maximum main memory to use for locked dma buffers: 3770 MBytes.
[fglrx] total GART = 532676608
[fglrx] free GART = 516685824
[fglrx] max single GART = 516685824
[fglrx] total LFB = 267911168
[fglrx] free LFB = 260567040
[fglrx] max single LFB = 260567040
[fglrx] total Inv = 268435456
[fglrx] free Inv = 268435456
[fglrx] max single Inv = 268435456
[fglrx] total TIM = 0


Here's the xorg.conf I've been using:

# Xorg configuration created by system-config-display

Section "ServerLayout"
Identifier "single head configuration"
Screen 0 "aticonfig-Screen[0]" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
FontPath "unix/:7100"
EndSection

Section "Module"
Load "i2c"
Load "bitmap"
Load "dbe"
Load "fbdevhw"
Load "ddc"
Load "dri"
Load "extmod"
Load "freetype"
Load "glx"
Load "int10"
Load "vbe"
Load "fglrx"
EndSection

Section "ServerFlags"
Option "AIGLX" "off"
EndSection

Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "yes"
EndSection

Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection

Section "Monitor"
Identifier "aticonfig-Monitor[0]"
DisplaySize 340 270
HorizSync 31.0 - 80.0
VertRefresh 56.0 - 75.0
Option "VendorName" "ATI Proprietary Driver"
Option "ModelName" "Generic Autodetecting Monitor"
Option "DPMS" "true"
EndSection

Section "Device"
Identifier "aticonfig-Device[0]"
Driver "fglrx"
BoardName "Radeon X1600 PRO 512MB"
Option "no_accel" "no"
Option "no_dri" "no"
Option "mtrr" "on"
Option "DesktopSetup" "single"
Option "ScreenOverlap" "0"
Option "Capabilities" "0x20008000"
Option "CapabilitiesEx" "0x00000000"
Option "VideoOverlay" "on"
Option "OpenGLOverlay" "off"
Option "CenterMode" "off"
Option "PseudoColorVisuals" "off"
Option "Stereo" "off"
Option "StereoSyncEnable" "1"
Option "FSAAEnable" "on"
Option "FSAAScale" "4"
Option "FSAADisableGamma" "off"
Option "FSAACustomizeMSPos" "no"
Option "FSAAMSPosX0" "0.000000"
Option "FSAAMSPosY0" "0.000000"
Option "FSAAMSPosX1" "0.000000"
Option "FSAAMSPosY1" "0.000000"
Option "FSAAMSPosX2" "0.000000"
Option "FSAAMSPosY2" "0.000000"
Option "FSAAMSPosX3" "0.000000"
Option "FSAAMSPosY3" "0.000000"
Option "FSAAMSPosX4" "0.000000"
Option "FSAAMSPosY4" "0.000000"
Option "FSAAMSPosX5" "0.000000"
Option "FSAAMSPosY5" "0.000000"
Option "BlockSignalsOnLock" "on"
Option "UseInternalAGPGART" "no"
Option "ForceGenericCPU" "off"
Option "MaxGARTSize" "512"
Option "UseFastTLS" "0"
Option "KernelModuleParm" "agplock=0;locked-userpages=0;maxlockedmem=3770"
Option "DRM_nbufs" "100"
Option "DRM_bufsize" "65536"
Option "EnablePrivateBackZ" "yes"
Option "TexturedVideoSync" "off"
BusID "2:0:0"
EndSection

Section "Screen"
Identifier "aticonfig-Screen[0]"
Device "aticonfig-Device[0]"
Monitor "aticonfig-Monitor[0]"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1280x1024" "1152x864" "1024x768" "800x600"
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 16
Modes "1280x1024" "1152x864" "1024x768" "800x600"
EndSubSection
EndSection

Section "DRI"
Group 0
Mode 0666
EndSection

Section "Extensions"
Option "Composite" "Disable"
Option "XVideo" "Enable"
EndSection


At this point, if I could even just hear from someone using FC6 who's got these drivers working for an RV530 / X1600 card, that would be terrific.

Thanks for your help,

Larry

[Michael]

Hi, Michael -

I think I have a handle on the proprietary ATI drivers at this point: I know where the various pieces of the drivers are supposed to be for the 8.32.5 driver. While the overall structure of the driver doesn't seem to have changed much from version to version, certain aspects of the driver do change. For example, 8.32.5 puts libGL.so.1.2 in /usr/lib64/fglrx and /usr/lib/fglrx; later versions (for example, 8.34.8) put those libs in /usr/lib64/xorg and /usr/lib/xorg. And, 8.34.8 also creates a script in /etc/profiles.d (ati-fglrx.sh) that sets LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH (see post_drv.sh in the 8.34.8 driver's fglrx_install dir). I also noticed that the libGL.so.1.2 provided in drivers 8.32.5, 8.33.6, 8.34.8, 8.35.5 - and even 8.36.5 - are all exactly the same size - and, from what I can tell (from nm -s and other tools), their contents are the same, too. And, I know those libraries work / are usable: for example, to get Google Earth up and running, I had to copy the libGL.so.1.2 that was included in version 8.25.18 of the driver into the directory in which Google Earth is installed (I think the default is /opt/google-earth).

Unfortunately, the installers for versions 8.33.6, 8.34.8, etc. of the driver don't put everything where it needs to go. Or, they cause other problems - one of them left me with a libGL.so.1.2 that was zero bytes in size; others either didn't make certain sym links, or made some rather interesting ones.
All of that being said, here's my problem / question: 8.32.5 (and drivers before it) being the exception, I cannot get X up and running in ia32 mode or x86_64 mode. I did have to make some adjustments to the scripts in the 8.32.5 driver package and apply some patches to firegl_public.c, but, having done that - and having archived it - I've removed and re-installed the driver, installed the driver on other systems, etc.; it's worked every single time. The procedure I've used to install the driver is:

# start with no left-over RPMs
rm *.rpm
# extract the fglrx-install dir
sh ./ati-driver-installer-8.32.5-x86.x86_64.run --extract
cd fglrx-install
# define syscall2, syscall3, etc. so firegl_public.c compiles
patch -p0 < ../backport__syscall-N.patch
# work-around for "fireglcontrolpanel ! found == rpmbuild failure" issue
mkdir -p ./x710_64a/usr/X11R6/bin
cp ./x700_64a/usr/X11R6/bin/fireglcontrolpanel \
./x710_64a/usr/X11R6/bin/fireglcontrolpanel
# build the packages
sh ./ati-installer.sh 8.32.5 --buildpkg Fedora/FC6
cd ..
# install the packages
rpm -e `rpm -qa | egrep "^ATI-.*$"`
rpm -e `rpm -qa | egrep "^kernel-module-ATI-fglrx.*"
rpm -Uvh --force `ls *.rpm`
I had to do a little prep work prior to this: the patch I'm using in the above is a patch I wrote that defines the macros syscall2, syscall3, etc. - macros that disappeared from the kernel source somewhere between versions 2.6.18 and 2.6.20 of the kernel, and saved in "backport__syscall-N.patch". And, there were a few steps I needed to take to prepare the kernel sources for the build; not doing them resulted in a failed build. They are:

# Make sure linux/config.h is present, even if it's just an empty file
[ -e /usr/src/kernels/$(uname -r)-$(uname -m)/include/linux/config.h ] || \
touch /usr/src/kernels/$(uname -r)-$(uname -m)/include/linux/config.h

# Note that one of these two directories - probably the second - is a symlink
# to the other, which means that only one of these statements should actually
# be necessary.
[ -e /lib/modules/$(uname -r)/build/include/linux/config.h ] || \
touch /lib/modules/$(uname -r)/build/include/linux/config.h

# Older driver code - not sure of cutoff version - looks for a file named:
# linux/version-$(uname -r)
# and will case the build to fail if that file doesn't exist.
[ -e /lib/modules/$(uname -r)/build/include/linux/version-$(uname -r).h ] || \
ln -s /lib/modules/$(uname -r)/build/include/linux/version.h \
/lib/modules/$(uname -r)/build/include/linux/version-$(uname -r).h
As I stated earlier, this procedure works every time I've tried it, and these drivers work nicely. There are a few gotcha's with them, and with every kernel update, I seem to be encountering more and more problems with them, however, so, I would like to get a more recent version of the drivers working.
And that leads me to my question: what I cannot figure out - and I'm hoping someone can help me with: Michael L., in your blog, you alluded to having to do something similar in order to get your system up and running - is, why won't this procedure work with anything newer than 8.32.5? Every time I install a driver package that's newer than 8.32.5 - whether it's on this machine, or on a different one - fresh install or no - the X server starts, the screen goes blank, and - nothing. If I boot up a debugging kernel && run X under nice, the system won't lock up completely, and I can see from, for example, top, that both cores are at very low utilization / user, but at 100% utilization / system. Screen goes blank, stays blank; last thing written to Xorg.0.log is regarding the X server's attempt to load fglrxdrm.

Is there something fundamentally different about the build procedure? Or, if it's a question of files being in the wrong places, etc., could someone please post a listing of what goes where? For example, "ls -l /usr/lib64/fglrx", and "ls -l /usr/lib/fglrx", etc.?
I have been able to get the system to the point where, with a more recent driver, if I mv libdrm.so out of the way, X will start up - albeit without DRI support, running very slowly, etc.; I tried this as (when using drivers > 8.32.5) my Xorg.0.log file always ended with:

(II) Loading sub module "fglrxdrm"
(II) LoadModule: "fglrxdrm"
(II) Loading /usr/lib64/xorg/modules/linux/libfglrxdrm.so
(II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
compiled for 7.1.0, module version = 8.36.5
ABI class: X.Org Server Extension, version 0.3
<note: file ends right here.>
In some of the myriad of postings w/respect to "I can't get my ATI drivers to work", I saw some conjecture as to there being a conflict between libdrm and fglrxdrm. I couldn't figure out any other way to keep libdrm from loading other than to move it out of the way.
I tried "ln -s <path-to-libfglxdrm> <libdrm>"; that didn't work, either - the X server started without DRI, error was regarding a missing symbol / missing functionality resulting in an inablility of the X server to bring up the DRI subsystem.

I also noticed that the scripts in fglrx-install for the drivers going back as far as 8.32.5 make reference to dkms. Anyone know what that's about (not "what's dkms", but "why are they either using it or attempting to accomodate it or ??").

On the occasions that X crashed when loading, there were no errors or warnings present in Xorg.0.log; ordinarily, there aren't any, either.

I am the maintainer of the Fedora packaging scripts, and the locations of the different files haven't been changed in recent releases... The only changes have really been about 2.6.20 support and then changes when adding amdcccle, etc.... Outside of that, the standard package locations have not changed.

I am out of town right now but once back I'll answer your question more thoroughly.

[time2IPL]

I am the maintainer of the Fedora packaging scripts, and the locations of the different files haven't been changed in recent releases... The only changes have really been about 2.6.20 support and then changes when adding amdcccle, etc.... Outside of that, the standard package locations have not changed.

I am out of town right now but once back I'll answer your question more thoroughly.

Thanks, Michael; I really appreciate it. I've been over this a number of times now and it's just not making any sense. Rather than pull what little hair I have left out, ...

Thanks again.

- Larry

[TheOuch]

Any update on this? Specifically, I'm looking for a patch to allow the fglx drivers to build on 2.6.21 (FC7)

[Michael]

Any update on this? Specifically, I'm looking for a patch to allow the fglx drivers to build on 2.6.21 (FC7)

You will need the 8.39 driver once released to support Fedora 7.

[karthikrg]

i was having EXACTLY THE problems with my X1800Xt (MSI) 512 MB on a GA-K8N51GMF9 motherboard (Nforce 430). I thought problems had got resolved with 8.38.7 but later only i found out that i was using my old xorg.conf with DRI disabled. Wen I enable DRI, same problem as urs.. Any help from my side and ill be glad to provide...

As of now even i am running 8.32.5 on 2.6.20 after using the fglrx-patch and compiling the kernel module manually..

Did you try changing AGP aperture size in BIOS? Its helping some people.. i dont seem to have such an option in my BIOS though

Regards, (Hoping to see an early solution to this)
karthik

[TheOuch]

You will need the 8.39 driver once released to support Fedora 7.


I thought newer drivers didn't support older cards? I have the ATI M24GL [Mobility FireGL V3200]

[Michael]

I thought newer drivers didn't support older cards? I have the ATI M24GL [Mobility FireGL V3200]

The newest drivers do not support the R200 series (up to the Radeon 9250). The Mobility FireGL V3200 is similar to the RV380 and should be supported by the current fglrx drivers.

[karthikrg]

all thats fine michael.. but hav u talked 2 ati ppl about time2ipl's and my problem? Many are having this problem and no solution in sight..

[Michael]

all thats fine michael.. but hav u talked 2 ati ppl about time2ipl's and my problem? Many are having this problem and no solution in sight..

They had no comment or solution on it.

[karthikrg]

But isnt it absurd that so many users are being left in the lurch unable to even start the GUI when ATI is looking for fancy stuff like AIGLX, Xvideo problems etc. etc. Someone said its due a clash of IRQ channels.. but then y is 8.32.5 working??