ELRepo Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000355 [channel: elrepo/el6] fglrx-x11-drv major always 2013-02-28 05:30 2017-01-27 17:28
Reporter stevemowbray View Status public  
Assigned To pperry
Priority normal Resolution open  
Status assigned  
Summary 0000355: fglrx drivers broken by CentOS CR updates to 6.4
Description Since the large batch of updates to the CentOS CR channel last night, and the change to the xorg ABI, all my machines running the fglrx driver fail.

Xorg.0.log contains
[ 31.995] (II) Loading /usr/lib64/xorg/modules/drivers/fglrx_drv.so
[ 32.012] (EE) Failed to load /usr/lib64/xorg/modules/drivers/fglrx_drv.so: /usr/lib64/xorg/modules/drivers/fglrx_drv.so: undefined symbol: noXFree86DRIExtension
[ 32.012] (II) UnloadModule: "fglrx"
[ 32.012] (II) Unloading fglrx
[ 32.012] (EE) Failed to load module "fglrx" (loader failed, 7)
Additional Information fglrx version:
xorg version:
Tags No tags attached.
Attached Files

- Relationships

-  Notes
toracat (administrator)
2013-02-28 08:54

We are investigating.
pperry (administrator)
2013-02-28 09:01


Thanks for confirming 12.4 is broken with the 6.4 update. I believe the reason is that Red Hat updated Xorg to version 1.13 (ABI version 13) in 6.4 and that ABI is not supported in the ATI/AMD 12.4 driver.

Please could you try the version in elrepo-testing (version 12.8):

yum --enablerepo=elrepo-testing update kmod-fglrx

and let us know if that works for you. If not then we will have to look to updating to a later version. I stopped updating these drivers for elrepo last year as I have no means to test them and no one was providing any feedback for me (I need proactive testers!)

Many thanks.
wolfy (developer)
2013-02-28 09:14

Unfortunately the version from elrepo-testing does not work either. Loading X fails (both for 12.4 and 12.8) with:
[ 28.170] Loading extension GLX
[ 28.170] (II) LoadModule: "fglrx"
[ 28.233] (II) Loading /usr/lib64/xorg/modules/drivers/fglrx_drv.so
[ 28.560] (EE) Failed to load /usr/lib64/xorg/modules/drivers/fglrx_drv.so: /usr/lib64/xorg/modules/drivers/fglrx_drv.so: undefined symbol: noXFree86DRIExtension
[ 28.560] (II) UnloadModule: "fglrx"
[ 28.560] (II) Unloading fglrx
[ 28.560] (EE) Failed to load module "fglrx" (loader failed, 7)
[ 28.560] (EE) No drivers available.
[ 28.560]
Fatal server error:
[ 28.560] no screens found
[ 28.560] (EE)
pperry (administrator)
2013-02-28 09:16

Thanks for testing.

I'm working on updating to the latest 13.1 driver and will post here as soon as it's available to test.

stevemowbray (reporter)
2013-02-28 09:44

I can confirm I still see the same error with 12.8 too.
pperry (administrator)
2013-02-28 10:11

The following packages have been built and pushed to the testing repository.

They should show up on the mirrors shortly.


Please test these latest drivers and let us know if they fix the issue.

stevemowbray (reporter)
2013-02-28 15:03

Unfortunately, it appears that version 13.1 drivers no longer support Radeon 4xxx series cards, which is mostly what we have. I don't think I have any later cards I can test quickly.
wolfy (developer)
2013-02-28 15:15

http://support.amd.com/us/gpudownload/linux/legacy/Pages/legacy-radeon_linux.aspx [^] lists 4xxx as supported
I am more concerned by the fact that RHEL 6.4 has xorg-x11-server-common-1.13.0 and the above mentioned page says "Automated installer and Display Drivers for Xorg 6.9 to Xserver _1.12_ [..]"
stevemowbray (reporter)
2013-02-28 15:16

Update: managed to find a Radeon 5xxx series card and the 13.1 driver works with that. So the initial issue is resolved.

Not much use for most of our machines with the older cards though :-<
pperry (administrator)
2013-02-28 16:27


Many thanks for confirming the 13.1 release works with 6.4

I will start looking at their legacy releases to see what we can do with that.

@wolfy - hopefully that might be a typo. That said, they are not known for backporting support for newer versions of X into their legacy drivers as NVIDIA do. For example, the old 9.3 legacy release never worked with EL6 at all for the same reason.
wolfy (developer)
2013-03-01 02:42

I've just installed fglrx-kmod-13.1-1.el6 on my system ( ATI RS780C [Radeon HD 3100] ) and everything seems fine.
stevemowbray (reporter)
2013-03-01 03:15

It would be great if you could get legacy drivers working as well.

It's certainly odd that a 3xxx series card is apparently working. I've tried a couple more 4xxx this morning and the driver does not recognise them:

[ 59.393] (II) AMD Proprietary Linux Driver Version Identifier:9.01.11
[ 59.393] (II) AMD Proprietary Linux Driver Release Identifier: 9.012
[ 59.393] (II) AMD Proprietary Linux Driver Build Date: Dec 19 2012 14:41:10
[ 59.393] (++) using VT number 1

[ 59.393] (WW) Falling back to old probe method for fglrx
[ 59.444] (II) Loading PCS database from /etc/ati/amdpcsdb /etc/ati/amdpcsdb.default
[ 59.870] ukiDynamicMajor: failed to open /proc/ati/major
[ 59.870] ukiDynamicMajor: failed to open /proc/ati/major
[ 59.897] (EE) No supported AMD display adapters were found
pperry (administrator)
2013-03-01 04:52

^^ I agree, Wolfy's does indeed look strange given what we were expecting.

If you download the .run installer and extract it (./and-driver-installer-catalyst-blah.run --extract somedir/), there are two executable's named amd-dcm32 and amd-dcm64 in the top level dir that the ati installer uses to detect supported hardware. It might be interesting to run those and see what they report.

Here's what I see, as expected, on my NVIDIA box:

$ ./amd_dcm64
./amd_dcm64: No supported adapters detected

I don't know if similar utils exist in the 13.1 legacy driver installer as I've not played with that yet.

I will try to build the legacy driver as soon as I can but no promises as I'm running out of free time.
stevemowbray (reporter)
2013-03-01 07:30

