FYI, I just wanted to acknowledge that you're not the only one with such a problem. A couple of days ago, after running "
yum upgrade", which upgraded the kernel from
3.10.0-327.36.3 to
3.10.0-514.2.2 (and "
rpm --query centos-release" showed
centos-release-7-3.1611.el7.centos.x86_64), I encountered blank screens on a Xfce 4-monitor system with dual HD 6450 cards. When I selected the previous kernel version in the boot menu, everything ran fine.
Running "
Xorg -version" on both kernels showed that they use the exact same version of X11 server (namely
xorg-x11-server 1.17.2-22.el7). Therefore, it appeared the X11 server was not the culprit, and downgrading it probably will not solve your problem.
As I documented further below, looking at the xserver log files "
/var/log/Xorg.0.log" and looking for entries in the boot log with "
dmesg | grep fglrx" showed that the fglrx driver did not load in the latest kernel version (failing to create "
/proc/ati" and its contents). This hint led me to an
entry in the Elrepo bug tracking system, where developer "
wolfy" suggested to try the files from
http://wdl.lug.ro/fglrx. I downloaded and installed these files (date stamped 30-Dec-2016 09:33 at the time of this post), which immediately solved the problem upon reboot for me. So, I'd say my problem (and hopefully yours, too) seems to be just a "driver out of sync" problem and a matter of patience until the drivers percolate through development and early testing into elrepo-testing (which at the time of this posting contained
fglrx-x11-drv-15.12-4.el7.elrepo.x86_64.rpm dated Aug-2016) and then the main distribution repos that yum catches up with.
Here's how I installed the files manually (via ssh console from another system, logged in as user, then using
su or
sudo for executing the commands with root privileges):
Code: Select all
cd Downloads
wget http://wdl.lug.ro/fglrx/fglrx-x11-drv-15.12-5.el7.elrepo.x86_64.rpm
wget http://wdl.lug.ro/fglrx/kmod-fglrx-15.12-5.el7.elrepo.x86_64.rpm
rpm -Uvh kmod-fglrx-15.12-5.el7.elrepo.x86_64.rpm
rpm -Uvh fglrx-x11-drv-15.12-5.el7.elrepo.x86_64.rpm
reboot
Note added 19-Jan-2107: I just noticed today that the driver issue has been reported last week in the Elrepo bug tracker
here. While the driver fixes problems with existing setups, please note that
aticonfig may not be working yet for new or first installs. wolfy explained the problem was caused by a "library that was removed from the distro" and that
aticonfig was the reason why the drivers have not yet been updated in elrepo and elrepo-testing. So, I'm guessing it will be just a matter of time until all problems will be completely resolved.
I hope this helps.
A big 'Thank You!' to all the developers and volunteers whose work helps keeping our systems alive!!!
=================================================================
And now, as an afterthought, for the sake of my own laziness and not having to remember where to find my notes, and for the benefit of others who may need to troubleshoot their own systems, here's a description of how a tracked down the problem (which required booting into the current and previous kernel several times to find differences).
1. Check Xorg version
On kernel
3.10.0-327.36.3 (which runs OK):
Code: Select all
[root@mysystem Downloads]# Xorg -version
X.Org X Server 1.17.2
Release Date: 2015-06-16
X Protocol Version 11, Revision 0
Build Operating System: 2.6.32-573.18.1.el6.x86_64
Current Operating System: Linux mysystem.mydomain.com 3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0-327.36.3.el7.x86_64 root=/dev/mapper/centos-root ro rd.lvm.lv=centos/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=centos/root crashkernel=auto vconsole.keymap=us rhgb quiet LANG=en_US.UTF-8 radeon.modeset=0 rd.driver.blacklist=radeon
Build Date: 06 November 2016 12:43:39AM
Build ID: xorg-x11-server 1.17.2-22.el7
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[root@mysystem Downloads]#
On kernel
3.10.0-514.2.2 (which fails):
Code: Select all
[root@mysystem Downloads]# Xorg -version
X.Org X Server 1.17.2
Release Date: 2015-06-16
X Protocol Version 11, Revision 0
Build Operating System: 2.6.32-573.18.1.el6.x86_64
Current Operating System: Linux mysystem.mydomain.com 3.10.0-514.2.2.el7.x86_64 #1 SMP Tue Dec 6 23:06:41 UTC 2016 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0-514.2.2.el7.x86_64 root=/dev/mapper/centos-root ro rd.lvm.lv=centos/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=centos/root crashkernel=auto vconsole.keymap=us rhgb quiet LANG=en_US.UTF-8 radeon.modeset=0 rd.driver.blacklist=radeon
Build Date: 06 November 2016 12:43:39AM
Build ID: xorg-x11-server 1.17.2-22.el7
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[root@mysystem Downloads]#
Result: Exact same version. Hence X11 is not the culprit.
2. Check and and see if server starts
Looking the end of the log file xserver log file "
/var/log/Xorg.0.log" shows that X11 fails under
3.10.0-514.2.2 :
Code: Select all
[root@mysystem Downloads]# tail -14 /var/log/Xorg.0.log
[ 24.118] (EE)
[ 24.118] (EE) Segmentation fault at address 0x22b0
[ 24.118] (EE)
Fatal server error:
[ 24.118] (EE) Caught signal 11 (Segmentation fault). Server aborting
[ 24.118] (EE)
[ 24.118] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 24.118] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 24.118] (EE)
[ 24.119] (EE) fglrx(0): firegl_SetSuspendResumeState FAILED -9.
[ 24.414] (EE) fglrx(1): firegl_SetSuspendResumeState FAILED -9.
Result: Ah, not good.
3. Check where differences start
Scrolling back in the log files shows, by comparison, where and how the same version of the X11 server fails in one instance but not the other, after loading
/usr/lib64/xorg/modules/linux/libfglrxdrm.so. Specifically, note the difference between “
ukiDynamicMajor: found major device number 248” and “
ukiDynamicMajor: failed to open /proc/ati/major” about 11 lines from the top.
On kernel
3.10.0-327.36.3 (which runs OK):
Code: Select all
(II) Loading /usr/lib64/xorg/modules/linux/libfglrxdrm.so
[ 16.329] (II) Module fglrxdrm: vendor="FireGL - AMD Technologies Inc."
[ 16.329] compiled for 1.4.99.906, module version = 15.30.3
[ 16.329] (II) AMD Proprietary Linux Driver Version Identifier:15.30.3
[ 16.329] (II) AMD Proprietary Linux Driver Release Identifier: UNSUPPORTED-15.302
[ 16.329] (II) AMD Proprietary Linux Driver Build Date: Dec 17 2015 02:43:16
[ 16.329] (++) using VT number 1
[ 16.331] (WW) Falling back to old probe method for fglrx
[ 16.368] (II) Loading PCS database from /etc/ati/amdpcsdb /etc/ati/amdpcsdb.default
[ 16.377] ukiDynamicMajor: found major device number 248
[ 16.377] ukiDynamicMajor: found major device number 248
[ 16.377] ukiOpenByBusid: Searching for BusID PCI:1:0:0
[ 16.377] ukiOpenDevice: node name is /dev/ati/card0
[ 16.377] ukiOpenDevice: open result is 9, (OK)
[ 16.549] ukiOpenByBusid: ukiOpenMinor returns 9
[ 16.549] ukiOpenByBusid: ukiGetBusid reports PCI:1:0:0
[ 16.551] ukiDynamicMajor: found major device number 248
[ 16.552] ukiDynamicMajor: found major device number 248
[ 16.552] ukiOpenByBusid: Searching for BusID PCI:1:0:0
[ 16.552] ukiOpenDevice: node name is /dev/ati/card0
[ 16.552] ukiOpenDevice: open result is 9, (OK)
[ 16.552] ukiOpenByBusid: ukiOpenMinor returns 9
[ 16.552] ukiOpenByBusid: ukiGetBusid reports PCI:1:0:0
[ 16.552] ukiDynamicMajor: found major device number 248
[ 16.552] ukiDynamicMajor: found major device number 248
[ 16.552] ukiOpenByBusid: Searching for BusID PCI:4:0:0
[ 16.552] ukiOpenDevice: node name is /dev/ati/card0
[ 16.552] ukiOpenDevice: open result is 9, (OK)
[ 16.552] ukiOpenByBusid: ukiOpenMinor returns 9
[ 16.552] ukiOpenByBusid: ukiGetBusid reports PCI:1:0:0
[ 16.552] ukiOpenDevice: node name is /dev/ati/card1
[ 16.885] ukiOpenDevice: open result is 9, (OK)
[ 16.885] ukiOpenByBusid: ukiOpenMinor returns 9
[ 16.885] ukiOpenByBusid: ukiGetBusid reports PCI:4:0:0
[ 16.886] ukiDynamicMajor: found major device number 248
[ 16.886] ukiDynamicMajor: found major device number 248
[ 16.886] ukiOpenByBusid: Searching for BusID PCI:4:0:0
[ 16.886] ukiOpenDevice: node name is /dev/ati/card0
[ 16.886] ukiOpenDevice: open result is 9, (OK)
[ 16.886] ukiOpenByBusid: ukiOpenMinor returns 9
[ 16.886] ukiOpenByBusid: ukiGetBusid reports PCI:1:0:0
[ 16.886] ukiOpenDevice: node name is /dev/ati/card1
[ 16.886] ukiOpenDevice: open result is 9, (OK)
[ 16.886] ukiOpenByBusid: ukiOpenMinor returns 9
[ 16.886] ukiOpenByBusid: ukiGetBusid reports PCI:4:0:0
[ 16.891] (--) Chipset Supported AMD Graphics Processor (0x6779) found
[ 16.891] (--) Chipset Supported AMD Graphics Processor (0x6779) found
[ 16.891] (--) Chipset Supported AMD Graphics Processor (0x6779) found
[ 16.891] (--) Chipset Supported AMD Graphics Processor (0x6779) found
On kernel
3.10.0-514.2.2 (which fails):
Code: Select all
[ 23.267] (II) Loading /usr/lib64/xorg/modules/linux/libfglrxdrm.so
[ 23.267] (II) Module fglrxdrm: vendor="FireGL - AMD Technologies Inc."
[ 23.267] compiled for 1.4.99.906, module version = 15.30.3
[ 23.267] (II) AMD Proprietary Linux Driver Version Identifier:15.30.3
[ 23.267] (II) AMD Proprietary Linux Driver Release Identifier: UNSUPPORTED-15.302
[ 23.267] (II) AMD Proprietary Linux Driver Build Date: Dec 17 2015 02:43:16
[ 23.267] (++) using VT number 1
[ 23.267] (WW) Falling back to old probe method for fglrx
[ 23.298] (II) Loading PCS database from /etc/ati/amdpcsdb /etc/ati/amdpcsdb.default
[ 23.303] ukiDynamicMajor: failed to open /proc/ati/major
[ 23.303] ukiDynamicMajor: failed to open /proc/ati/major
[ 23.303] ukiDynamicMajor: failed to open /proc/ati/major
[ 23.303] ukiDynamicMajor: failed to open /proc/ati/major
[ 23.303] ukiDynamicMajor: failed to open /proc/ati/major
[ 23.303] ukiDynamicMajor: failed to open /proc/ati/major
[ 23.303] ukiDynamicMajor: failed to open /proc/ati/major
[ 23.303] ukiDynamicMajor: failed to open /proc/ati/major
[ 23.307] (--) Chipset Supported AMD Graphics Processor (0x6779) found
[ 23.307] (--) Chipset Supported AMD Graphics Processor (0x6779) found
[ 23.307] (--) Chipset Supported AMD Graphics Processor (0x6779) found
[ 23.307] (--) Chipset Supported AMD Graphics Processor (0x6779) found
Result: "failed to open /proc/ati/major" gives a hint.
4. Check for presence of /proc/ati
Doing an "
ls -l /proc" shows that no
/proc/ati (and therefore also no
/proc/ati/major) existed at all under
3.10.0-514.2.2:
Code: Select all
[root@mysystem Downloads]# ls -l /proc
– snip –
dr-xr-xr-x. 9 root root 0 Jan 14 13:52 99
dr-xr-xr-x. 2 root root 0 Jan 14 17:24 acpi
dr-xr-xr-x. 7 root root 0 Jan 14 17:24 asound
-r--r--r--. 1 root root 0 Jan 14 17:24 buddyinfo
– snip –
...while under
3.10.0-327.36.3, the following
/proc/ati/major structure exists:
Code: Select all
[root@mysystem Downloads]# ls -l /proc/ati/
total 0
dr-xr-xr-x. 2 root root 0 Jan 14 18:08 0
dr-xr-xr-x. 2 root root 0 Jan 14 18:08 1
-r--r--r--. 1 root root 0 Jan 14 18:08 debug
-r--r--r--. 1 root root 0 Jan 14 18:08 major
[root@mysystem Downloads]#
5. Check boot log entries for "fglrx"
The command “
dmesg | grep fglrx” produces a number of entries on
3.10.0-327.36.3, but there are no (zero) entries on
3.10.0-514.2.2. This is further evidence that the driver does not load at boot time under
3.10.0-514.2.2.
Hence, most likely the driver is the culprit.
Since AMD stopped official support for HD 6xxx+ cards in Nov-2015 (see
here), I briefly considered compiling AMD drivers based on what is described for FC23 on this page
here, but luckily found somebody else already did that in the solution described above.
Undoubtedly, users with AMD HD cards will be in a world of hurt going forward, and therefore I'm considering upgrading my graphics card to a card that takes advantage of using AMD's latest supported drivers (currently 16.50, see list of supported cards about halfway down the page
here -- but there's no guarantee AMD will release updated drivers in time, either). However, I'm lazy and cheap, and it would break my heart having to rip apart a system and ditch hardware that works perfectly well.