Summary: | x11-drivers/nvidia-drivers-367.27 causes black screen when switching VT's | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Carter Young <ecyoung> |
Component: | Current packages | Assignee: | David Seifert <soap> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | ionen, mschiff, O01eg, phobosk, rzubaly, serge |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Carter Young
2016-07-17 19:29:47 UTC
(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. |