When I run amd_dcm64 on the only machine I have with a Radeon 3xxx (3450 in fact) I get "No supported adapters detected".
wolfy (developer)
2013-03-01 08:18

Just did a bit more testing and there exist some problems. None of the configuration tools seem to work.
[root@wolfy ~]# amdconfig enable
amdconfig: No supported adapters detected

[root@wolfy ~]# amdcccle
There was a problem initializing Catalyst Control Center Linux edition. It could be caused by the following.

No AMD graphics driver is installed, or the AMD driver is not functioning properly.
Please install the AMD driver appropriate for you AMD hardware, or configure using aticonfig.

[root@wolfy ~]# aticonfig
aticonfig: No supported adapters detected

and last but not least:
[wolfy@wolfy tmp]$ glxgears
X Error of failed request: BadRequest (invalid request code or no such operation)
  Major opcode of failed request: 152 (GLX)
  Minor opcode of failed request: 19 (X_GLXQueryServerString)
  Serial number of failed request: 12
  Current serial number in output stream: 12

In addition to that, in Xorg.0.log I see something which I am not sure that is correct:
[ 30.463] (II) LoadModule: "glx"
[ 30.510] (II) Loading /usr/lib64/xorg/modules/extensions/fglrx/libglx.so
[ 30.525] (II) Module glx: vendor="Advanced Micro Devices, Inc."
[ 30.525] compiled for 6.9.0, module version = 1.0.0
[ 30.534] Loading extension GLX
[ 30.534] (II) LoadModule: "ati"
[ 30.534] (II) Loading /usr/lib64/xorg/modules/drivers/ati_drv.so
[ 30.706] (II) Module ati: vendor="X.Org Foundation"
[ 30.706] compiled for 1.13.0, module version = 6.99.99
[ 30.706] Module class: X.Org Video Driver
[ 30.706] ABI class: X.Org Video Driver, version 13.1
[ 30.706] (II) LoadModule: "radeon"
[ 30.706] (II) Loading /usr/lib64/xorg/modules/drivers/radeon_drv.so
[ 30.753] (II) Module radeon: vendor="X.Org Foundation"
[ 30.753] compiled for 1.13.0, module version = 6.99.99
[ 30.753] Module class: X.Org Video Driver
[ 30.753] ABI class: X.Org Video Driver, version 13.1

Back in my Nvidia days I've never seen the Xorg and proprietary drivers loaded simultaneously so I have to ask: is it normal what I see above ?
pperry (administrator)
2013-03-01 08:26

@wolfy - did you reboot after changing drivers? I'm not sure what is going on on your system there.
pperry (administrator)
2013-03-01 08:35
edited on: 2013-03-01 08:37

I have just built the 13.1 Legacy drivers for you all to try:


EDIT: Note, there are named kmod-fglrx-legacy so remove any previous kmod-fglrx packages and do 'yum install kmod-fglrx-legacy' to test.

