cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

yurtesen
Miniboss

Fedora 17 Catalyst 12.4 crash...

Description of problem:

AMD fglrx drivers are malfunctioning

Version-Release number of selected component (if applicable):

Fedora 17

AMD Catalyst 12.4

How reproducible:

Install Fedora 17 then Install Catalyst 12.4

Steps to Reproduce:

1. Install Fedora 17

2. Install Catalyst 12.4

3.

 

Actual results:

It stays at text console...

Expected results:

Login screen

Additional info:

Device: HP dm1-4100 with AMD E-450 APU processor

# cat /mnt/etc/X11/xorg.conf

Section "ServerLayout"

        Identifier     "aticonfig Layout"

        Screen      0  "aticonfig-Screen[0]-0" 0 0

EndSection

Section "Module"

EndSection

Section "Monitor"

        Identifier   "aticonfig-Monitor[0]-0"

        Option      "VendorName" "ATI Proprietary Driver"

        Option      "ModelName" "Generic Autodetecting Monitor"

        Option      "DPMS" "true"

EndSection

Section "Device"

        Identifier  "aticonfig-Device[0]-0"

        Driver      "fglrx"

        BusID       "PCI:0:1:0"

EndSection

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

        EndSubSection

EndSection

# cat /mnt/var/log/Xorg.0.log

[   197.643]

X.Org X Server 1.12.0

Release Date: 2012-03-04

[   197.707] X Protocol Version 11, Revision 0

[   197.728] Build Operating System: x86-01 2.6.32-220.4.1.el6.x86_64

[   197.750] Current Operating System: Linux amd-e450.abo.fi 3.3.4-1.fc17.x86_64 #1 SMP Fri Apr 27 18:39:03 UTC 2012 x86_64

[   197.773] Kernel command line: BOOT_IMAGE=/vmlinuz-3.3.4-1.fc17.x86_64 root=UUID=8e6d54e0-5607-4727-9ffd-5175395b213c ro rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 rhgb quiet

[   197.820] Build Date: 14 March 2012  03:02:21PM

[   197.844] Build ID: xorg-x11-server 1.12.0-2.fc17

[   197.867] Current version of pixman: 0.24.4

[   197.889]    Before reporting problems, check http://wiki.x.org

        to make sure that you have the latest version.

[   197.936] Markers: (--) probed, (**) from config file, (==) default setting,

        (++) from command line, (!!) notice, (II) informational,

        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.

[   198.008] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Apr 29 03:05:34 2012

[   198.031] (==) Using config file: "/etc/X11/xorg.conf"

[   198.055] (==) Using system config directory "/usr/share/X11/xorg.conf.d"

[   198.078] (==) ServerLayout "aticonfig Layout"

[   198.078] (**) |-->Screen "aticonfig-Screen[0]-0" (0)

[   198.078] (**) |   |-->Monitor "aticonfig-Monitor[0]-0"

[   198.079] (**) |   |-->Device "aticonfig-Device[0]-0"

[   198.079] (==) Automatically adding devices

[   198.079] (==) Automatically enabling devices

[   198.079] (==) FontPath set to:

        catalogue:/etc/X11/fontpath.d,

        built-ins

[   198.079] (==) ModulePath set to "/usr/lib64/xorg/modules"

[   198.079] (II) The server relies on udev to provide the list of input devices.

        If no devices become available, reconfigure udev or disable AutoAddDevices.

[   198.079] (II) Loader magic: 0x7c5ac0

[   198.079] (II) Module ABI versions:

[   198.079]    X.Org ANSI C Emulation: 0.4

[   198.079]    X.Org Video Driver: 12.0

[   198.079]    X.Org XInput driver : 16.0

[   198.079]    X.Org Server Extension : 6.0

[   198.080] (--) PCI:*(0:0:1:0) 1002:9806:103c:3387 rev 0, Mem @ 0xe0000000/268435456, 0xf0300000/262144, I/O @ 0x00004000/256, BIOS @ 0x????????/131072

[   198.080] (II) "extmod" will be loaded by default.

[   198.080] (II) "dbe" will be loaded by default.

[   198.080] (II) "glx" will be loaded by default.

[   198.080] (II) "record" will be loaded by default.

[   198.080] (II) "dri" will be loaded by default.

[   198.080] (II) "dri2" will be loaded by default.

[   198.080] (II) LoadModule: "extmod"

[   198.081] (II) Loading /usr/lib64/xorg/modules/extensions/libextmod.so

[   198.082] (II) Module extmod: vendor="X.Org Foundation"

[   198.082]    compiled for 1.12.0, module version = 1.0.0

[   198.082]    Module class: X.Org Server Extension

[   198.082]    ABI class: X.Org Server Extension, version 6.0

[   198.082] (II) Loading extension SELinux

[   198.082] (II) Loading extension MIT-SCREEN-SAVER

[   198.082] (II) Loading extension XFree86-VidModeExtension

