uname -a Linux 3820TG 4.4.6-gentoo #4 SMP Mon Sep 19 03:38:26 CST 2016 x86_64 Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz GenuineIntel GNU/Linux equery l xorg-server [IP-] [ ] x11-base/xorg-server-1.17.4:0/1.17.4 equery l ati-drivers [IP-] [ ] x11-drivers/ati-drivers-15.9-r1:1 equery l xorg-drivers [IP-] [ ] x11-base/xorg-drivers-1.17:0 It's reproducible that open a black screen with a flickering underscore when /etc/init.d/xdm starts using radeon driver. Here is /var/log/Xorg.0.log https://bpaste.net/show/3d79333cd7a9 Here is /var/log/sddm.log https://bpaste.net/show/a5603d7ba3ac Here is /etc/X11/xorg.conf Section "ServerLayout" Identifier "Default Layout" Option "ignoreABI" "1" EndSection Section "Monitor" Identifier "Default Monitor" EndSection Section "Device" Identifier "Radeon" Driver "radeon" #Option "AccelMethod" "glamor" #Option "DRI" "2" #Option "TearFree" "on" BusID "PCI:02:00:0" EndSection Section "Screen" Identifier "Default Screen" Monitor "Default Monitor" Device "Radeon" EndSection Here is dmesg https://bpaste.net/show/f4f499696294 Here is lsmod https://bpaste.net/show/dd851eee28b5 Here is lspci | grep VGA https://bpaste.net/show/2c203259714e Here is /usr/src/linux/.config https://bpaste.net/show/81e880c35864
Please attach your dmesg, etc. rather than providing links to be sure the links don't break, etc. Please also give a clear description of what problem you are seeing.
Created attachment 126618 [details] var/log/Xorg.0.log
Created attachment 126619 [details] /var/log/sddm.log
Created attachment 126620 [details] dmesg
Created attachment 126621 [details] lsmod
Created attachment 126622 [details] lspci | grep VGA
Created attachment 126623 [details] /usr/src/linux/.config
Created attachment 126624 [details] dmesg
Created attachment 126625 [details] lsmod
After /etc/init.d/xdm start, it shows 'sddm setting' at tty1, a black screen shows, and back to tty1.
dmesg shows that the fglrx kernel module gets loaded. If you want to use the open source radeon drivers, you have to completely remove all traces of fglrx. If that doesn't help, please attach a full Xorg log file corresponding to the failure. You may need to look at Xorg.*.log.old .
Created attachment 126650 [details] dmesg without fglrx
Created attachment 126651 [details] xorg.0.log without fglrx
Created attachment 126652 [details] sddm.log without fglrx
(In reply to Michel Dänzer from comment #11) > dmesg shows that the fglrx kernel module gets loaded. If you want to use the > open source radeon drivers, you have to completely remove all traces of > fglrx. > > If that doesn't help, please attach a full Xorg log file corresponding to > the failure. You may need to look at Xorg.*.log.old . I already remove all fglrx modules, but situation is the same. log files are attached.
From the Xorg log file: [ 129.365] (WW) Warning, couldn't open module radeon [ 129.365] (II) UnloadModule: "radeon" [ 129.365] (II) Unloading radeon [ 129.365] (EE) Failed to load module "radeon" (module does not exist, 0) [ 129.365] (EE) No drivers available. It looks like /etc/X11/xorg.conf forces the radeon driver (xf86-video-ati), but that isn't installed.
Created attachment 126691 [details] /var/log/Xorg.0.log after emerge xf86-video-ati
(In reply to Michel Dänzer from comment #16) > From the Xorg log file: > > [ 129.365] (WW) Warning, couldn't open module radeon > [ 129.365] (II) UnloadModule: "radeon" > [ 129.365] (II) Unloading radeon > [ 129.365] (EE) Failed to load module "radeon" (module does not exist, 0) > [ 129.365] (EE) No drivers available. > > It looks like /etc/X11/xorg.conf forces the radeon driver (xf86-video-ati), > but that isn't installed. Yes, it isn't there, so I emerge xf86-video-ati again. After /etc/init.d/xdm start, screen shows whole black and no jump back to tty1. (I have to switch it to console manually.) Another thing that warned during emerge xf86-video-ati process was portage tree suggested that I should not set the below CONFIG_DRM_RADEON_UMS=y CONFIG_FB_RADEON=m Does this matter?
(In reply to Yu Tzu Wu from comment #17) > /var/log/Xorg.0.log after emerge xf86-video-ati Assuming the Xorg process still existed when you grabbed the log file, it looks like Xorg starts up normally and that you could successfully switch away from its VT to console. Note that a black screen is Xorg's default startup behaviour, so unless the problem doesn't happen e.g. using the modesetting driver instead of radeon, it looks like the problem is more likely with sddm or something it uses. (In reply to Yu Tzu Wu from comment #18) > Another thing that warned during emerge xf86-video-ati process was > portage tree suggested that I should not set the below > CONFIG_DRM_RADEON_UMS=y > CONFIG_FB_RADEON=m > Does this matter? No.
Created attachment 126699 [details] /var/log/sddm.log when /var/Xorg.0.log no Errors
(In reply to Michel Dänzer from comment #19) > Note that a black screen is Xorg's default startup behaviour, so unless the > problem doesn't happen e.g. using the modesetting driver instead of radeon, > it looks like the problem is more likely with sddm or something it uses. Yes. There is no error in Xorg.0.log. But errors appear in sddm.log, [23:35:44.594] (II) HELPER: [PAM] Starting... [23:35:44.595] (II) HELPER: [PAM] Authenticating... [23:35:44.595] (II) HELPER: [PAM] returning. [23:35:44.595] (EE) HELPER: Auth: SafeDataStream: Could not write all stored data [23:35:44.595] (WW) HELPER: QIODevice::read (QTcpSocket): device not open [23:35:44.595] (EE) HELPER: Received a wrong opcode instead of AUTHENTICATED: 0 [23:35:44.595] (EE) HELPER: Unable to run user session: unknown session type [23:35:44.595] (EE) HELPER: Auth: SafeDataStream: Could not write all stored data [23:35:44.595] (WW) HELPER: QIODevice::read (QTcpSocket): device not open [23:35:44.595] (EE) HELPER: Received a wrong opcode instead of SESSION_STATUS: 0 [23:35:44.595] (II) HELPER: [PAM] Ended. I should go to report a bug to sddm. Thank you very much!
Assuming this was an SDDM issue.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.