But as we suspect, I expect these to fail on 6.4 due to lack of support for Xorg 1.13 (assuming AMD's documentation is correct).

Packages are just syncing out to the mirrors now and will be in the el6 testing repository.

http://elrepo.org/linux/testing/el6/ [^]

After a bit of googling, I came across a recommendation to add the following to xorg.conf as a workaround for the ABI check. No idea if it works or not, but perhaps you'd like to try given we've got nothing to lose at this point.

Section "ServerFlags"
    Option "IgnoreABI" "True"

If none of the above works then we are left in a situation where older hardware is unsupported on RHEL6.4 unless AMD updates the legacy drivers.

wolfy (developer)
2013-03-01 08:43

ref: @wolfy - did you reboot after changing drivers? I'm not sure what is going on on your system there.

 Of course I did.

ref: legacy drivers: we'll try as soon as the packages become available.Or Monday if we cannot get them during the next 30-40 min.
wolfy (developer)
2013-03-01 08:56

It seems that there is a small bug in the fglrx-legacy-x11-drv package:

--> Running transaction check
---> Package fglrx-legacy-x11-drv.x86_64 0:13.1-1.el6.elrepo will be installed
--> Processing Dependency: fglrx-kmod = 13.1-1.el6.elrepo for package: fglrx-legacy-x11-drv-13.1-1.el6.elrepo.x86_64
wolfy (developer)
2013-03-01 09:25

Anyway, as expected the legacy drivers do not work:
[ 65.779] Loading extension GLX
[ 65.779] (II) LoadModule: "fglrx"
[ 65.779] (II) Loading /usr/lib64/xorg/modules/drivers/fglrx_drv.so
[ 65.798] (EE) Failed to load /usr/lib64/xorg/modules/drivers/fglrx_drv.so: /usr/lib64/xorg/modules/drivers/fglrx_drv.so: undefined symbol: noXFree86DRIExtension
[ 65.798] (II) UnloadModule: "fglrx"
[ 65.798] (II) Unloading fglrx
[ 65.798] (EE) Failed to load module "fglrx" (loader failed, 7)
[ 65.798] (EE) No drivers available.
[ 65.798]
Fatal server error:
[ 65.798] no screens found
[ 65.798] (EE)

I wonder if bypassing the ABI check is worth testing in this scenario.
wolfy (developer)
2013-03-01 09:38

For what it's worth: rpm -Uvh --nodeps fglrx-legacy-x11-drv-13.1-1.el6.elrepo.x86_64 kmod-fglrx-legacy-13.1-1.el6.elrepo.x86_64.rpm does not update grub.conf
wolfy (developer)
2013-03-01 09:52

I've added another coin and I tried to bypass the ABI check. 2 reboots later there was absolutely no difference compared to the original bug report or to (0002842).
pperry (administrator)
2013-03-01 10:28

OK, thanks. Apologies about the messed up Requires - as you did it's fine to just use --nodeps.

I think this is the key log entry that tells us that Xorg 1.13 is not yet supported:

 [ 65.798] (EE) Failed to load /usr/lib64/xorg/modules/drivers/fglrx_drv.so: /usr/lib64/xorg/modules/drivers/fglrx_drv.so: undefined symbol: noXFree86DRIExtension
pperry (administrator)
2013-03-01 10:37

Here is the %post script section that should update grub.conf:

if [ "${1}" -eq 1 ]; then
  # Check if xorg.conf exists, if it does, backup and remove [BugID # 0000127]
  [ -f %{_sysconfdir}/X11/xorg.conf ] && \
    mv %{_sysconfdir}/X11/xorg.conf %{_sysconfdir}/X11/xorg.conf.elreposave-fglrx &>/dev/null
  # xorg.conf now shouldn't exist so create it
  [ ! -f %{_sysconfdir}/X11/xorg.conf ] && %{_bindir}/aticonfig --initial &>/dev/null
  # Make sure we have a Files section in xorg.conf, otherwise create an empty one
  [ -w ${XORGCONF} ] && ! grep -q 'Section "Files"' ${XORGCONF} && \
    echo -e 'Section "Files"\nEndSection' >> ${XORGCONF}
  /sbin/chkconfig --add atieventsd
  # Enable console access for amdcccle-su on a PAM secured system
  if [ -e /etc/pam.d/su ]; then
    ln -s /etc/pam.d/su /etc/pam.d/amdcccle-su
  # Disable the radeon driver
  if [[ -x /sbin/grubby && -e /boot/grub/grub.conf ]]; then
    # get installed kernels
    for KERNEL in $(rpm -q --qf '%{v}-%{r}.%{arch}\n' kernel); do
    # Check kABI compatibility
      for KABI in $(find /lib/modules -name fglrx.ko | cut -d / -f 4); do
        if [[ "$KERNEL" == "$KABI" && -e "$VMLINUZ" ]]; then
          /sbin/grubby --update-kernel="$VMLINUZ" \
            --args='radeon.modeset=0' &>/dev/null
fi || :

This section is only run on new installs, not on updates. I wonder if your use of 'rpm -Uvh' caused this whereas 'rpm -ivh' would have worked? This is something I've not considered before and I must admit I would also have instinctively used -Uvh so perhaps you've found a bug!
wolfy (developer)
2013-03-01 10:43

I ran the postinstall scripts manually after installing the packages ( I verified grub.conf, noticed that modeset did not exist, run rpm -q --scripts and executed the relevant parts of %postinstall/grubby and weak-modules/ manually).

As of difference: since there was no existing package prior to install ( I manually removed the previous version), -i and -U should have behaved the same. The odd part is that xorg.conf WAS created.
pperry (administrator)
2013-03-01 11:37

Thanks for the clarification Wolfy. I can't explain your observations but it does sound like we have an issue there somewhere. If you can figure out what's going wrong I'd be glad to fix it.

BTW, did you try the xorg.conf IgnoreABI workaround?
wolfy (developer)
2013-03-01 15:19

Yes, I did. See http://elrepo.org/bugs/view.php?id=355#c2846 [^]
pperry (administrator)
2013-03-01 17:00

OK, thanks wolfy (I missed that bit).
wolfy (developer)
2013-03-08 00:41

I have just downgraded my Xorg to the version available in CentOS 6.3/updates and the fglrx packaged shipped by elrepo works perfectly.

[wolfy@wolfy tmp]$ glxinfo| head -5
name of display: :0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: ATI
server glx version string: 1.4

[wolfy@wolfy tmp]$ fglrxinfo
display: :0 screen: 0
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: ATI Radeon 3100 Graphics
OpenGL version string: 3.3.11631 Compatibility Profile Context

snip from Xorg.0.log:
[ 29.937]
X.Org X Server 1.10.6
Release Date: 2012-02-10
[ 29.967] X Protocol Version 11, Revision 0
[ 29.967] Build Operating System: c6b7 2.6.32-220.el6.x86_64
[ 29.967] Current Operating System: Linux wolfy 2.6.32-358.0.1.el6.x86_64 #1 SMP Wed Feb 27 06:06:45 UTC 2013 x86_64
[ 30.285] (II) Loading extension DRI2
[ 30.285] (II) LoadModule: "fglrx"
[ 30.286] (II) Loading /usr/lib64/xorg/modules/drivers/fglrx_drv.so
[ 30.680] (II) Module fglrx: vendor="FireGL - ATI Technologies Inc."
[ 30.686] compiled for, module version = 8.96.4
[ 30.686] Module class: X.Org Video Driver
[ 30.688] (II) Loading sub module "fglrxdrm"
[ 30.688] (II) LoadModule: "fglrxdrm"
[ 30.688] (II) Loading /usr/lib64/xorg/modules/linux/libfglrxdrm.so
[ 30.755] (II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
[ 30.755] compiled for, module version = 8.96.4
[ 30.755] (II) ATI Proprietary Linux Driver Version Identifier:8.96.4
[ 30.755] (II) ATI Proprietary Linux Driver Release Identifier: 8.961
[ 30.755] (II) ATI Proprietary Linux Driver Build Date: Apr 5 2012 23:06:21
[ 30.755] (++) using VT number 7

[ 30.764] (WW) Falling back to old probe method for fglrx
[ 30.957] (II) Loading PCS database from /etc/ati/amdpcsdb
[ 30.988] (--) Chipset Supported AMD Graphics Processor (0x9611) found
[ 31.000] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:17:0) found
[ 31.002] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:18:0) found
[ 31.003] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:18:1) found
[ 31.003] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:18:2) found
[ 31.003] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:19:0) found
[ 31.003] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:19:1) found
[ 31.003] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:19:2) found
[ 31.003] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:20:0) found
[ 31.003] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:20:1) found
[ 31.003] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:20:2) found
[ 31.003] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:20:3) found
[ 31.003] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:20:4) found
[ 31.003] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:20:5) found
[ 31.003] (II) AMD Video driver is running on a device belonging to a group targeted for this release
[ 31.004] (II) AMD Video driver is signed
[ 31.004] (II) Loading /usr/lib64/xorg/modules/drivers/fglrx_drv.so
[ 31.004] (II) Loading /usr/lib64/xorg/modules/linux/libfglrxdrm.so
[ 31.004] (II) fglrx(0): pEnt->device->identifier=0x1a77d20
[ 31.004] (II) fglrx(0): === [xdl_xs110_atiddxPreInit] === begin
[ 31.233] (II) Loading sub module "fglrxdrm"
[ 31.233] (II) LoadModule: "fglrxdrm"
[ 31.233] (II) Loading /usr/lib64/xorg/modules/linux/libfglrxdrm.so
[ 31.233] (II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
[ 31.233] compiled for, module version = 8.96.4
[ 31.277] ukiDynamicMajor: found major device number 248
[ 31.277] ukiDynamicMajor: found major device number 248
[ 31.277] ukiOpenByBusid: Searching for BusID PCI:1:5:0
[ 31.277] ukiOpenDevice: node name is /dev/ati/card0
[ 31.278] ukiOpenDevice: open result is 9, (OK)
[ 31.278] ukiOpenByBusid: ukiOpenMinor returns 9
[ 31.278] ukiOpenByBusid: ukiGetBusid reports PCI:1:5:0
[ 31.278] (**) fglrx(0): NoAccel = NO
[ 31.278] (**) fglrx(0): ATI 2D Acceleration Architecture enabled
[ 31.278] (--) fglrx(0): Chipset: "ATI Radeon 3100 Graphics" (Chipset = 0x9611)
[ 31.278] (--) fglrx(0): (PciSubVendor = 0x1043, PciSubDevice = 0x82ee)
[ 31.278] (==) fglrx(0): board vendor info: third party graphics adapter - NOT original ATI
[ 31.278] (--) fglrx(0): Linear framebuffer (phys) at 0xf4000000
[ 31.278] (--) fglrx(0): MMIO registers at 0xfbef0000
[ 31.278] (--) fglrx(0): I/O port at 0x0000c000
[ 31.278] (==) fglrx(0): ROM-BIOS at 0x000c0000
[ 31.458] (II) fglrx(0): AC Adapter is used
[ 31.484] (II) fglrx(0): Primary V_BIOS segment is: 0xc000

I have amended the "Known Issues " section of the release notes for CentOS 6.4 with the relevant info and the workaround.
s3men (reporter)
2013-03-10 00:10

I have Radeon HD 6290, upgrade driver to 13.1 and flight is normal.
pperry (administrator)
2013-03-13 07:46

Thanks for the feedback.

I'm just promoted the latest fglrx-13.1 drivers to the main repository for el6.

I've deleted the broken legacy packages tested earlier in this thread from the repos.

I've also promoted older 12.8 packages that were still lurking in testing to the main repo.
Yves Bellefeuille (reporter)
2013-03-13 19:03

Is it expected that fglrx-13.1 doesn't work with Radeon 4xxx even if xorg isn't updated?

If so, can I suggest that the oldest version that does work (fglrx-12.8, apparently) be given a different name to make it easier to install that version and stay with it? fglrx-x11-drv-legacy-12.8 does seem like an appropriate name to me.
wolfy (developer)
2013-03-14 01:12

It is expected and well documented under the "known issues" section at http://elrepo.org/tiki/kmod-fglrx [^] . In fglrx-13.1 ATI removed support for the 3/4/5xxx series so one MUST use the -legacy drivers.
dragonfly (reporter)
2013-03-14 14:20

I have a AMD FirePro 3D V4800. It fail after upgrading to CentOS 6.4. I had to downgrade Xorg to CentOS 6.3 to fix the probelm.
borealis (reporter)
2013-03-14 20:35

After I upgraded my dev workstation from CentOS 6.3 (64-bit) to CentOS 6.4 (64-bit), the proprietary drivers for my AMD FirePro V4800 failed as described above. I was using AMD's proprietary fglrx-8.911.3.3 driver. This and the newer proprietary fglrx- driver failed with the error:

[ 22.664] (EE) Failed to load /usr/lib64/xorg/modules/drivers/fglrx_drv.so: /usr/lib64/xorg/modules/drivers/fglrx_drv.so: undefined symbol: noXFree86DRIExtension

I *successfully* fixed the problems after uninstalling the proprietary AMD driver and installing the fglrx-x11-drv-13.1-1.el6.elrepo.x86_64 (and fglrx-kmod) drivers mentioned in this thread. The only minor problem is the AMD "Unsupported hardware" watermark at the bottom right of my display. I will figure that out later. Thanks for the helpful information and quick work on the fglrx drivers!
stevemowbray (reporter)
2013-03-15 04:52

> In fglrx-13.1 ATI removed support for the 3/4/5xxx series
> so one MUST use the -legacy drivers.

This is surely wrong? The 3xxx/4xxx series are no longer supported but the 5xxx are. All my 5xxx series cards are working with the 13.1 drivers.
wolfy (developer)
2013-03-15 05:05

My bad. I did not remember correctly the content of http://support.amd.com/us/gpudownload/linux/legacy/Pages/legacy-radeon_linux.aspx [^] which mentions 2/3/4xxx not 3/4/5xxx. I ammended the CentOS 6.4 Release Notes accordingly.
wolfy (developer)
2013-03-15 05:43

For what it's worth: we've just tested the most recent 3 versions of kmod-fglrx that exist now in the main repository, using
  01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS780L [Radeon HD 3000]
The OS was a fully updated CentOS 6.4 except for the xorg packages ( we used the most recent ones from CentOS 6.3).

Conclusion: the most recent version of kmod-fglrx (as provided by elrepo ) which works on this chipset is 12.4; 12.8 and 13.1 claim that they cannot find a compatible adapter.
pperry (administrator)
2013-03-15 08:26

@wolfy: I didn't realise the 12.8 also dropped support.

Let me get the 13.1 legacy drivers built over the weekend, and then we can make a decision as to which is the "best" legacy driver to recommend / keep longer term in elrepo for older hardware. If necessary I can rebuild 12.4 as fglrx-legacy-12.4
wolfy (developer)
2013-03-15 08:38

> I didn't realise the 12.8 also dropped support.

This came as a surprise for us, too, I was pretty sure that 12.8 were the recommended drivers.
We discovered this by accident: my colleague ( who was using 12.4, as I am ) run a "yum update" in order to upgrade his kernel but kmod-fglrx-13.1 was installed too. We used "yum downgrade", installed 12.8 and found out that they did not work either. Another "yum downgrade" later he was on 12.4 and the system had again a functional video driver.

I guess we should verify which one between 12.4 and http://support.amd.com/us/gpudownload/linux/legacy/Pages/legacy-radeon_linux.aspx [^] works [better] and is newer.
pperry (administrator)
2013-03-15 09:03

wolfy: ACK. I'll try to get that 13.1 legacy driver built this weekend.
wolfy (developer)
2013-03-15 09:07

I did a bit more digging. Apparently 12.4 identifies itself as "Version: 8.96.4" while the 13.1 legacy driver claims to be "". I guess 13.1 should get packaged and shipped for the older cards, mentioning everywhere in large bold letters that they work up to xorg 1.12 only.
Yves Bellefeuille (reporter)
2013-03-15 16:21

I confirm that 12.8 doesn't work with 4xxx; 12.4 does work.
pajamian (reporter)
2013-03-16 18:48

I encountered the same issue in Fedora 18 (which also runs xorg server 1.13). What I found looking into it is that the missing symbol noXFree86DRIExtension is part of the xfre86dri extension which is still a part of xorg 1.13 (and the symbol is included, but has been moved to a different file), but that and other extensions that were built by default in xorg 1.12 don't seem to be built in 1.13 for some reason. So the code is there, we just have to figure out how to get it to build again. I think this is actually an xorg bug and can likely be fixed in the xorg-x11-server packages spec file.

The bug I filed in Fedora is at https://bugzilla.redhat.com/show_bug.cgi?id=921375 [^] it might pay to file this bug for RHEL 6.4 as well.
pperry (administrator)
2013-03-17 14:38

Apologies for the delay.

I have built fglrx-legacy packages for the 13.1 driver release:


These packages are currently syncing to the mirrors.

The kmod package was built against the 6.4 kernel and _I think_ it should weak-link back against later 6.3 kernels (after 2.6.32-279.11 due to a kABI bug that was fixed).

The fglrx-legacy-x11-drv package obviously isn't compatible with the version of xorg in 6.4 so I've added a Conflict for xorg-x11-server-Xorg >= 1.13

In summary, these packages should support older 2000, 3000 and 4000 series cards on 6.4 installations that have NOT updated their xorg-* packages.

Please test and report back
pperry (administrator)
2013-03-17 14:41

^^ the above packages were pushed to the el6 testing repository.
stindall (administrator)
2013-03-17 18:09
edited on: 2013-03-17 18:14

I just successfully tested kmod-fglrx-legacy / fglrx-legacy-x11-drv on a SL6.3/6.4 system (SL6.4 is not released, but many 6.4 upgrades were installed incl. kernel and xorg. Downgraded xorg components before testing).

# lspci -nn|grep VGA
01:05.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RS880 [Radeon HD 4200] [1002:9710]

# uname -r

# rpm -q kmod-fglrx-legacy fglrx-legacy-x11-drv

# rpm -q xorg-x11-server-Xorg xorg-x11-server-common xorg-x11-server-utils

# lsmod|grep fglrx
fglrx 3297174 40

$ glxgears > 3100 FPS

# cat /etc/grub.conf
title Scientific Linux (2.6.32-358.2.1.el6.x86_64)
    root (hd0,6)
    kernel /vmlinuz-2.6.32-358.2.1.el6.x86_64 ro root=/dev/primary/el6 rd_NO_LUKS rd_LVM_LV=primary/el6 rd_LVM_LV=primary/swap1 LANG=en_US.UTF-8 rd_MD_UUID=592265ca:6bffc90e:39eac407:630f26fb SYSFONT=latarcyrheb-sun16 rhgb quiet rd_MD_UUID=6fa392a0:ed401cd0:0093dff1:7cec46a5 KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM crashkernel=auto radeon.modeset=0
    initrd /initramfs-2.6.32-358.2.1.el6.x86_64.img

# cat /etc/X11/xorg.conf
Section "ServerLayout"
    Identifier "aticonfig Layout"
    Screen 0 "aticonfig-Screen[0]-0" 0 0

Section "Files"
    ModulePath "/usr/lib64/xorg/modules/extensions/fglrx"
    ModulePath "/usr/lib64/xorg/modules"

Section "Monitor"
    Identifier "aticonfig-Monitor[0]-0"
    Option "VendorName" "ATI Proprietary Driver"
    Option "ModelName" "Generic Autodetecting Monitor"
    Option "DPMS" "true"

Section "Device"
    Identifier "aticonfig-Device[0]-0"
    Driver "fglrx"
    BusID "PCI:1:5:0"

Section "Screen"
    Identifier "aticonfig-Screen[0]-0"
    Device "aticonfig-Device[0]-0"
    Monitor "aticonfig-Monitor[0]-0"
    DefaultDepth 24
    SubSection "Display"
        Viewport 0 0
        Depth 24

# ls -lh /lib/modules/*/{extra,weak-updates}/fglrx-legacy/fglrx.ko
(spacing added)
lrwxrwxrwx. 1 root root 62 Mar 17 19:27 /lib/modules/2.6.32-279.19.1.el6.x86_64/weak-updates/fglrx-legacy/fglrx.ko -> /lib/modules/2.6.32-358.el6.x86_64/extra/fglrx-legacy/fglrx.ko

lrwxrwxrwx. 1 root root 62 Mar 17 19:27 /lib/modules/2.6.32-279.22.1.el6.x86_64/weak-updates/fglrx-legacy/fglrx.ko -> /lib/modules/2.6.32-358.el6.x86_64/extra/fglrx-legacy/fglrx.ko

lrwxrwxrwx. 1 root root 62 Mar 17 19:27 /lib/modules/2.6.32-358.2.1.el6.x86_64/weak-updates/fglrx-legacy/fglrx.ko -> /lib/modules/2.6.32-358.el6.x86_64/extra/fglrx-legacy/fglrx.ko

-rw-r--r--. 1 root root 4.5M Mar 17 16:22 /lib/modules/2.6.32-358.el6.x86_64/extra/fglrx-legacy/fglrx.ko


To downgrade "6.4" xorg:

# yum remove xorg-x11-drv-modesetting xorg-x11-drivers

# yum downgrade xorg-x11-server-Xorg xorg-x11-server-common xorg-x11-server-utils xorg-x11-drv*

# grep exclude /etc/yum.conf
exclude=xorg-x11-server-Xorg xorg-x11-server-common xorg-x11-server-utils xorg-x11-drv* kmod-fglrx* fglrx*x11-drv

pperry (administrator)
2013-03-17 18:24


Many thanks for the detailed feedback. Looks like the package is behaving as expected.

Lets leave it in testing for a week or so to allow others to offer their feedback.
wolfy (developer)
2013-03-17 18:42
edited on: 2013-03-17 18:55

A bit as expected but kmod-fglrx-legacy does not update cleanly the previous kmod-fglrx:
[root@wolfy ~]# yum -y install kmod-fglrx-legacy.x86_64 --enablerepo=elrepo-testing
Loaded plugins: changelog, downloadonly, fastestmirror, kabi, presto, priorities, refresh-packagekit, remove-with-leaves
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package kmod-fglrx-legacy.x86_64 0:13.1-2.el6.elrepo will be installed
--> Processing Dependency: fglrx-legacy-x11-drv = 13.1-2.el6.elrepo for package: kmod-fglrx-legacy-13.1-2.el6.elrepo.x86_64
--> Running transaction check
---> Package fglrx-legacy-x11-drv.x86_64 0:13.1-2.el6.elrepo will be installed
--> Processing Conflict: fglrx-legacy-x11-drv-13.1-2.el6.elrepo.x86_64 conflicts fglrx-x11-drv
--> Processing Conflict: fglrx-legacy-x11-drv-13.1-2.el6.elrepo.x86_64 conflicts fglrx-kmod
--> Finished Dependency Resolution
Error: fglrx-legacy-x11-drv conflicts with kmod-fglrx-12.4-1.el6.elrepo.x86_64
Error: fglrx-legacy-x11-drv conflicts with fglrx-x11-drv-12.4-1.el6.elrepo.x86_64
 You could try using --skip-broken to work around the problem

[root@wolfy ~]# yum -y update kmod-fglrx-legacy.x86_64 --enablerepo=elrepo-testing
Loaded plugins: changelog, downloadonly, fastestmirror, kabi, presto, priorities, refresh-packagekit, remove-with-leaves
Loading support for CentOS kernel ABI
Setting up Update Process
Package(s) kmod-fglrx-legacy.x86_64 available, but not installed.
No Packages marked for Update

I am not 100% sure but I think that adding Obsoletes:kmod-fglrx <= 12.4 would be suitable for this case

In other news, the packages install and work fine on my "[AMD] nee ATI RS780C [Radeon HD 3100]":
[ 32.123] (II) LoadModule: "fglrx"
[ 32.124] (II) Loading /usr/lib64/xorg/modules/drivers/fglrx_drv.so
[ 33.162] (II) Module fglrx: vendor="FireGL - ATI Technologies Inc."
[ 33.196] compiled for, module version = 8.97.2
[ 33.196] Module class: X.Org Video Driver
[ 33.322] (II) Loading sub module "fglrxdrm"
[ 33.322] (II) LoadModule: "fglrxdrm"
[ 33.323] (II) Loading /usr/lib64/xorg/modules/linux/libfglrxdrm.so
[ 33.385] (II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
[ 33.385] compiled for, module version = 8.97.2
[ 33.385] (II) ATI Proprietary Linux Driver Version Identifier:8.97.2
[ 33.385] (II) ATI Proprietary Linux Driver Release Identifier:
[ 33.385] (II) ATI Proprietary Linux Driver Build Date: Nov 16 2012 14:45:00

Yves Bellefeuille (reporter)
2013-03-17 18:53

kmod-fglrx-legacy and fglrx-legacy-x11-drv work properly for me with 4xxx. I did have to manually uninstall kmod-fglrx-12.4-1 and fglrx-x11-drv-12.4-1 first.
stindall (administrator)
2013-03-17 18:56

Likewise, I uninstalled kmod-fglrx and fglrx-x11-drv before installing legacy.
pperry (administrator)
2013-03-17 19:02

We don't want kmod-fglrx-legacy to obsolete kmod-fglrx because some users may actually want to carry on using kmod-fglrx and update - i.e, those with hardware based on 5000 series and above. So we can't use an obsoletes in this case.

Users have to know that their hardware is no longer supported by kmod-fglrx and know that they need to switch to the legacy package. There's not much we can do to help that from a packaging point of view.

IMHO the best solution is to manually uninstall the old packages and install the new legacy packages.
wolfy (developer)
2013-03-17 19:11
edited on: 2013-03-17 19:14

Those with hardware based on 5000 series and above should and can use kmod-fglrx, not kmod-fglrx-legacy. And due to yum picking the shorter name, a yum update should work for them (and pick the correct package, i.e. kmod-fglrx) even if kmod-fglrx-legacy also obsoletes kmod-fglrx <=12.4 .

Mind that I specifically added a version, the last one which we knew that was suitable for 2/3/4xxx. Although I think that even using <=12.8 would be fine, this allows them to upgrade the driver if they installed by mistake the non-working version

pperry (administrator)
2013-03-17 20:27

My concern is that anyone still using an older version of kmod-fglrx (12.4 or earlier) who then performs a generic 'yum update' will get kmod-fglrx obsoleted by kmod-fglrx-legacy.

Are you saying you think that's not the case and that yum would instead update kmod-fglrx to the latest available version rather than obsoleting it in favour of kmod-fglrx-legacy?
wolfy (developer)
2013-03-18 02:16

Yes, that is exactly what I meant. Roughly speaking (*), when given several packages which satisfy the same requirement for Provides, yum picks the one with the shortest name. As proof:

[wolfy@wolfy ~]$ rpmdev-vercmp kmod-fglrx-13.1 kmod-fglrx-legacy-13.1
0:kmod-fglrx-13.1 is newer

Should you agree with my suggestion (and we definitely have to test before promoting to stable - I volunteer as guinea pig ) if I am correct in the case of a yum update we should end up with one of the following cases:

1) a generic "yum update" or "yum update kmod-fglrx"
a) people with older cards and kmod-fglrx <= 12.4 . They will cry because the kmod-fglrx-13.1 will replace the installed package despite not being compatible with the old cards. Nothing we can do to fix that , short of a test similar to nvidia-detect, run in %pre
b) people with older cards and kmod-fglrx = 12.8 or newer. They already cry because as it has been proven by our testing, 12.8 does not support the older cards; an upgrade to 13.1 will not change that. Once again nothing we can do to fix that , short of a test similar to nvidia-detect, run in %pre
c) people with new cards and any version of kmod-fglrx: they end up with the new package and everybody should be happy

