I have a TX2 dev board, Jetpack 3.3.
I am unable to run any OpenGL apps.
When loading X server on login, one line in the /var/log/Xorg.0.log seems to be culprit:
(EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)
However, sha1sum -c /etc/nv_tegra_release shows all as OK.
Any ideas?
Xorg.0.log (24 KB)
You might want to post that log (you could rename it with a “.txt” file extension…hover the mouse over the upper right of an existing post, then the paper clip icon shows up so you can attach a file).
I’ve posted the entire log as an attachment to my original question.
This line is repeated many times in the log, and is an error I have not seen before:
[ 15.013] (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
After that it mentions what you already noted:
[ 15.032] (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)
The “invalid argument” tends to make me believe this is related to configuration. From what I can tell the ABI versions seem to be what they should be, and so I don’t think it is an incorrect version of any software.
I don’t know if this will be related, but you might post a copy of your “/etc/X11/xorg.conf” file, and what you see from:
sudo -s
cat `find /sys -name edid`
exit
Meanwhile, does anyone have an idea of why the error “FBDEV(0): FBIOPUTCMAP: Invalid argument” might be showing up?
Hmm I actually don’t seem to HAVE an /etc/X11/xorg.conf file - I have xorg.conf.failsafe, xorg.conf.orig.vgl, xorg.conf-backup-181018162912, and xorg.conf.t186_ref. Which one is used if I don’t have a default?
The output of the edid command is:
root@tegra-ubuntu:~# cat `find /sys -name edid`
00 ff ff ff ff ff ff 00 10 ac a4 a0 4c 4e 46 30
13 1c 01 03 80 35 1e 78 ee 7e 75 a7 55 52 9c 27
0f 50 54 a5 4b 00 71 4f 81 80 a9 c0 a9 40 d1 c0
01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
45 00 0f 28 21 00 00 1e 00 00 00 ff 00 4a 48 38
57 43 38 35 37 30 46 4e 4c 0a 00 00 00 fc 00 44
45 4c 4c 20 55 32 34 31 34 48 0a 20 00 00 00 fd
00 38 4c 1e 53 11 00 0a 20 20 20 20 20 20 01 52
02 03 1f f1 4c 90 05 04 03 02 07 16 01 14 1f 12
13 23 09 07 07 65 03 0c 00 10 00 83 01 00 00 02
3a 80 18 71 38 2d 40 58 2c 45 00 0f 28 21 00 00
1e 01 1d 80 18 71 1c 16 20 58 2c 25 00 0f 28 21
00 00 9e 01 1d 00 72 51 d0 1e 20 6e 28 55 00 0f
28 21 00 00 1e 8c 0a d0 8a 20 e0 2d 10 10 3e 96
00 0f 28 21 00 00 18 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 37
That file missing is quite odd and could quite possibly cause some odd failures. Did your host computer have sufficient space from the JetPack directory? From that location do you have spare space shown in “df -H /where/ever/that/is”? Does “sha1sum -c /etc/nv_tegra_release” show all ok?
I have been facing twice the xorg.conf file having disappeared. You can just copy xorg.conf.t186_ref:
sudo cp /etc/X11/xorg.conf.t186_ref /etc/X11/xorg.conf
Hmm…in several releases the base file is something like xorg.conf.t186_ref, and then a “/etc/systemd/” file exists which creates a symbolic link from the “.t186_ref” to just plain “xorg.conf”. I’m not sure what would cause the sym link to fail when that method exists, but you might run this command too just to explore what is going on:
<s>egrep -R /etc/systemd 'xorg.conf'</s>
# OOPS! Edit :P
egrep -R 'xorg.conf' /etc/systemd
Just conjecture, but an example of something which might interfere with this would be experimenting with a default run level, such as booting without X, and then going back to having X (perhaps reinstating the symolic link part of systemd would fail).
Another example of that failing would be a full rootfs.
If that ref copy does exist, then this would indeed be an exact copy of what is needed for the missing “/etc/X11/xorg.conf”. I would still be curious as to how it disappeared.
I haven’t been able to use your command, but using
grep -R xorg.conf /etc/systemd
I’ve only found /etc/systemd/nv.sh that makes xorg.conf to be a link to /etc/X11/xorg.conf.jetson_e for tx1 or any “$machine” = “jetson_e”, but nothing that would explain this on TX2.
I think the problem is indeed happening in shutdown or boot, as it was working fine before.
First time, I was editing xorg.conf, so I thought I was just a problem of sync’ing.
However, I’m pretty sure that it happened also a second time later when I had not tried to edit xorg.conf by myself.
In my case, the Ubuntu login screen was appearing with different colors (right side was more blue than usual), but I wasn’t able to open any session.
I have to say however that I’m running an unusual config and see sometimes problems at shutdown time.
Oops…corrected that command. Yes I reversed it.
That setup for sym linking is only on some releases (not sure which). Even with that in place it wouldn’t explain why his xorg.conf was missing. Possibly a full file system on the host during flash, not sure.
So, I seem to have:
/etc/systemd/nv.sh: sudo bash -c "ln -sf /etc/X11/xorg.conf.jetson_e /etc/X11/xorg.conf"
But I do not have a file called /etc/X11/xorg.conf.jetson_e.
The contents of /etc/X11/xorg.conf.t186_ref are:
# Copyright (c) 2015, NVIDIA CORPORATION. All Rights Reserved.
#
# This is the minimal configuration necessary to use the Tegra driver.
# Please refer to the xorg.conf man page for more configuration
# options provided by the X server, including display-related options
# provided by RandR 1.2 and higher.
Disable extensions not useful on Tegra.
Section “Module”
Disable “dri”
SubSection “extmod”
Option “omit xfree86-dga”
EndSubSection
EndSection
Section “Device”
Identifier “Tegra0”
Driver “nvidia”
Option “AllowEmptyInitialConfiguration” “true”
EndSection
sha1sum -c /etc/nv_tegra_release shows all as OK.
My explanation for the messed up xorg.conf is probably because I was playing with VirtualGL and TurboVNC (have since uninstalled both) to allow OpenGL apps to run over VNC or SSH.
@michele: Your /etc/X11/xorg.conf.t186_ref looks ok. If not yet done, you can just copy it to xorg.conf, reboot and it should be ok. You may confirm it is fixed now.
@Linuxdev (or anyone interested in this): I understand that lack of space for making rootfs on host prior to flashing can lead to such problems, however in my case this rootfs is about one year old on a SATA SSD and it has been working fine till some time ago, so it is unlikely to be related to host disk space. It has always been updated from apt.
In my case, with my current monitor, when this missing xorg.conf happened, I was seeing ubuntu login screen being blue on right side.
Yes, the space issue is just a long shot. It is easy to check though if a host ran out of space…basically zero effort and a big gain if it turns out to be true. On the other hand there are more possibilities for a symbolic link not showing, e.g., a non-Linux file system for the flash host’s “rootfs/” makes symbolic links impossible (for example, the Linux version of a symbolic link isn’t understood on VFAT or NTFS). So I’m just doing a lot of guessing since it is so rare to not have this file present (and I know you’re not one to use the wrong file system type, but some people do :P).
I suspect that the mentioned VirtualGL and TurboVNC experimentation was the actual cause. As you mention, the likely fix is to simply copy the xorg.conf.t186_ref to xorg.conf.