Regardless of the fact that I use systemd, this needs to be looked into. As such, please don't hate on me but help me. ----------------------- I'd like to be able to use startx to console switch with the binary NVIDIA driver. I'd also like to use the graphical.target, but the same behaviour occurs. I wrote a custom service, as described at: https://wiki.gentoo.org/wiki/X_without_Display_Manager#Method_2 Reproducible: Always Steps to Reproduce: 1. Add ~amd64 to /etc/portage/package.use for x11-drivers/nvidia-drivers to install support for the nvidia-drm module. 1a. Whether Stable or unstable drivers, the issue occurs in both cases. 2. Add nvidia to the VIDEO_CARDS variable in make.conf 3. Install xorg-x11 using emerge. This pulls in the nvidia-drivers. 4. Install twm to test, with emerge twm xterm 5. Using startx, Starts X, but Ctrl + Alt + Fn results in the behaviour I described above, in both the multi-user and graphical targets. Actual Results: Why does this occur? Do graphical and display-manger service files properly support passing VT numbers? --------------------------------------- Not having said service causes the NVIDIA Binary Blob to lock up the screen, i.e permanent black screen, with only recovery possible being a hard reboot. Expected Results: Being able to press Ctrl + Alt + Fn multiple times should allow proper terminal switching. systemd version: 226-r2 Card: 02:00.0 VGA compatible controller: NVIDIA Corporation GF116 - GeForce GTX 550 Ti (rev a1) Portage 2.2.28 (python 3.4.3-final-0, default/linux/amd64/13.0/systemd, gcc-4.9. 3, glibc-2.22-r4, 4.4.6-gentoo x86_64) ================================================================= System uname: Linux-4.4.6-gentoo-x86_64-AMD_Athlon-tm-_II_X2_255_Processor-with- gentoo-2.2 KiB Mem: 4055644 total, 2543156 free KiB Swap: 4702204 total, 4698524 free Timestamp of repository gentoo: Thu, 14 Jul 2016 21:30:01 +0000 sh bash 4.3_p42-r1 ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1 app-shells/bash: 4.3_p42-r1::gentoo dev-lang/perl: 5.20.2::gentoo dev-lang/python: 2.7.10-r1::gentoo, 3.4.3-r1::gentoo dev-util/cmake: 3.3.1-r1::gentoo dev-util/pkgconfig: 0.28-r2::gentoo sys-apps/baselayout: 2.2::gentoo sys-apps/openrc: 0.19.1::gentoo sys-apps/sandbox: 2.10-r1::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69::gentoo sys-devel/automake: 1.14.1::gentoo, 1.15::gentoo sys-devel/binutils: 2.25.1-r1::gentoo sys-devel/gcc: 4.9.3::gentoo sys-devel/gcc-config: 1.7.3::gentoo sys-devel/libtool: 2.4.6::gentoo sys-devel/make: 4.1-r1::gentoo sys-kernel/linux-headers: 4.3::gentoo (virtual/os-headers) sys-libs/glibc: 2.22-r4::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O3 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/ fonts.conf /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=k8 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild -locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned san dbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="ftp://cosmos.illinois.edu/pub/gentoo/" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir- times --compress --force --whole-file --delete --stats --human-readable --timeou t=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="X a52 aac acl acpi alsa amd64 berkdb bluetooth branding bzip2 cairo cdda cd r cli cracklib crypt cups cxx dbus dri dts dvd dvdr emboss encode exif fam firef ox flac fortran gdbm gif glamor gpm gtk iconv jpeg lcms ldap libkms libnotify lv m2create_initrd mad mmx mmxext mng modules mp3 mp4 mpeg multilib ncurses nls npt l ogg opengl openmp pam pango pcre pdf plymouth png policykit ppds qt3support re adline sdl seccomp session spell sse sse2 ssl startup-notification svg systemd t cpd tiff truetype udev udisks unicode upower usb uvm vorbis wxwidgets x264 xattr xcb xml xv xvid zlib" ABI_X86="32 64" ALSA_CARDS="ali5451 als4000 atiixp atiixp -modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-inte l intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" AP ACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basi c authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_defa ult authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid d av dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filt er headers include info log_config logio mem_cache mime mime_magic negotiation r ewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA _FEATURES="kexi words flow plan sheets stage tables krita karbon braindump autho r" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap sy slog" CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext popcnt sse sse2 sse3 sse4a" ELIBC ="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 r tcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="pc" INPUT_DEVICES="evdev" KERNEL="linux" L10N="en en_US" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS ="presenter-console presenter-minimizer" LINGUAS="en en_US" OFFICE_IMPLEMENTATIO N="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TAR GETS="python2_7 python3_4" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" VIDEO_CAR DS="nvidia" XFCE_PLUGINS="brightness clock multiload-nandhp power trash" XTABLES _ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuz zy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos a ccount" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, P ORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_ EXTRA_OPTS, USE_PYTHON ----------------- Possible Fix Writing the custom service is a nasty hack(the --login parameter supports only one user), but works, but only allows switching terminals once. Switching from X to terminal works, but going back from the terminal to X the second time, still produces the behavior. Switching to nouveau may fix this, but would severely cripple my adapter IMHO, which is why I'm using the nvidia-drm module, with in kernel DRM.
(In reply to Carter Young from comment #0) > Regardless of the fact that I use systemd, this needs to be looked into. As > such, please don't hate on me but help me. What are you on about?
Please post your `emerge -vpq x11-drivers/nvidia-drivers` output in a comment.
emerge -vpq x11-drivers/nvidia-drivers [ebuild R ] x11-drivers/nvidia-drivers-367.27 USE="X acpi driver kms multilib tools uvm -compat -gtk3 -pax_kernel -static-libs -wayland" ------------------------------------- Re: On about Sorry about that rant. I just don't want this bug to turn into an "anti systemd" switchover flame. Let me know what else you need. BTW: This is a semi brand new install(less than a week old). I lost a 3+ year install while attempting to convert over to LVM, unsuccessfully.
http://www.nvidia.com/download/driverResults.aspx/105342/en-us * Fixed a bug that caused X to crash when applying changes to the RandR CscMatrix property while VT-switched away from X. Could you try upgrading to =x11-drivers/nvidia-drivers-367.35
(In reply to Jeroen Roovers from comment #4) > http://www.nvidia.com/download/driverResults.aspx/105342/en-us > > * Fixed a bug that caused X to crash when applying changes to the RandR > CscMatrix > property while VT-switched away from X. > > Could you try upgrading to =x11-drivers/nvidia-drivers-367.35 Just updated to 367.35, and the issue still persists... It did get better, but the VT switching is now only one way. With graphical.target enabled, XFCE starts. Pressing Ctrl + Alt + Fn works now when going from VT7 to VT1. Attempting to go from VT7 to VT1 fails, with the Black Screen
> > Just updated to 367.35, and the issue still persists... It did get better, > but the VT switching is now only one way. With graphical.target enabled, > XFCE starts. Pressing Ctrl + Alt + Fn works now when going from VT7 to VT1. > Attempting to go from VT7 to VT1 fails, with the Black Screen I just read this and caught a mistake: Works: VT7(Graphical) ==> VT1 Fails: VT1 ==> VT7 == VT7 Stuck at black
I can confirm this bug... NVIDIA GeForce GTX 460 (GF104) here on two diff PCs on Gentoo I had it and its' being aggravated with every new Xorg and Nvidia versions since xorg 1.17.4 and Nvidia 361.28... Sadly it is an Nvidia driver problem and we will have to wait for them to fix it..... I've tried different things as a workaround but nothing works.... Now I am testing the Nouveau driver with the nvidia-firmware packages and modeset=1 .... The above bug gives me this message: nvidia-modeset: ERROR: GPU:0: Idling display engine timed out: 0x0000857d:0:0:0x00000040 Downgrading to Nvidia 358.16-r1 or 361.28 and xorg 1.17.4 may help you but if your system is with the ~ keyword it will have too much and too deep downgrade deps and maybe circular ones that are hard to fix...
(In reply to PhobosK from comment #7) > I can confirm this bug... > ... > > Downgrading to Nvidia 358.16-r1 or 361.28 and xorg 1.17.4 may help you but > if your system is with the ~ keyword it will have too much and too deep > downgrade deps and maybe circular ones that are hard to fix... emerge -avq x11-base/xorg-server [ebuild R ] x11-base/xorg-server-1.17.4:0/1.17.4::gentoo USE="glamor kdrive nptl suid systemd udev xorg -dmx -doc -ipv6 (-libressl) -minimal (-selinux) -static-libs -tslib -unwind -wayland -xephyr -xnest -xvfb" 0 KiB I've tried 361.28, but i havent tried 358.xx...
OK here is a solution you may try (it worked for me and it will probably work for you too).. In a word NVidia's bin kernel driver is incompatible with uvesafb, nvidiafb etc... So you should remove these... The long story: Since NVidia bin kernel driver has a part that provides some kinda FB it conflicts with any other FB and DRM kernel module... So make sure you don't have any compiled in kernel (or if they are, just blacklist them if are compiled as modules) your: zgrep CONFIG_FB_NVIDIA /proc/config.gz zgrep CONFIG_FB_UVESA /proc/config.gz zgrep CONFIG_FB_VESA /proc/config.gz and zgrep CONFIG_FB_RIVA /proc/config.gz should say "is not set"... If they are set recompile kernel... Same goes for: CONFIG_DRM_NOUVEAU Then put these in your /etc/modprobe.d/blacklist.conf (it is important to be in this file, because it is the only one copied in the initramfs) blacklist nouveau blacklist uvesafb blacklist nvidiafb then recreate your initramfs-genkernel by: genkernel --install --oldconfig --loglevel=5 initramfs Watch the genkernel output for NOT injecting the /sbin/v86d also (it should not do it especially if you have not merged the sys-apps/v86d) A shortest way without recompiling things is to add to your kernel boot parameters: modprobe.blacklist=nouveau,uvesafb,nvidiafb then run grub-install and reboot...
(In reply to PhobosK from comment #9) > OK here is a solution you may try (it worked for me and it will probably > work for you too).. > > In a word NVidia's bin kernel driver is incompatible with uvesafb, nvidiafb > etc... So you should remove these... The long story: > > > Since NVidia bin kernel driver has a part that provides some kinda FB it > conflicts with any other FB and DRM kernel module... So make sure you don't > have any compiled in kernel (or if they are, just blacklist them if are > compiled as modules) > > your: > zgrep CONFIG_FB_NVIDIA /proc/config.gz > zgrep CONFIG_FB_UVESA /proc/config.gz > zgrep CONFIG_FB_VESA /proc/config.gz > and > zgrep CONFIG_FB_RIVA /proc/config.gz > > should say "is not set"... If they are set recompile kernel... > > Same goes for: CONFIG_DRM_NOUVEAU > > <snip> This worked. Running a native systemd init, I had used sys-kernel/genkernel-next to add plymouth support to my initramfd. In order to use sys-boot/plymouth I needed a framebuffer driver. When I used SysV init, the uvesafb/nvidia driver combo worked and successfully switched, even on the newer kernels, with strtx. Short of it is: 1. Pure systemd breaks media-gfx/splashutils, until recently. Systemd service files don't exist for fbcondecor. If I knew I could write one non-hackishly looking I would. 2. Adding plymouth for eyecandy still requires a framebuffer driver. In order for the combo I listed above to work, startx must be used. 3. Startx, AFAIK, is very hard to get working system-wide, when using systemd. 4. Systemd uses graphical.target to control graphical session management, removing the need for startx. 5. Terminal switching with uvesafb/v86d loaded breaks graphical.target, causing the lockup. Logging out after a session using startx allowed uvesafb to remain loaded. I'd get a framebuffer I could read at high resolution, plus KDE when I needed it. ----------------------------------- As it stands now, terminal switching now works like it's supposed to, but you only get a 640x480 colored terminal, and no plymouth startup splash. What needs work here to get these working harmoniously again?
Accordingly to https://www.reddit.com/r/linux/comments/4bfxip/plymouth_now_works_with_proprietary_nvidia/ plymouth now can work with latest proprietary drivers. Does anyone succeed with this under Gentoo?
(In reply to Serge Gavrilov from comment #11) > Accordingly to > > https://www.reddit.com/r/linux/comments/4bfxip/ > plymouth_now_works_with_proprietary_nvidia/ > > plymouth now can work with latest proprietary drivers. Does anyone succeed > with this under Gentoo? I have gotten this to work. I just finished it yesterday. It will take some time to retrace what I did, but I'll post it here since this is my bug report. Also, note that the plymouth method may only work with a service that automatically starts X at boot, ie. gdm/gnme3 or kdm/kde
(In reply to Serge Gavrilov from comment #11) > Accordingly to > > https://www.reddit.com/r/linux/comments/4bfxip/ > plymouth_now_works_with_proprietary_nvidia/ > > plymouth now can work with latest proprietary drivers. Does anyone succeed > with this under Gentoo? This tool awhile and I now have a fully running system, with a plymouth splash, systemd. Follow these steps to repeat the process 1. Determine if your PC is UEFI or BIOS based 2. Install sys-kernel/genkernel-next, or sys-kernel/dracut(Personal preference is genkernel next, as we get an entire kernel + a RAM Disk). Needed for plymouth support 2. Upgrade your kernel to 4.14.xx. See https://bugs.gentoo.org/649198 4. Upgrade or install new microcode. Preferred method of installation is 5.2. See https://wiki.gentoo.org/wiki/Intel_microcode ================================================ This protects us against Meltdown/Spectre. Continuing: 5. Set menuconfig to YES in /etc/genkernel.conf 6. Set plymouth to YES in /etc/genkernel.conf 7. Set a theme in /etc/genkernel.conf. See https://wiki.gentoo.org/wiki/Plymouth 8. Set LOGLEVEL to 5 9. Run genkernel all 10. Device Drivers -> Graphics -> Framebuffer Console Support -> Remove all *'s A.) If BIOS choose VESA and simplefb B.) If UEFI choose EFI Framebuffer and simplefb 11. Set the rest of your needed kernel options. 12. Save the .config file and build the kernel. 13. Update your boot command line with the appropriate video option. NOTE: I didn't have to do this as the EFI Framebuffer selects the native resolution.
*** Bug 594558 has been marked as a duplicate of this bug. ***
I was thinking to add some checks to handle these FB_* issues but current means to check are not very versatile and would trigger unneeded messages for generic kernels. I feel wiki documentation is more suitable to handle these issues (as it already does to some extend). https://wiki.gentoo.org/wiki/NVIDIA/nvidia-drivers
(In reply to Ionen Wolkens from comment #15) > I was thinking to add some checks to handle these FB_* issues but current > means to check are not very versatile and would trigger unneeded messages > for generic kernels. > > I feel wiki documentation is more suitable to handle these issues (as it > already does to some extend). > https://wiki.gentoo.org/wiki/NVIDIA/nvidia-drivers I've fixed this by only using the EFI Framebuffer as the console driver. This is now the only option on amd64 systems due to the fact that v86d is no longer maintained/in the kernel tree.