2) yum update kmod-fglrx-legacy
a) people with older cards and kmod-fglrx <= 12.8. Happy, happy happy 'cause they end up with the new driver which obsoletes the older one despite the name change
b) people with new cards and kmod-fglrx <= 12.8: they should _not_ do that. If they do, they end up with the new driver and the result is not yet certain since we have not tested. But once again, they should _not_ do that or they inflict their own pain. And once again nothing we can do to fix that short of a test run in %pre

Basically, if I am correct wrt the "Obsoletes" part, the only behaviour changes compared to the current situation of the package that will occur are:
- in case 2a: people will no longer need to remove the old driver first.
- in case 2b: self inflicted pain and they deserve what they get :) The happy owners of newer cards should not attempt to install - on purpose - the legacy drivers. Yum will not enforce that on them, they have to deliberately do that.

* The behaviour is a bit smarter nowadays. Yum also takes into account the repository from where the package which triggered the Requires comes from , priorities etc
wolfy (developer)
2013-03-18 02:59

For what is worth, as reported by amdcccle:
kmod-fglrx-12.4 provides
- Catalyst version 12.4
- Driver packaging version 8.961-120405a-137531C-ATI
- 2D driver version: 8.96.4
- Catalyst Control Center: 2.14
- OpenGL version 3.3.11631 Profile Context

