X server hangs when switching TTYs or shutdown

Pyro MX · n00b Joined: 19 Oct 2007 Posts: 27 Location: Canada

Hello all,

I have a bit of a special problem that appeared recently, maybe after an update. The system was running smoothly for a while.

So here's the thing: X runs on VT7. If I switch to a different VT (ex VT1) and try to come back to VT7, the system freezes.

Now, I tried some combinations and here's what I found out so far: unless I shutdown from a logged in KDE session, X will never stop. If I shutdown from VT{1-6}, X hangs. If I shutdown from the LightDM greeter, X hangs. I tried Alt+Sysrq+O - the signals gets registered, nothing happens. I was running KDM, I switched to LightDM, didn't change anything. The XDM service doesn't get stopped, init reports the service not stopping and it just waits there forever.

Where it gets more interesting: if I run htop as root inside VT{1-6} and try to kill (with SIGKILL) the X server, I will be able to interact with the terminal for about a couple seconds. After that, X will take 100% of the CPU (although it seems to be 100% of one of the 6 cores) and all input will freeze. Htop still runs and gets updated on screen. Keys seem to register, but with a very very very long delay. The keyboard is plugged on the PS/2 port.

Does that ring a bell to anybody?

Machine information:

* Arch is amd64
* GPU is Nvidia, running with the latest stable proprieraty driver
* Kernel 4.1.15-gentoo-r1, initramfs generated with genkernel stable
* KDE 4 desktop environment (stable)

Thanks!

_________________
Pyro MX

C5ace · Posted: Sun Feb 21, 2016 8:59 am Post subject:

I updated from kernel 4.1.12 to 4.1.15-gentoo-r1, Genkerne, Nvidia, Xfce, Slim. grub-static. Result was no video on Vt1 ~ Vt12. Same thing on a Toshiba laptop with Intel video. Both have no EFI or UEFI hardware

Reverted back kernel 4.1.12.

Kernel 4.1.15-gentoo-r1 works on a new HP latop with EFI and UEFI hardware, both disbled, Radeon viedeo. otherwise the same as above.

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

Pyro MX · n00b Joined: 19 Oct 2007 Posts: 27 Location: Canada

I double-checked my kernel configuration. DRM is activated, but there are no compiled-in drivers in the kernel itself. The proprietary NVidia driver is the only one I have. Maybe it's something with the framebuffer...
_________________
Pyro MX

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

Framebuffer/VGA console are also hardware drivers. Any framebuffer console in particular is NOT safe to use with nvidia.ko.

chithanh · Posted: Sun Feb 21, 2016 11:17 pm Post subject:

Do you have IOMMU support enabled in your kernel? That is known to cause problems with the proprietary NVidia driver.

If so, try to disable CONFIG_INTEL_IOMMU in genkernel --menuconfig or set the intel_iommu=off kernel parameter.

Pyro MX · n00b Joined: 19 Oct 2007 Posts: 27 Location: Canada

I happen to have two framebuffer drivers enabled - Userspace (uvesafb) and EFI. Since I don't use EFI, I'm going to disable this one first. I also have INTEL_IOMMU. I'm going to try without the EFI driver first, see if corrects the problem. If it does, we'll be able to pinpoint the option causing conflicts. If not, I'll also try disabling INTEL_IOMMU.
_________________
Pyro MX

Pyro MX · n00b Joined: 19 Oct 2007 Posts: 27 Location: Canada

Well, still no luck. I disabled both the EFI framebuffer and the Intel IOMMU option, still have the same behaviour as before. I also tried removing the "video" line altogether from the kernel command line to prevent the system from enabling fbcondecor, no effect. It makes me want to switch to nouveau,all of a sudden :wink:

.
_________________
Pyro MX

perlovka · n00b Joined: 04 Aug 2004 Posts: 16 Location: Israel

Same trouble: when trying to switching VTs or to stop xdm, video and input subsystems hangs (still available to connect via ssh and reboot properly)

This message appears in system logs:

Pyro MX · n00b Joined: 19 Oct 2007 Posts: 27 Location: Canada

Thanks for the info, perlovka

I did some tests on my side and here's what happened:

After the update to Plasma 5, sddm failed to start because it wasn't in the video group. But not knowing the cause initially, I switched to the nouveau driver. Using the nouveau driver, everything worked including the framebuffer, but no 3D firepower here.

I then re-switched to the nvidia driver, this time disabling all the framebuffer drivers. Here's what I did:

emerge with "newuse" considering the VIDEO_CARD option changed in make.conf, making sure to rebuild all the necessary packages
Unmerge v86d
Remove all the framebuffer drivers (including the Userspace Vesa VGA driver), but leave framebuffer support on
Remove the v86d initramfs reference from the kernel configuration
Remove all video-related kernel command line options from GRUB
Remove splashutils and disable the themes from the genkernel configuration
Remove the kernel, rebuild the initramfs, reinstall the kernel in /boot
Update GRUB2 configuration
Add the sddm user to the video group (for any users here who may just have upgraded to Plasma 5 )
Reboot

I no longer have any framebuffer console decorations, but I can freely switch to any VT without any freezing. From what I gather, there are troubles with the new proprietary nvidia drivers and uvesafb. I'll have to do some more testing in the future, but I'll mark this as solved as there are a couple of options here to circumvent the problem.

Thanks everybody for all your help!

_________________
Pyro MX