[   198.082] (II) Loading extension XFree86-DGA

[   198.082] (II) Loading extension DPMS

[   198.082] (II) Loading extension XVideo

[   198.082] (II) Loading extension XVideo-MotionCompensation

[   198.082] (II) Loading extension X-Resource

[   198.082] (II) LoadModule: "dbe"

[   198.082] (II) Loading /usr/lib64/xorg/modules/extensions/libdbe.so

[   198.082] (II) Module dbe: vendor="X.Org Foundation"

[   198.082]    compiled for 1.12.0, module version = 1.0.0

[   198.082]    Module class: X.Org Server Extension

[   198.082]    ABI class: X.Org Server Extension, version 6.0

[   198.082] (II) Loading extension DOUBLE-BUFFER

[   198.082] (II) LoadModule: "glx"

[   198.082] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so

[   198.083] (II) Module glx: vendor="Advanced Micro Devices, Inc."

[   198.083]    compiled for 6.9.0, module version = 1.0.0

[   198.083] (II) Loading extension GLX

[   198.083] (II) LoadModule: "record"

[   198.083] (II) Loading /usr/lib64/xorg/modules/extensions/librecord.so

[   198.084] (II) Module record: vendor="X.Org Foundation"

[   198.084]    compiled for 1.12.0, module version = 1.13.0

[   198.084]    Module class: X.Org Server Extension

[   198.084]    ABI class: X.Org Server Extension, version 6.0

[   198.084] (II) Loading extension RECORD

[   198.084] (II) LoadModule: "dri"

[   198.084] (II) Loading /usr/lib64/xorg/modules/extensions/libdri.so

[   198.084] (II) Module dri: vendor="X.Org Foundation"

[   198.084]    compiled for 1.12.0, module version = 1.0.0

[   198.084]    ABI class: X.Org Server Extension, version 6.0

[   198.084] (II) Loading extension XFree86-DRI

[   198.084] (II) LoadModule: "dri2"

[   198.085] (II) Loading /usr/lib64/xorg/modules/extensions/libdri2.so

[   198.085] (II) Module dri2: vendor="X.Org Foundation"

[   198.085]    compiled for 1.12.0, module version = 1.2.0

[   198.085]    ABI class: X.Org Server Extension, version 6.0

[   198.085] (II) Loading extension DRI2

[   198.085] (II) LoadModule: "fglrx"

[   198.085] (II) Loading /usr/lib64/xorg/modules/drivers/fglrx_drv.so

[   198.124] (II) Module fglrx: vendor="FireGL - ATI Technologies Inc."

[   198.124]    compiled for 1.4.99.906, module version = 8.96.4

[   198.124]    Module class: X.Org Video Driver

[   198.125] (II) Loading sub module "fglrxdrm"

[   198.125] (II) LoadModule: "fglrxdrm"

[   198.125] (II) Loading /usr/lib64/xorg/modules/linux/libfglrxdrm.so

[   198.125] (II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."

[   198.125]    compiled for 1.4.99.906, module version = 8.96.4

[   198.125] (II) ATI Proprietary Linux Driver Version Identifier:8.96.4

[   198.125] (II) ATI Proprietary Linux Driver Release Identifier: 8.961       

[   198.125] (II) ATI Proprietary Linux Driver Build Date: Apr  5 2012 23:06:21

[   198.125] (--) using VT number 1

[   198.184] (WW) Falling back to old probe method for fglrx

[   198.210] (II) Loading PCS database from /etc/ati/amdpcsdb

[   198.213] (--) Chipset Supported AMD Graphics Processor (0x9806) found

[   198.213] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:1:1) found

[   198.213] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:17:0) found

[   198.213] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:18:0) found

[   198.213] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:18:2) found

[   198.213] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:19:0) found

[   198.213] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:19:2) found

[   198.213] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:20:0) found

[   198.213] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:20:2) found

[   198.214] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:20:3) found

[   198.214] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:20:4) found

[   198.214] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:21:0) found

[   198.214] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:21:1) found

[   198.214] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:22:0) found

[   198.214] (WW) fglrx: No matching Device section for instance (BusID PCI:0@0:22:2) found

[   198.216] (II) AMD Video driver is running on a device belonging to a group targeted for this release

[   198.216] (II) AMD Video driver is signed

[   198.217] (II) fglrx(0): pEnt->device->identifier=0x1299a80

[   198.217] (II) fglrx(0): Loading PCS database from /etc/ati/amdpcsdb

[   198.217]

[   198.217] Backtrace:

[   198.217] 0: X (xorg_backtrace+0x36) [0x464d46]

[   198.217] 1: X (0x400000+0x69d99) [0x469d99]

[   198.218] 2: /lib64/libpthread.so.0 (0x7f21a3e8d000+0xefe0) [0x7f21a3e9bfe0]