kmod-fglrx-13.1-legacy provides
- Catalyst version 12.4
- Driver packaging version 8.961-120405a-137531C-ATI
- 2D driver version: 8.97.2
- Catalyst Control Center: 2.15
- OpenGL version 3.3.11672 Profile Context
pperry (administrator)
2013-03-18 14:40


Thanks for clarifying.

We can test this, but lets not test it with real packages.

I can knock up some dummy test packages to mimic the situation with the fglrx packages and we can run through and test some scenarios. The bad news is that it will take me a few days to get back to this due to work commitments.

If yum behaves as you expect, the prospect of being able to do 'yum install kmod-fglrx-legacy' and have it obsolete the old package is very appealing (providing all the install scripts work OK).
pperry (administrator)
2013-03-18 15:03
edited on: 2013-03-18 15:05

Yes, that is exactly what I meant. Roughly speaking (*), when given several packages which satisfy the same requirement for Provides, yum picks the one with the shortest name. As proof:

[wolfy@wolfy ~]$ rpmdev-vercmp kmod-fglrx-13.1 kmod-fglrx-legacy-13.1
0:kmod-fglrx-13.1 is newer

I don't think it's a case of which name is shorter; in my mind rpmdev-vercmp performs a left to right analysis and it's logic can be explained with this statement:

"kmod-fglrx-" in each is equal, then "13" of "13.1" is greater than "legacy". rpmdev-vercmp uses "." and "-" as delimiters and compares the contents between.

Suppose I had named the legacy package kmod-fglrx-4xxx instead as it supports up to 4000 series cards:

$ rpmdev-vercmp kmod-fglrx-13.1 kmod-fglrx-4xxx-13.1
0:kmod-fglrx-13.1 is newer

again no problem as 13 > 4xxx

but what if I'd named it kmod-fglrx-4000:

$ rpmdev-vercmp kmod-fglrx-13.1 kmod-fglrx-4000-13.1
0:kmod-fglrx-4000-13.1 is newer

Now we have a problem as 4000 is greater than 13.

I believe that is why kmod-fglrx will always take precedence over kmod-fglrx-legacy in rpm versioning terms, all else being equal.

Ed Drouillard (reporter)
2013-03-23 12:34

This bug also affects SiS display drivers.

# lspci -nn | grep VGA
01:00.0 VGA compatible controller [0300]: Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter [1039:6325]

and I had to revert back to the 6.3 xorg packages - which is well documented at

https://www.centos.org/modules/newbb/viewtopic.php?topic_id=41846 [^]

Sean Hemp (reporter)
2013-03-24 10:21

