You are not logged in.
Edit:
I have been tracing the error, and it doesn't look like to be the driver's fault: I can start kodi-standalone from the command line, but somehow it fails only when launched through systemd (which I did NOT update last week, and does neither solve the problem when downgrading).
---
Hi all,
I have an old computer hooked up to my TV through HDMI, working as media server with kodi (in "standalone" mode). The computer has an nvidia GT 610, and it has been running fine for a long time. But last week I ran a system update, and since then, I haven't been able to start kodi: it always gets stuck in a black screen, spitting out hundreds of crashlog files in kodi's user directory.
I have tried to downgrade every package that I updated last week, including nvidia (nvidia, nvidia-utils, nvidia-libgl), kernel (linux, linux-headers), mesa (...) and xorg (xorg-server, xorg-server-common). The only thing that worked is to install mesa-libgl: kodi starts, but then playback quality is garbage. I also have tried to switch to nvidia-dkms, but still no positive results.
My best guess is that the driver is broken, as everything worked a week ago, and also, as I have looked into the Xorg log, and found these entries, which I had never noticed before:
[ 31.070] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 11 paused 1
[ 31.070] (EE) Error systemd-logind returned paused fd for drm node
[ 31.351] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X
[ 31.351] (EE) NVIDIA(0): log file that the GLX module has been loaded in your X
[ 31.351] (EE) NVIDIA(0): server, and that the module is the NVIDIA GLX module. If
[ 31.351] (EE) NVIDIA(0): you continue to encounter problems, Please try
[ 31.351] (EE) NVIDIA(0): reinstalling the NVIDIA driver.
[ 32.280] (II) AIGLX: Screen 0 is not DRI2 capable
[ 32.280] (EE) AIGLX: reverting to software rendering
[ 32.544] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/swrast_dri.so failed (/usr/lib/xorg/modules/dri/swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)
[ 32.544] (EE) GLX: could not load software renderer
[ 32.544] (II) GLX: no usable GL providers found for screen 0
I also had a look at the crashlogs and dmesg, but I haven't been able to extract any useful information, just "ERROR: Failed to find matching visual" in the last line of the crashlogs.
Can somebody help me out? Or, at least, confirm that something is wrong with the drivers?
Last edited by ricrogz (2017-02-22 06:58:22)
Offline
Please don't tag the post title with "[Closed]", which carries the connotation of a moderator locking the thread against people posting and possibly moving it to the Dustbin as well.
Perhaps you could say "mistaken", or turn it into a thread about "Kodi crashes with a black screen".
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
As I stated in the AUR page, I experienced this too using the 340xx series of drivers. The solution was to enable [testing] and update. For me the breakage occurred after 16-Feb as downgrading using ALA set to that date fixed the problem. I did see some non-minor changes to both the xorg-server and nvidia-340xx-utils in that time frame.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Please test nvidia-340xx-utils 340.102-3 in testing
Offline
Perhaps you could say "mistaken", or turn it into a thread about "Kodi crashes with a black screen". smile
Ok, fixed. The post is not [Mistaken].
Please test nvidia-340xx-utils 340.102-3 in testing
Actually, I also tried the 340.102 drivers (but not the ones in testing) too, still with no results. I'll try them tonight.
Yesterday I tried a few things, and I learned that I could run kodi-standalone from the command line (with "sudo -u kodi /usr/bin/xinit /usr/bin/kodi-standalone -- :0 -nolisten tcp vt7"), but not from systemd.
Looking further into it, I tried to alter the kodi.service file and to change the number of the vt. I tried vt2, vt3 and just without vt7, and in all three cases I was able to get kodi to run (albeit it took some time to start up, but I think this might be related to a problem with pulseaudio's configuration).
As I said, I will try to gather some more information this evening.
Offline
ricrogz, paste you kodi.service file here.
Offline
@killer1804 it's exactly the same as in aur/kodi-standalone-service
[Unit]
Description=Starts instance of Kodi using xinit
After=systemd-user-sessions.service network.target sound.target mysqld.service
Conflicts=getty@tty7.service
[Service]
User=kodi
Group=kodi
PAMName=login
TTYPath=/dev/tty7
ExecStart=/usr/bin/xinit /usr/bin/kodi-standalone -- :0 -nolisten tcp vt7
Restart=on-abort
StandardInput=tty
[Install]
WantedBy=multi-user.target
I also can confirm that if I remove the "vt7", kodi-standalone works again (and breaks as soon as I put back the "vt7"). I also fixed pulseaudio's problems, and now kodi is starting in just a few seconds again
Last edited by ricrogz (2017-02-22 19:12:41)
Offline
I maintain the kodi-standalone-service from the AUR. To be clear:
1) You need to remove the last work on the ExecStart line for your system to work?
2) You did or did not try enabling [testing] and running `pacman -Syyu` using the original kodi.service file?
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
I had a similar problem yesterday, with similar setup, NVIDIA ION, nvidia-340xx-utils.
also glx module missing. Solved the problem by adding ModulePath "/usr/lib/nvidia/xorg" in xorg.conf.d
No other changes.
Offline
I had a similar problem yesterday, with similar setup, NVIDIA ION, nvidia-340xx-utils.
also glx module missing. Solved the problem by adding ModulePath "/usr/lib/nvidia/xorg" in xorg.conf.d
No other changes.
Do you have [testing] enabled and if so is your machine updated? Please try that and remove the customization you did to /etc/X11/xorg.conf.d/20-nvidia.conf before you reboot. Does that solve the issue?
Note the changes to nvidia-340xx-utils: https://git.archlinux.org/svntogit/pack … 05ce67fd4f
Last edited by graysky (2017-02-22 20:45:37)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Grrr... now my ION machine (340xx) is not starting again upon updating to 340xx-utils-340.102-4. I can confirm the behavior ricrogz pointed out by removing the last word from the ExecStart line of kodi.service. I can also confirm this seems harmless on a non-nvidia box. Perhaps it's time to change it in the AUR package.
@ricrogz - How did you happen upon this solution curiously?
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
I maintain the kodi-standalone-service from the AUR. To be clear:
1) You need to remove the last work on the ExecStart line for your system to work?
2) You did or did not try enabling [testing] and running `pacman -Syyu` using the original kodi.service file?
1) Yes, removing the last word from the ExecStart line ("vt7") solved my issue. Why? No clue. It just works. And yes, I know that you are the maintainer of the aur package.
2) No, I did not try any updates from testing. As I am not sure what went wrong the last time, or updating which package caused the failure, I prefer not to start updating packages randomly from the [testing] repo.
Offline
@ricrogz - Thank you for the fix however you figured it out.... removing this last word from the service works for nvidia-340xx machines but not for intel machines
Last edited by graysky (2017-02-22 21:15:06)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
...I think there must be something odd with the nvidia-304xx packaging.
Last edited by graysky (2017-02-22 21:15:29)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
@graysky: I'm not sure the problem is with the nvidia packages -- then downgrading them should have worked, I guess.
Somehow, I have the impression that it is related with systemd and/or the vt's: see the log messages in my first post.
Also, I found out (after fixing the problem and comparing the logs) that the X server was completely ignoring the nvidia-drm-outputclass.conf file, even if I copied it into /etc/X11/xorg.conf.d. This botched up the ModulePath, as ybergeek mentioned in his post, and loaded the default libglx.so in /usr/lib/xorg/modules/extensions/, which is provided by mesa (that's the reason why it worked when I installed mesa-libgl). Maybe something similar is happening with the intel drivers.
But, as I said: as soon as I removed the "vt7" from the ExecStart line (or changed it to a lower numbered vt), the errors dissappeared, X found the nvidia-drm-outputclass.conf file, and everything is wonderful again. Analyzing it a little bit, the error messages about GLX and AIGLX are gone because ModulePath is right, and the nvidia module is loaded, so the only "unexplained" error left is the first one, directly mentioning systemd-logind, which, somehow, I ended up relating to the vt's.
Offline
@ricrogz - On my ION box, I needed to downgrade to the repo per the 16th of Feb or else the standalone service stopped working. Can you try that? You can use ALA. Simply modify /etc/pacman.conf like this and run `pacman -Syy && pacman -Suu` then reboot keeping the standalone service unmodified and whatever else you changed unmodified. It should work. Now Revert back to the current repo and update. Then it will cease to work. That was my experience.
[core]
#Include = /etc/pacman.d/mirrorlist.reflector
Server=https://archive.archlinux.org/repos/2017/02/16/$repo/os/$arch
[extra]
#Include = /etc/pacman.d/mirrorlist.reflector
Server=https://archive.archlinux.org/repos/2017/02/16/$repo/os/$arch
[community]
#Include = /etc/pacman.d/mirrorlist.reflector
Server=https://archive.archlinux.org/repos/2017/02/16/$repo/os/$arch
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Here, I don't use kodi but since few days i encounter issues with nvidia 340xxx and kde plasma desktop.
When switching to a user, sddm crashes when it launches a new session on a second X server.
In the /var/log/Xorg.1.log, i see some weird things :
$ grep EE /var/log/Xorg.1.log
[ 53589.799] Current Operating System: Linux xxxxxx 4.9.8-1-ARCH #1 SMP PREEMPT Mon Feb 6 12:59:40 CET 2017 x86_64
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 53589.801] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
[ 53591.057] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X
[ 53591.057] (EE) NVIDIA(0): log file that the GLX module has been loaded in your X
[ 53591.057] (EE) NVIDIA(0): server, and that the module is the NVIDIA GLX module. If
[ 53591.057] (EE) NVIDIA(0): you continue to encounter problems, Please try
[ 53591.057] (EE) NVIDIA(0): reinstalling the NVIDIA driver.
[ 53591.227] (EE) AIGLX: reverting to software rendering
[ 53591.288] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/swrast_dri.so failed (/usr/lib/xorg/modules/dri/swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)
[ 53591.288] (EE) GLX: could not load software renderer
[ 53591.395] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
The permission denied on /dev/dri/card0 leads sddm to crash.
Feb 22 22:24:32 darkstar systemd[1]: Started User Manager for UID 990.
Feb 22 22:24:32 darkstar sddm[26406]: Greeter session started successfully
Feb 22 22:24:32 darkstar sddm-greeter[3347]: Reading from "/usr/share/xsessions/fvwm.desktop"
Feb 22 22:24:32 darkstar sddm-greeter[3347]: Reading from "/usr/share/xsessions/plasma.desktop"
Feb 22 22:24:32 darkstar sddm-greeter[3347]: inotify_add_watch("/usr/share/wayland-sessions") failed: "No such file or directory"
Feb 22 22:24:32 darkstar sddm-greeter[3347]: Connected to the daemon.
Feb 22 22:24:32 darkstar sddm[26406]: Message received from greeter: Connect
Feb 22 22:24:32 darkstar sddm-greeter[3347]: Loading file:///usr/share/sddm/themes/maui/Main.qml...
Feb 22 22:24:32 darkstar sddm-greeter[3347]: Adding view for "DVI-I-1" QRect(0,0 1920x1200)
Feb 22 22:24:32 darkstar systemd[3338]: Started D-Bus User Message Bus.
Feb 22 22:24:32 darkstar sddm-greeter[3347]: Message received from daemon: Capabilities
Feb 22 22:24:32 darkstar sddm-greeter[3347]: Message received from daemon: HostName
Feb 22 22:24:32 darkstar sddm-greeter[3347]: QXcbIntegration: Cannot create platform OpenGL context, neither GLX nor EGL are enabled
Feb 22 22:24:32 darkstar sddm-greeter[3347]: Failed to create OpenGL context for format QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize
Feb 22 22:24:32 darkstar kernel: potentially unexpected fatal signal 6.
Feb 22 22:24:32 darkstar kernel: CPU: 1 PID: 3347 Comm: sddm-greeter Tainted: P O 4.9.8-1-ARCH #1
Feb 22 22:24:32 darkstar kernel: Hardware name: MICRO-STAR INTERNATIONAL CO.,LTD MS-7513/P45D3(MS-7513), BIOS V1.9 05/19/2011
Feb 22 22:24:32 darkstar kernel: task: ffff8801d081ea00 task.stack: ffffc90003a1c000
Feb 22 22:24:32 darkstar kernel: RIP: 0033:[<00007febb10f404f>] [<00007febb10f404f>] 0x7febb10f404f
Feb 22 22:24:32 darkstar kernel: RSP: 002b:00007ffc83b732e8 EFLAGS: 00000246
Feb 22 22:24:32 darkstar kernel: RAX: 0000000000000000 RBX: 0000000000000006 RCX: 00007febb10f404f
I have tried a
chmod o+rw /dev/dri/card0
but it makes no difference.
Somehow, I have the impression that it is related with systemd and/or the vt's: see the log messages in my first post.
It confirms what rickrogz says.
Edit :
I have just upgraded to the latest nvidia-340xx*, it doesn't solve the issue.
Last edited by hamelg (2017-02-23 20:17:21)
Offline
@ricrogz - On my ION box, I needed to downgrade to the repo per the 16th of Feb or else the standalone service stopped working. Can you try that? You can use ALA. Simply modify /etc/pacman.conf like this and run `pacman -Syy && pacman -Suu` then reboot keeping the standalone service unmodified and whatever else you changed unmodified. It should work. Now Revert back to the current repo and update. Then it will cease to work. That was my experience.
[core] #Include = /etc/pacman.d/mirrorlist.reflector Server=https://archive.archlinux.org/repos/2017/02/16/$repo/os/$arch [extra] #Include = /etc/pacman.d/mirrorlist.reflector Server=https://archive.archlinux.org/repos/2017/02/16/$repo/os/$arch [community] #Include = /etc/pacman.d/mirrorlist.reflector Server=https://archive.archlinux.org/repos/2017/02/16/$repo/os/$arch
First of all, thanks, I didn't know about the existence of the ALA. You always learn something new
I just did as requested. As soon as I reverted, everything worked fine, as you said. From there on, I started upgrading packages gradually, until I found the culprits:
- If I start from 2017/02/16 packages and upgrade just kernel + nvidia modules (install nvidia-utils-378.13-1 linux-4.9.11-1 linux-firmware-20170217.12987ca-1 linux-headers-4.9.11-1 nvidia-378.13-2 nvidia-libgl-378.13-1), then xorg-server 1.19.1-2 argues about "ModulePath", and kodi-standalone cannot start:
[ 145.947] Parse error on line 5 of section OutputClass in file /usr/share/X11/xorg.conf.d/nvidia-drm-outputclass.conf
"ModulePath" is not a valid keyword in this section.
As expected, reverting the packages to the previous versions makes kodi-standaloe start again.
- On the other hand, if starting from 2017/02/16 I update xorg-server and xorg-server-common from 1.19.1-2 to 1.19.1-5, I get a warning about /usr/lib/xorg/modules/extensions/libglx.so already existing in the filesystem (belongs to nvidia-libgl 375.26-2), and installation cannot proceed. Forcing installation, and then re-installing nvidia-libgl also breaks kodi-standalone, and to make it work again, xorg-server must be downgraded, and also nvidia-libgl 375.26-2 must be reinstalled.
- needless to say, upgrading everything also breaks kodi-standalone, as it is the initial situation that motivated this thread.
Conclusion: the pair xorg / nvidia-libgl are not getting along well, avoid to update any of them. This also affects the kernel (due to dependance of nvidia module): keep xorg version 1.19-2, nvidia-libgl 375.26-2 plus kernel 4.9.8, and everything should be fine.
Last edited by ricrogz (2017-02-24 19:26:55)
Offline
@ric - best to open a bugreport against these packages so the devs/packagers can investiagte and fix
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Conclusion: the pair xorg / nvidia-libgl are not getting along well, avoid to update any of them. This also affects the kernel (due to dependance of nvidia module): keep xorg version 1.19-2, nvidia-libgl 375.26-2 plus kernel 4.9.8, and everything should be fine.
I have downgraded according your suggestion
downgraded xorg-server-common (1.19.1-5 -> 1.19.1-2)
downgraded xorg-server-devel (1.19.1-5 -> 1.19.1-2)
downgraded xorg-server-xnest (1.19.1-5 -> 1.19.1-2)
downgraded linux (4.9.11-1 -> 4.9.8-1)
downgraded linux-docs (4.9.11-1 -> 4.9.8-1)
downgraded linux-headers (4.9.11-1 -> 4.9.8-1)
downgraded xorg-server (1.19.1-5 -> 1.19.1-2)
downgraded nvidia-340xx-utils (340.102-4 -> 340.101-1)
downgraded lib32-nvidia-340xx-utils (340.102-2 -> 340.101-1)
downgraded nvidia-340xx (340.102-3 -> 340.101-10)
and it has solved the issue
Offline
@hamelg: good! I'm happy to be of help.
@graysky: I'm on it.
Last edited by ricrogz (2017-02-24 21:52:49)
Offline
... and they said it's not a bug, but a bad configuration.
Offline
... and they said it's not a bug, but a bad configuration.
What are you talking about... reference?
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
The bug report: https://bugs.archlinux.org/task/53078
Offline
Further investigation about my issue (see comment #17).
I did a diff on Xorg.x.log files before and after the breakage (with nvidia-340xx-utils 340.102-5). The issue is related to module autoloading.
The first X server load the right glx module, but not the second. In the Xorg.0.log, there is a line just before loading glx module which is not present in Xorg.1.log :
(**) OutputClass "nvidia" ModulePath extended to "/usr/lib/nvidia/xorg,/usr/lib/xorg/modules"
The second X server tries to load the wrong module /usr/lib/xorg/modules/extensions/libglx.so (owned by xorg-server). It should load /usr/lib/nvidia/xorg/libglx.so.
The workaround is to add a modulepath as says ybergeek in comment #9 and the conclusion of the bug report.
Section "Files"
ModulePath "/usr/lib/nvidia/xorg,/usr/lib/xorg/modules"
EndSection
Edit :
https://bugs.archlinux.org/task/53090
Last edited by hamelg (2017-02-26 19:03:15)
Offline