[   198.218] 3: /usr/lib64/xorg/modules/drivers/fglrx_drv.so (xdl_xs111_atiddxLeaveVT+0x45) [0x7f21a05e3735]

[   198.218] 4: X (xf86DeleteScreen+0x7c) [0x48b03c]

[   198.218] 5: X (InitOutput+0x9f4) [0x484504]

[   198.218] 6: X (0x400000+0x23246) [0x423246]

[   198.218] 7: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f21a2b14735]

[   198.218] 8: X (0x400000+0x236bd) [0x4236bd]

[   198.218]

[   198.219] Segmentation fault at address 0x10

[   198.219]

Fatal server error:

[   198.219] Caught signal 11 (Segmentation fault). Server aborting

[   198.219]

[   198.219]

Please consult the Fedora Project support

         at http://wiki.x.org

for help.

[   198.219] Please also check the log file at "/var/log/Xorg.0.log" for additional information.

[   198.219]

[   198.333] Server terminated with error (1). Closing log file.

0 Likes
41 Replies
nouvo09
Journeyman III

As already said, it is impossible at this time to compile the kernel-modules against the 3.x.x kernels.

One bug as already been fixed but that does not resolve the issue.

0 Likes

What do you mean? I am already using AMD Catalyst 12.4 on Fedora16 with  3.3.2-6.fc16.x86_64  kernel and on Ubuntu 12 (I think it has 3.2.0-24 kernel). There is only a tiny problem at compiling kernel module due to conflicting define in headers and it is possible to avoid it by defining it manually... (or by renaming the conflicting entry). Other than that, everything works perfectly...

See:

http://cvs.rpmfusion.org/viewvc/rpms/catalyst-kmod/F-16/rename_debug.patch?revision=1.1&root=nonfree...

This problem is a totally new problem. I think something is totally broken with 3.3.4 kernel.... kernel module still compiles and installs on the machine with the fix...

0 Likes

The problem is not the kernel, if you already know how to take care/patch it (just commenting out two lines in /usr/src/kernels/`uname -r`/arch/x86/include/asm/uaccess_64.h is enough)

The problem is X.

X.Org X Server 1.12 (shipped as default with Fedora 17) has problems recognizing some ati cards. You'll notice that you won't be able to obtain a decent resolution even without fglrx. You'll notice that, if you boot in "single" mode, you'll have at best segfault if you attempt to create a default xorg.conf via # Xorg -configure or any variant.

The proprietary driver, on the other hand, apparently compiles, but then segfaults/freezes on boot.

First, give a look at

https://fedoraproject.org/wiki/Common_F17_bugs#DKMS_broken_due_to_executable_being_named_dkms.old_in...

Then, perform a distro-synch with --releasever=16 for xorg-x11-server-Xorg xorg-x11-server-common xorg-x11-drv* and eventually other packages like startup-notification (and devel packages if required) and xcb-util (down to .fc15 version)

Give a look with package-cleanup and if everything is fine, reboot, and you'll have your decent resolution back. Re-run the amd installer, and you'll have the working proprietary drivers.

I hope xorg 1.12 will be compatible soon with amd, or the other way round. Six-seven months ago, with the new xorg version, something similar happened.

Hope it helps.

0 Likes

I must have read your reply 6 times and tried to follow the steps you mentioned, but they are just to vague for me to follow.   For those who have stumbled upon these threads that are just trying to find a way to get their laptop, or other type of computer working after upgrading to Fedora 17 here are the steps to follow.

1. If you are not in run level 3, change to run level 3 with the command:

init 3

2. Uninstall your fglrx packages.  e.g.  You can start listing the actual packages, but I thing the following will catch everything:

   yum erase x\*catalyst k\*catalyst

be careful not to uninstall perl packages with catalyst in the name...

3. Install the RPM at: http://rpmfind.net//linux/RPM/mageia/cauldron/x86_64/media/nonfree/release/x11-driver-video-fglrx-8....

  yum install ftp://fr2.rpmfind.net/linux/mageia/distrib/cauldron/x86_64/media/nonfree/release/x11-driver-video-fg...

4. If you have already tried starting X11, remove the module:

rmmod fglrx

5. Hack the module not display that it is for testing only.  You already know that...

updatedb

DRIVER=$(locate fglrx_drv.so)

for x in $(objdump -d $DRIVER|awk '/call/&&/EnableLogo/{print "\\x"$2"\\x"$3"\\x"$4"\\x"$5"\\x"$6}'); do
sed -i "s/$x/\x90\x90\x90\x90\x90/g" $DRIVER
done

6. Now go ahead and test with 'startx'.

7. If everything is working, reboot or switch back to run level 5 with the command:

init 5

Note: I have tried to actually to install the ATI file but others have commented it seems to fail to build under Fedora 17.   The RPM seems to work just fine though...

0 Likes
nouvo09
Journeyman III

Ho

Ok I wrote in the wrong topic:

I work with Fedora 15 and I meaned it is still impossible to compile the kernel module against this release, with a kernel version higher than 2.6.43.3.2 and I think because the newer ones such 2.6.49.x are in fact 3.x.x kernels.

0 Likes

I wouldnt say impossible, it needs a small patch, then it is easily possible

0 Likes

So it's cool.

Where can I find it and how to apply it ?

I think it's not really easy for everybody.

0 Likes

If you are using Fedora, you can just install rpm-fusion repository and instal the drivers from there. It is that easy.

If you want to installl drivers yourself, you can use the patch from the link I provided in my first reply in this thread, or use a search engine and search for how people fixed this problem. There are a pile of forum posts in different forums where the solution is explained.

If you are using Ubuntu, even easier. You can install from additional drivers section:

https://help.ubuntu.com/community/BinaryDriverHowto/ATI

0 Likes
pablrod
Journeyman III

Xorg running with Catalyst 12.6 beta. (HD7970, Fedora 17, Xorg 1.12)

http://support.amd.com/us/kbarticles/Pages/AMDCatalyst126beta.aspx

0 Likes

Works here as well (HD 5970, and HD 6600M).

I didn't even have to comment lines out in uacces_64.h.

0 Likes

No more, Fedora released an update to Fedora 17 which broke the drivers even before they get out of beta status!

This is exactly why I am using Ubuntu now. I just had so many problems with Fedora updates. Every time something brakes down, (by the way, my wifi adapter stopped working in the last update too!).

I used Fedora and Ubuntu side-by-side and I can say with certain amount of confidence that that Ubuntu is much more reliable for workstation usage and also snappier for some reason. It is sad, but Fedora appears to be a real testground nowadays.

PS. I expect F16 to be broken too, since it was following the latest kernel which is used in F17, but I dont dare to upgrade my F16 machine yet. I need it to be working.

0 Likes

That's not true.

I have just updated to F17 and 3.4.xx kernel half an hour ago and the 12-6beta driver runs fine and the kernel module  has been compiled without any issue with dkms.

0 Likes

I actually just updated my F17 system to kernel 3.4.0-1 and now I can't get the 12-6beta driver to install.  Here's my fglrx-install.log:

Check if system has the tools required for installation.

Uninstalling any previously installed drivers.

Unloading radeon module...

Unloading drm module...

Error: Module drm is in use by: ttm drm_kms_helper

[Message] Kernel Module : Trying to install a precompiled kernel module.

[Message] Kernel Module : Precompiled kernel module version mismatched.

[Message] Kernel Module : Found kernel module build environment, generating kernel module now.

AMD kernel module generator version 2.1

doing Makefile based build for kernel 2.6.x and higher

rm -rf *.c *.h *.o *.ko *.a .??* *.symvers

make -C /lib/modules/3.4.0-1.fc17.x86_64/build SUBDIRS=/usr/lib/modules/fglrx/build_mod/2.6.x modules

make[1]: Entering directory `/usr/src/kernels/3.4.0-1.fc17.x86_64'

  CC   /usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o

/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function ‘kasInitExecutionLevels’:

/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:4159:5: error: ‘cpu_possible_map’ undeclared (first use in this function)

/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:4159:5: note: each undeclared identifier is reported only once for each function it appears in

/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:4159:5: warning: left-hand operand of comma expression has no effect [-Wunused-value]

make[2]: *** [/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o] Error 1

make[1]: *** [_module_/usr/lib/modules/fglrx/build_mod/2.6.x] Error 2

make[1]: Leaving directory `/usr/src/kernels/3.4.0-1.fc17.x86_64'

make: *** [kmod_build] Error 2

build failed with return value 2

[Error] Kernel Module : Failed to compile kernel module - please consult readme.

[Reboot] Kernel Module : dracut

Any suggestions to fix this?

0 Likes

I had the same entries, I just couldnt take it out since my wifi stopped working also at the same time. I just booted into Ubuntu instead... I cant be bothered fixing Fedora anymore it lasted 1 week and thats it... fedora is a joke... solution is not to use it, even if you can install the driver today. You can never know what will happen with next updates.

0 Likes

Hi, I followed the procedure under comment #8 of this link:

http://forums.opensuse.org/english/get-technical-help-here/tumbleweed/475575-warning-kernel-3-4-amd-...

Did it under kernel 3.4, catalyst 12.6b, fedora 17, and xorg server 1.12.  Didn't make any changes whatsoever to uaccess_64.h (yes it's a catalyst issue) ...

Sincerely,

HH:-)

Message was edited by: H H  P.S. Yes, it works.  At least for x86_64 arch ...

Message was edited by: H H  After playing around with the changes made, I advise against this procedure.  It has rendered some inconsistence in my system.  Although I reverted back to the radeon (open source) driver, I'm gona reinstall.  I'll wait for the new ATI driver (patience) ...  Sincerely,  HH:-(

Message was edited by: H H

You guys are going to kill me ...

BTW and FWIW, my mistake.  I was testing wine and thought it was the modified catalyst.  I tryed again and yes it's the waqy to go.  Just change those 2 files (as mentioned in the link), re-make (sh make.sh) the fglrx driver and install it.

Sorry for all the editing (newb) ...

HH:-)