lspci -nn | grep VGA

0e:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Barts XT [Radeon HD 6800 Series] [1002:6738]

more Xorg.0.log

[ 15.479] (WW) fglrx: No matching Device section for instance (BusID PCI:0@14:0:0) found
[ 15.479] (WW) fglrx: No matching Device section for instance (BusID PCI:0@15:0:0) found
[ 15.479] (EE) No devices detected.
[ 15.479]
Fatal server error:
[ 15.479] no screens found
[ 15.479] (EE)
pperry (administrator)
2013-03-24 11:33

@Sean Hemp

What driver are you using? What OS? What kernel? What version of Xorg? Without supporting information it's just noise.

Unless it was working _before_ the update to 6.4, it is not related to this bug/issue and you should file a new report.
pperry (administrator)
2013-03-24 11:36

@Ed Drouillard

Yes, this issue will affect ANY older 3rd party display driver that is not part of the distro.
dragonfly (reporter)
2013-06-25 16:16

I think the Current version of AMD driver (12.104.2) solves the problem.
toracat (administrator)
2013-07-18 11:32

There was a post to the CentOS mailing list today that seconds dragonfly's note (AMD driver (12.104.2) works with the X.Org version used by CentOS 6.4).
pperry (administrator)
2013-07-18 15:46

Acknowledged, and thanks for the further confirmation.

This is on my todo list and I will get to it when I can.
pperry (administrator)
2013-07-23 03:07


I just went to look at this today, and I don't see the 12.104.2 driver for download.

The AMD site still points here for the latest HD 2000/3000/4000 series chipsets:

http://support.amd.com/us/gpudownload/linux/legacy/Pages/legacy-radeon_linux.aspx [^]

which lists the same 13.1 driver from 1/21/2013 supporting Xorg up to 1.12

Can someone point me in the right direction please if I am missing something?
pperry (administrator)
2013-07-23 03:15
edited on: 2013-07-23 08:44


If you are referring to this post:

http://lists.centos.org/pipermail/centos/2013-July/135946.html [^]

then this driver is for their FirePro range of cards and doesn't support the more mainstream older HD 2000/3000/4000 series cards that this bug relates to.

We have not previously packaged these drivers.

If someone knows otherwise, please feel free to confirm with evidence here. Thanks.

toracat (administrator)
2013-07-23 08:36


Yes, that's the post I was referring to.
wolfy (developer)
2017-01-27 17:28