0 Likes

One more Time...

With the 3.3 kernel, it was finally possible to compile the kernel module with the AMD 12-6 Beta Catalyst driver.

I updated to the 3.4.0 then to the 3.4.2 and then to the 3.4.3 and one more time it is impossible to setup correctly this driver:

Here the content of an attempt to compile the module with dkms:

vi /var/lib/dkms/fglrx/8.98/build/make.log

DKMS make.log for fglrx-8.98 for kernel 3.4.3-1.fc17.i686.PAE (i686)

mar. juin 26 10:26:16 CEST 2012

AMD kernel module generator version 2.1

make.sh: ligne 390 : [: = : opérateur unaire attendu

doing Makefile based build for kernel 2.6.x and higher

rm -rf *.c *.h *.o *.ko *.a .??* *.symvers

make -C /lib/modules/3.4.3-1.fc17.i686.PAE/build SUBDIRS=/var/lib/dkms/fglrx/8.98/build/2.6.x modules

make[1] : on entre dans le répertoire « /usr/src/kernels/3.4.3-1.fc17.i686.PAE »

  CC   /var/lib/dkms/fglrx/8.98/build/2.6.x/firegl_public.o

/var/lib/dkms/fglrx/8.98/build/2.6.x/firegl_public.c: In function ‘kasInitExecutionLevels’:

/var/lib/dkms/fglrx/8.98/build/2.6.x/firegl_public.c:4159:5: erreur: ‘cpu_possible_map’ undeclared (first use in this function)

/var/lib/dkms/fglrx/8.98/build/2.6.x/firegl_public.c:4159:5: note: each undeclared identifier is reported only once for each function it appears in

/var/lib/dkms/fglrx/8.98/build/2.6.x/firegl_public.c:4159:5: attention : l'opérande à gauche de la virgule n'a pas d'effet [-Wunused-value]

/var/lib/dkms/fglrx/8.98/build/2.6.x/firegl_public.c: In function ‘KCL_fpu_begin’:

/var/lib/dkms/fglrx/8.98/build/2.6.x/firegl_public.c:5833:9: erreur: implicit declaration of function ‘__save_init_fpu’ [-Werror=implicit-function-declaration]

cc1: some warnings being treated as errors

make[2]: *** [/var/lib/dkms/fglrx/8.98/build/2.6.x/firegl_public.o] Erreur 1

make[1]: *** [_module_/var/lib/dkms/fglrx/8.98/build/2.6.x] Erreur 2

make[1] : on quitte le répertoire « /usr/src/kernels/3.4.3-1.fc17.i686.PAE »

make: *** [kmod_build] Erreur 2

build failed with return value 2

Anything to do or to try ?

Thx

0 Likes

You know, initially when things like this happened I got angry at AMD for their driver's not working.  But nowadays since it happens with almost every kernel update I blame the kernel maintainers for constantly changing things in a way that breaks existing drivers.  Is it really that difficult to maintain some consistency and predictability?  This has made me block updates to kernels and all other packages (mesa, x11, etc.) that may potentially break my system, although may also leave my system vulnerable to exploits that have been patched.  If CentOS supported my AMD powered notebook's wireless I would use it (their kernel is too old), and for whatever reason OpenSUSE won't even boot to install, so I keep using Fedora (whose kernel is too new).

0 Likes

Give a look on the centos.org forum. I believe there is a solution for your issue.

0 Likes

Did you try Ubuntu? Honestly I made a bug report to fedora everytime the kernel broke the drivers. Everytime they replied that it is the responsibility of the driver maker to fix it. I suggested them that there is only 2-3 large GPU suppliers, cant they just test these stuff before pushing to production use! But they dont seem to think that it is necessary.... If AMD is suppose to fix this, I wonder, how will AMD know beforehand that they will push new incompatible kernel with an update. Does Fedora even inform AMD about it? (and well those updates of fedora often broke nvidia drivers too!)

I think Ubuntu might be testing compatibility before updates... I also feel more comfortable with Fedora but I came to the conclusion that I have no other choice if I want to save several hours of fixing, bug reporting etc. everytime there is an update to Fedora...

http://www.ubuntu.com/certification/catalog/

0 Likes

I tried Ubuntu, but frankly I didn't like it and prefer Fedora since I've been using it for nearly ten years now.  CentOS is generally my next choice, but it doesn't have as many repositories for things I like and packages are much older.

0 Likes

settle wrote:

I tried Ubuntu, but frankly I didn't like it and prefer Fedora since I've been using it for nearly ten years now.  CentOS is generally my next choice, but it doesn't have as many repositories for things I like and packages are much older.

Hmm Ubuntu is only 8 yeards old. But anyway, it is a very long time, you might want to re-test it. I am not sure if I could get away if I said "I used windows 3.1 and I didnt like it so I wont use windows 7"   Things change in time...  I would at least give it a chance (I mean, I did it and I was not disappointed so that is why I am suggesting it...)

0 Likes

Really, it unrealistic to assume kernel developers will even allow a proprietary binary blob on their computers.  It interfaces directly with the kernel, so really it could do absolutely anything...   Properly, it is the downstream users responsibility to test there stuff with the kernel.  Linux kernel source is open source, and available long before it gets added to a distribution.   Generally, what people do when they want a stable interface for the kernel, is the write one and submit it as open source.   So long as they also write a useful open source application that uses it, eventually it gets pulled into the kernel and maintained as part of the kernel.   Frankly, what all GPU vendors should be doing, is making sure there are solid open source video drivers with appropriate kernel drivers, and sufficient hooks for them to add their proprietary stuff to.   Then everyone wins.  Everyone gets usable video drivers, and the power users that need something that the GPU vendors can't release as open source have a stable packages they can install, regardless of kernel build.

But frankly, Windows is still king.  Linux is just an afterthought when it comes to video cards.  As long as that is true, we'll just have to be grateful with whatever scraps are thrown our way.

0 Likes

It is irrelevant if the kernel is open source or not. The hardware manufacturer can not simply check if their driver is working after every commit to kernel sources. It would be waste of time to make fixes for transient changes.

The whole thing works fine with Windows. I never saw an update to Windows breaking an existing driver myself. So maybe Linux must become closed source to fix the issue right? (if we apply the same logic that you used).

All things considered, closed source systems are dominant in market and used much more because they actually work better when everybody is not trying to implement what they think is best. There is like 100 different Linux distributions with different sets of problems and if the driver was open source, I am pretty sure eventually there would be 10 different drivers to choose from. I am not sure if it is beneficial for anybody if that happens. There is an open source driver, you can use it if you think open source is much better eh? Can you imagine how nice Linux would be if there was only one Linux version which was actually working? now the effort is divided in several versions...(and shore it is good to have choices,  one has to consider the overhead of having too many choices)

I think the fault is in Linux (especially Fedora) developers. They have to determine which kernel they will release next and freeze it. Then test it and if the drivers do not function, report it to hardware manufacturers. Then give ample time for the manufacturer to release a fix. Then release the kernel to general public. The whole process of Fedora seems quite random.

0 Likes

Fedora follows a VERY predictable schedule.   The kernel version for the next release is mapped fairly early on in the planning cycle.   There is a 6 month lead time, during which anyone can access the upcoming release via rawhide.  So really by the time a release happens the changes are six months old.  Once a release happens, there are far more updates that I'm am really comfortable with, including kernel updates.   I have never seen one of those post release updates break something major like a video driver though.  Usually to be included in an update there needs to be a major problem being address, such as a security alert.   I have had a few times when the updates have broken wifi drivers and such when used for fringe type cases.   In all cases, the developers have bent over backwards to get a fix or a workaround ASAP.

I don't really know what kind of schedule Ubuntu follows, so I can't comment on it.  I used to use Ubuntu, but I got discouraged one day when I upgraded open office on my mother-inlaw's computer, and it uninstalled x11.   Previously, I had other problems with Ubuntu, always with the update or upgrade processes.   My general conclusion is Ubuntu works great, if you do not want to update it.   But then, almost any distribution works great under those conditions.

Bill

0 Likes

docbill wrote:

Fedora follows a VERY predictable schedule.   

Can you just tell how to see this very predictable schedule?

docbill wrote:

I got discouraged one day when I upgraded open office on my mother-inlaw's computer, and it uninstalled x11.   Previously, I had other problems with Ubuntu, always with the update or upgrade processes.   My general conclusion is Ubuntu works great, if you do not want to update it.   But then, almost any distribution works great under those conditions.

Did you find out if it was because of something you did or a bug in Ubuntu? I Google'd a bit and could not find a single entry where OO update removing X11 on Ubuntu   In either case I believe you, but the point was Ubuntu working better than Fedora, not Ubuntu working 100% perfectly. At least I had no problems on several Ubuntu systems with updates so far, while systems running Fedora nearly always had problems, and major problems.

You have to consider that Ubuntu guys appear to be actually trying to improve user experience. Ubuntu seems to be all about that, so maybe they have significantly improved the updates. I would definitely give another try...

Today, in my opnioun, Ubuntu updates just work better than Fedora. Since I have been using both Ubuntu and Fedora simultaneously. I had to bug report major problems (such as logins not functioning due to NIS bugs they introduced, or RAID failures due to bugs they introduced)  to Fedora which were fixed in one update and broken again on next update (same exact problem comes back) and had to bug report again and again few times back to back... But in Ubuntu, things seem to be working fine, while there were small minor problems where I had to add a user to a group manually to run virtualbox etc. Overall, my vote goes to Ubuntu. (like I said before, it was a hard decision, I am more familiar with CentOS/Fedora so my preferences go towards them, but still..)

0 Likes

http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle

http://fedoraproject.org/wiki/Releases/18/Schedule

To ubuntu's credit, the limitation of not being able to upgrade major components as updates, is well known.  There GUI installer at the time did not even list open office updates as available.  I had to drop to the command line, to install them.  That was nearly 5 years ago.   I would not be surprised if by now they have even updated the command line tools to keep you from shooting yourself in the foot.   That be said, there are equally many ways to shoot yourself in the foot with Fedora.  For example:

yum erase $(package-cleanup --orphans)

after an upgrade will often leave you a system missing critical components needed for reboot.   The only saving grace is, I would expect an erase operation to be dangerous.  I would not expect an update operation to be equally dangerous.

Really, if you are using Linux, and it works for you I'm happy,  regardless of distribution.   I still think however, vendors providing proprietary drivers do have a responsibility to keep there drivers working with current kernels.   If they don't have time to keep on top of the kernel dev branch, so they work with all kernel builds, then they at least need to keep on top of the two or three major distributions dev branches, so they can work with what will be used in the major releases.

0 Likes

docbill wrote:

Really, if you are using Linux, and it works for you I'm happy,  regardless of distribution.   I still think however, vendors providing proprietary drivers do have a responsibility to keep there drivers working with current kernels.   If they don't have time to keep on top of the kernel dev branch, so they work with all kernel builds, then they at least need to keep on top of the two or three major distributions dev branches, so they can work with what will be used in the major releases.

From http://devgurus.amd.com/message/1281581#1281581

Kristen Carney wrote:

Per the Catalyst QA team, Fedora is considered a Tier 2 distro -- which means it's not QA'd & AMD may release updates to support the distro in the future.

OpenSuse & Red Hat are Tier I distros.

Too bad OpenSUSE won't install and CentOS doesn't support my notebook's wireless device.

0 Likes

settle wrote:

Too bad OpenSUSE won't install and CentOS doesn't support my notebook's wireless device.

I am waiting to hear about what is wrong with Ubuntu's recent versions? You can boot it from DVD or USB stick (my favourite) to test if all the devices work fine, you might have to enable additional drivers..., and since you said you are on a notebook. I have to say Ubuntu runs much cooler on notebooks (tested on an amd e-450 with dual boot between fedora and ubuntu).

0 Likes

I've tried Ubuntu several times over the years, as recently as 12.04 LTS, but I never liked it.  I must admit they seem to have good support out of the box and documentation, similar to OpenSUSE, but I don't have the time to learn a third package management system and all the subtleties of yet another Linux distribution.

Personally, my best solution is to stick with Fedora and just stop updating things that aren't broken (for me).

0 Likes

I asked how do I know which kernel and when it will be released for F16 or F17 and there is no info that I can see in those links. You are not able to back up your claim...

docbill wrote:

http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle

http://fedoraproject.org/wiki/Releases/18/Schedule

You said Fedora is following a very predictible schedule. Yet, after checking the links you provided, I cant tell what will be the next kernel version and when it will be updated for Fedora 16 or 17. It is totally random. Somebody will push it whenever he feels like it.

Even in detailed development schedule of Fedora 18, there is like 15 days between last kernel update and release. Yet, we dont know which kernel will be used.

How do you suggest that a hardware manufacturer actually follow and test their drivers before release of Fedora when this is the case? It is not enough that you put a list of things todo and dates, they should actually be useful...eh?

Fedora in my opinion appear to be simply working by 1st brake it, 2nd fix it schedule...

I dont know much about Ubuntu, but they appear to be working harder to keep things working at first place:

http://blog.canonical.com/2012/03/07/improving-hardware-support-in-ubuntu/

I forgot to mention that Ubuntu's laptop support is also much better than Fedora's as far as I can see (I remembered it after reading the blog above...). It correctly configures laptop mode support, and power saving features whereas fedora seems to be doing nothing in that area

0 Likes

Details of each package is not going to be in the high level lists.  Usually kernel version is important enough it will be mentioned in each of the respective go/no go meeting notes.   Really though, all developers need to concern themselves with is the the freeze date.  e.g. At minimum a vendor should test/update their proprietary code after the beta freeze.   Any updates after that, will be minor to address specific bugs.  (Possibly the ones that vendor submits.)   I would think it would be wise to also test as the alpha freeze, so they know if any major change will be needed.

0 Likes

docbill wrote:

Details of each package is not going to be in the high level lists.  Usually kernel version is important enough it will be mentioned in each of the respective go/no go meeting notes.   Really though, all developers need to concern themselves with is the the freeze date.  e.g. At minimum a vendor should test/update their proprietary code after the beta freeze.   Any updates after that, will be minor to address specific bugs.  (Possibly the ones that vendor submits.)   I would think it would be wise to also test as the alpha freeze, so they know if any major change will be needed.

I am not sure if my question was not clear. What I want to know is which kernel version is next for F16 and F17, and when it will be pushed in updates. So where exactly(a direct link perhaps?) this information is shown? As I mentioned earlier. I couldnt find this information in the links you have provided. I am not sure how it will help anybody to know that there is some obscure meeting note which is nowhere to be found.

Even easier, lets look at a concrete example. This latest update to kernel which broke the drivers again, when was it pushed and where is the note which is showing that it will be pushed? I would think that to be able to blame AMD or Nvidia for the failure, it should at least be mentioned in a document 2+ months before pushing it, not in 2 weeks advance which would be insufficient to test anything, wouldnt you agree?

0 Likes

docbill wrote:

Really, it unrealistic to assume kernel developers will even allow a proprietary binary blob on their computers.  It interfaces directly with the kernel, so really it could do absolutely anything...

I don't assume they would use proprietary software, but they shouldn't obstruct others from using it.

docbill wrote:

Frankly, what all GPU vendors should be doing, is making sure there are solid open source video drivers with appropriate kernel drivers, and sufficient hooks for them to add their proprietary stuff to.   Then everyone wins.  Everyone gets usable video drivers, and the power users that need something that the GPU vendors can't release as open source have a stable packages they can install, regardless of kernel build.

By your argument, those kernel developers would be unlikely to even allow hooks to proprietary stuff.  Plus, at what point are the open source drivers solid enough, and hooks acceptable?  It's arbitrary, although Fedora has taken a clear stance requiring everything they touch to be FOSS.

And sure, in the short-term it would be great for consumers if everything was FOSS, but I don't assume that model works for every everyone.  If a business tries to follow the FOSS model, but fails to make sufficient profit to compete against a business following the proprietary model, then that doesn't benefit consumers in the long-term.

To each his own.

0 Likes

I know that you want to fix the current kernel but is it worth the trouble, downgrade the kernel to a working version and change yum config so it wont upgrade kernel anymore. What functionality you need from newer kernel anyway? Another solution is using Ubuntu which seems to be more smart in providing working updates of any package...

0 Likes

It is what I do. I have changed the "installonly" value to 8 in yum.conf. I let the system do the updates but I still continue to work with the 3.3 kernel.

In fact I installed Fedora 17 just for testing. I think there are too problems and I continue with my F 15.

Thans you anyway

0 Likes

I'd like to differ. I see your trying to compile it for a PAE kernel

(sorry I can't help you there, I did it for a Fedora 17 x86_64 build).

If I'm not mistaken, it was working for x86, so it should work for a

PAE. At first, when got the kernel 3.4.3 update didn't work right away.

There was an xorgserverXorg* package that came afterwards (maybe that

was the trick).

I suggest you do "yum update" and try again ...

0 Likes

Thanks

I'll try it when  I am back from holidays. Actually i'm on my laptop with Centos !

0 Likes

So I'm back and I have juste updated my Fedora 17 with the new 3.5 kernel.

And there is nothing new, things continue to not work ...

Wait and see

0 Likes

Im having similar problem.

Trying to install using Amd official driver installer 12.8.

The installer informs me at the end that the install had errors. I list the errors below:

Check if system has the tools required for installation.

Uninstalling any previously installed drivers.

[Message] Kernel Module : Trying to install a precompiled kernel module.

[Message] Kernel Module : Precompiled kernel module version mismatched.

[Message] Kernel Module : Found kernel module build environment, generating kernel module now.

AMD kernel module generator version 2.1

doing Makefile based build for kernel 2.6.x and higher

rm -rf *.c *.h *.o *.ko *.a .??* *.symvers

make -C /lib/modules/3.5.3-1.fc17.x86_64/build SUBDIRS=/usr/lib/modules/fglrx/build_mod/2.6.x modules

make[1]: Entering directory `/usr/src/kernels/3.5.3-1.fc17.x86_64'

  CC   /usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o

/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c: In function 'KCL_MEM_AllocLinearAddrInterval':

/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:2131:5: error: implicit declaration of function 'do_mmap' [-Werror=implicit-function-declaration]

/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.c:2131:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]

cc1: some warnings being treated as errors

make[2]: *** [/usr/lib/modules/fglrx/build_mod/2.6.x/firegl_public.o] Error 1

make[1]: *** [_module_/usr/lib/modules/fglrx/build_mod/2.6.x] Error 2

make[1]: Leaving directory `/usr/src/kernels/3.5.3-1.fc17.x86_64'

make: *** [kmod_build] Error 2

build failed with return value 2

[Error] Kernel Module : Failed to compile kernel module - please consult readme.

[Reboot] Kernel Module : dracut

My kernel is 3.5.3-1.fc17.x86_64 and my kernel-headers and kernel-devel are uptodate!

Any help will be welcome!

0 Likes