Well.. that chip is only supported by the very old AMD drivers and those drivers are not compatible with the Xorg shipped in RHEL>6.4. So comment 0002816 is correct.
IIRC fglrx-legacy is compiled against the latest Xorg it was compatible with but it also requires the kernel version that was available at the time. I do not think it is worth anyone's time to recompile it against a more modern kernel and publish it in elrepo, even if theoretically one could lock the X version to the 3 years old one that was compatible with those drivers and upgrade the rest of the system. From my point of view, if a sysadmin was comfortable enough to preserve an old and known buggy/security affected X version, he should also be able to rebuild the fglrx-legacy package against the kernel of his choice. I am not willing to publicly support that ( even if I can do it in private :) )

Bottom line: I would close this bug as either "unfixable" or "fixed in current release".

- Issue History
Date Modified Username Field Change
2013-02-28 05:30 stevemowbray New Issue
2013-02-28 05:30 stevemowbray Status new => assigned
2013-02-28 05:30 stevemowbray Assigned To => pperry
2013-02-28 08:54 toracat Note Added: 0002815
2013-02-28 09:01 pperry Note Added: 0002816
2013-02-28 09:14 wolfy Note Added: 0002817
2013-02-28 09:16 pperry Note Added: 0002818
2013-02-28 09:44 stevemowbray Note Added: 0002820
2013-02-28 10:11 pperry Note Added: 0002821
2013-02-28 15:03 stevemowbray Note Added: 0002824
2013-02-28 15:15 wolfy Note Added: 0002825
2013-02-28 15:16 stevemowbray Note Added: 0002826
2013-02-28 16:27 pperry Note Added: 0002827
2013-03-01 02:42 wolfy Note Added: 0002831
2013-03-01 03:15 stevemowbray Note Added: 0002832
2013-03-01 04:52 pperry Note Added: 0002835
2013-03-01 07:30 stevemowbray Note Added: 0002836
2013-03-01 08:18 wolfy Note Added: 0002837
2013-03-01 08:26 pperry Note Added: 0002838
2013-03-01 08:35 pperry Note Added: 0002839
2013-03-01 08:37 pperry Note Edited: 0002839
2013-03-01 08:43 wolfy Note Added: 0002840
2013-03-01 08:56 wolfy Note Added: 0002841
2013-03-01 09:25 wolfy Note Added: 0002842
2013-03-01 09:38 wolfy Note Added: 0002844
2013-03-01 09:52 wolfy Note Added: 0002846
2013-03-01 10:28 pperry Note Added: 0002848
2013-03-01 10:37 pperry Note Added: 0002849
2013-03-01 10:43 wolfy Note Added: 0002850
2013-03-01 11:37 pperry Note Added: 0002851
2013-03-01 15:19 wolfy Note Added: 0002854
2013-03-01 17:00 pperry Note Added: 0002856
2013-03-03 19:14 ianmor Issue Monitored: ianmor
2013-03-03 19:14 ianmor Issue End Monitor: ianmor
2013-03-08 00:41 wolfy Note Added: 0002894
2013-03-10 00:10 s3men Note Added: 0002913
2013-03-10 01:52 povder Issue Monitored: povder
2013-03-13 07:46 pperry Note Added: 0002925
2013-03-13 19:03 Yves Bellefeuille Note Added: 0002928
2013-03-14 01:12 wolfy Note Added: 0002932
2013-03-14 14:20 dragonfly Note Added: 0002942
2013-03-14 20:35 borealis Note Added: 0002943
2013-03-15 04:52 stevemowbray Note Added: 0002945
2013-03-15 05:05 wolfy Note Added: 0002946
2013-03-15 05:43 wolfy Note Added: 0002947
2013-03-15 08:26 pperry Note Added: 0002949
2013-03-15 08:38 wolfy Note Added: 0002950
2013-03-15 08:39 wolfy Note Added: 0002951
2013-03-15 08:41 toracat Note Deleted: 0002951
2013-03-15 09:03 pperry Note Added: 0002952
2013-03-15 09:07 wolfy Note Added: 0002953
2013-03-15 16:21 Yves Bellefeuille Note Added: 0002960
2013-03-16 18:48 pajamian Note Added: 0002961
2013-03-16 23:10 pajamian Issue Monitored: pajamian
2013-03-17 14:38 pperry Note Added: 0002964
2013-03-17 14:41 pperry Note Added: 0002965
2013-03-17 18:09 stindall Note Added: 0002966
2013-03-17 18:14 stindall Note Edited: 0002966
2013-03-17 18:24 pperry Note Added: 0002967
2013-03-17 18:42 wolfy Note Added: 0002968
2013-03-17 18:53 Yves Bellefeuille Note Added: 0002969
2013-03-17 18:55 wolfy Note Edited: 0002968
2013-03-17 18:56 stindall Note Added: 0002970
2013-03-17 19:02 pperry Note Added: 0002971
2013-03-17 19:11 wolfy Note Added: 0002972
2013-03-17 19:14 wolfy Note Edited: 0002972
2013-03-17 20:27 pperry Note Added: 0002973
2013-03-18 02:16 wolfy Note Added: 0002974
2013-03-18 02:59 wolfy Note Added: 0002976
2013-03-18 14:40 pperry Note Added: 0002981
2013-03-18 15:03 pperry Note Added: 0002982
2013-03-18 15:05 pperry Note Edited: 0002982
2013-03-23 12:34 Ed Drouillard Note Added: 0002991
2013-03-24 10:21 Sean Hemp Note Added: 0002992
2013-03-24 11:33 pperry Note Added: 0002994
2013-03-24 11:36 pperry Note Added: 0002995
2013-06-25 16:16 dragonfly Note Added: 0003164
2013-07-18 11:32 toracat Note Added: 0003213
2013-07-18 15:46 pperry Note Added: 0003215
2013-07-23 03:07 pperry Note Added: 0003216
2013-07-23 03:15 pperry Note Added: 0003217
2013-07-23 08:36 toracat Note Added: 0003218
2013-07-23 08:44 burakkucat Note Edited: 0003217
2017-01-27 17:28 wolfy Note Added: 0005055

Mantis 1.1.8[^]
Copyright © 2000 - 2009 Mantis Group
Powered by Mantis Bugtracker