Category Archives: Hardware, Treiber

Beiträge zu der von mir eingesetzten Hardware

Problem mit Nvidia Treiber NVIDIA-Linux-x86_64-367.35, ssh -X und KDE/QT5-Anwendungen

Posted on by

Manchmal erlebt man mit Linux Dinge, die glaubt man erst gar nicht. Die anschließende Analyse hält einen dann vom produktiven Arbeiten ab – und das Problem entpuppt sich letztlich als eines, das durch einen neuen Treiber induziert wurde. (Nicht, dass das unter MS Win anders wäre ….) Um anderen Betroffenen ein wenig Arbeit zu sparen, deshalb hier ein kurzer Hinweis zum aktuellen Nvidia-Treiber:

Der proprietäre Treiber NVIDIA-Linux-x86_64-367.35 ist mit Vorsicht zu genießen. Er verursacht offenbar unter bestimmten Umständen Segmentation Faults – im Besonderen bei Remote-Verbindungen per “ssh -X” auf den Host, auf dem der Treiber installiert ist.

Ich schildere hier kurz die Probleme, die bei mir aufgetreten sind – siehe aber auch https://devtalk.nvidia.com/default/topic/952373/linux/367-35-driver-fedora-24-glx-segmentation-faults/.

Das Problem

Der Treiber NVIDIA-Linux-x86_64-367.35 wurde bei mir auf einem Opensuse Leap 42.1 Host installiert. Auf diesen Host muss ich manchmal von anderen Systemen aus über “ssh -X” zugreifen. Ein solcher SSH-Client ist ein Laptop mit einem Optimus-System, auf dem der Intel Driver i915 für das prozessor-interne Grafik-Device Intel HD Graphics 4000 läuft. (Die auch vorhandene Nvidia-Karte wird nur wenn nötig über Bumblebee aktiviert). Folgende Schritte führen reproduzierbar ins Nirwana:

1) Man öffnet vom Laptop eine “ssh -X”-Sitzung auf dem Opensuse Leap System.
2) In der geöffneten Shell startet man bestimmte KDE Anwendungen, die QT5 nutzen
=> segmentation fault

Wann tritt der Bug nicht auf:

  • Der Bug tritt nicht auf für KDE-Anwendungen, die QT4 verwenden.
  • Der Bug tritt nicht auf für normale simple X11-Anwendungen oder GTK-Anwendungen wie Firefox.
  • Der Bug tritt aber interessanterweise auch nicht auf, wenn ich Verbindungen von anderen Systemen mit Opensuse 13.1/13.2 oder Opensuse Leap 42.1 aufnehme, auf denen selbst (ältere) Nvidia-Treiber installiert sind. Was immer das nun bedeuten mag ….

Workaround

Der Bug tritt auch nicht auf, wenn auf dem Opensuse Leap 42.1-System der ältere Treiber NVIDIA-Linux-x86_64-361.42 installiert wird. Zwischenversionen von Nvidia-Treibern habe ich (noch) nicht getestet.

Es sieht also danach aus, dass zwischen den angegebenen Treiberversionen etwas Seltsames passiert ist. Wieder mal zeigt sich, dass man mit (proprietären) Grafikkarten-Treibern aufpassen muss – das Aktuellste ist nicht immer das Beste.

Linux-Namensgebung für physikalische Netzwerk-Devices

Posted on by

Opensuse nutzt ja seit längerem “systemd”. Zwei der größten Veränderungen, die damit einhergingen, war die intensive Nutzung von “udev” durch “systemd” im Rahmen des Systemstarts und eine resultierende Veränderung der Namensgebung für physikalische Devices – u.a. Netzwerkdevices. Alles unter dem Schlagwort “predictable device names”.

Einen großen Einfluss hatte das u.a. auf Netzwerk-Devices: An die Stelle der alten NIC-Bezeichnungen “eth0”, “eth1”, etc. traten dann auf meinem Desktop-System z.B. so illustre Ausdrücke wie “enp8s0”, “enp9s0” oder noch komplexere Namen.

Aus den netzwerk-bezogenen “udev”-Regeln in den Dateien unter “/lib/udev/rules.d” alleine konnte ich mir bislang nicht erklären, wie es zur Festlegung der Device-Namen kam. “Die “udev”-Regeln betreffen ja etliche unterschiedliche Identifikations-Bezeichnungen. Ich hatte die Namensvergabe daher bislang einfach als Ergebnis einer für mich nicht nachvollziehbaren “udev/systemd”-Logik abgetan.

In der Auseinandersetzung mit virtuellen Bridges bin ich jedoch wieder über das Thema und inzwischen auch über zwei Artikel gestolpert, die das Ganze erklären. Ich möchte an dieser Stelle gerne auf die betreffenden Artikel hinweisen:

Der erste lesenswerte Artikel stammt von Major Hayden, der der Sache mal nachgegangen ist:
https://major.io/2015/08/21/understanding-systemds-predictable-network-device-names/

Besonders hilfreich fand ich in dem zitierten Artikel den Auszug aus “src/udev/udev-builtin-net_id.c”, der einem hilft eine Zugang zu einer Namensvergabe wie “enp8s0” zu finden:

  
 * Two character prefixes based on the type of interface:
 *   en -- ethernet
 *   sl -- serial line IP (slip)
 *   wl -- wlan
 *   ww -- wwan
 *
 * Type of names:
 *   b<number>                             -- BCMA bus core number
 *   ccw<name>                             -- CCW bus group name
 *   o<index>[d<dev_port>]                 -- on-board device index number
 *   s<slot>[f<function>][d<dev_port>]     -- hotplug slot index number
 *   x<MAC>                                -- MAC address
 *   [P<domain>]p<bus>s<slot>[f<function>][d<dev_port>]
 *                                         -- PCI geographical location
 *   [P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
 *                                         -- USB port number chain

 
Der zweite Artikel betrifft die Regeln, nach denen “systemd” verschiedene Varianten der Namensgebung bis zu einer endgültigen Entscheidung für ein Netzwerk-Device durchexerziert:

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Ich zitiere aus dem Artikel: 

  
The following different naming schemes for network interfaces are now supported by udev natively:

    Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
    Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
    Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
    Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
    Classic, unpredictable kernel-native ethX naming (example: eth0)

By default, systemd v197 will now name interfaces following policy 1) if that 
information from the firmware is applicable and available, falling back to 2) if that information from the firmware is applicable and available, falling back to 3) if applicable, falling back to 5) in all other cases. Policy 4) is not used by default, but is available if the user chooses so.

 
Aha – das kann ich nachvollziehen.

Wer sich mit diesem Wissen ausgestattet auch mal ansehen will, was “udev” auf einem System alles an Definitionen für gefundene Netzwerk-Devices hinterlegt, nutze das Kommando

“udevadm info -e”

mit Filtern. Auf meinem Desktop-System etwa finde ich: 

   
mytux:~ # udevadm info -e | grep net            
E: ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (Motherboard)
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
P: /devices/pci0000:00/0000:00:1c.4/0000:08:00.0/net/enp8s0
E: DEVPATH=/devices/pci0000:00/0000:00:1c.4/0000:08:00.0/net/enp8s0
E: ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (Motherboard)
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/enp8s0 /sys/subsystem/net/devices/enp8s0

E: ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (Motherboard)
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
P: /devices/pci0000:00/0000:00:1c.5/0000:09:00.0/net/enp9s0
E: DEVPATH=/devices/pci0000:00/0000:00:1c.5/0000:09:00.0/net/enp9s0
E: ID_MODEL_FROM_DATABASE=RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (Motherboard)
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/enp9s0 /sys/subsystem/net/devices/enp9s0

P: /devices/virtual/misc/network_latency
N: network_latency
E: DEVNAME=/dev/network_latency
E: DEVPATH=/devices/virtual/misc/network_latency
P: /devices/virtual/misc/network_throughput
N: network_throughput
E: DEVNAME=/dev/network_throughput
E: DEVPATH=/devices/virtual/misc/network_throughput
N: net/tun
E: DEVNAME=/dev/net/tun

P: /devices/virtual/net/br0
E: DEVPATH=/devices/virtual/net/br0
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/br0

P: /devices/virtual/net/lo
E: DEVPATH=/devices/virtual/net/lo
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: SUBSYSTEM=net

P: /devices/virtual/net/virbr0
E: DEVPATH=/devices/virtual/net/virbr0
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/virbr0

P: /devices/virtual/net/virbr0-nic
E: DEVPATH=/devices/virtual/net/virbr0-nic
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/virbr0-nic

P: /devices/virtual/net/virbr1
E: DEVPATH=/devices/virtual/net/virbr1
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/virbr1

P: /devices/virtual/net/virbr1-nic
E: DEVPATH=/devices/virtual/net/virbr1-nic
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/virbr1-nic

P: /devices/virtual/net/vmnet0
E: DEVPATH=/devices/virtual/net/vmnet0
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: INTERFACE=vmnet0
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/vmnet0

P: /devices/virtual/net/vmnet1
E: DEVPATH=/devices/virtual/net/vmnet1
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
nE: INTERFACE=vmnet1
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/vmnet1

P: /devices/virtual/net/vmnet2
E: DEVPATH=/devices/virtual/net/vmnet2
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: INTERFACE=vmnet2
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/vmnet2

 
(Der erfahrene Leser erkennt, dass hier neben physikalischen Devices qemu-Bridges und auch VMware-Bridges aktiv sind. Für entsprechende Devices werden im Zusammenspiel mit den Generatoren der Virtualisierungs-Tools offenbar Standardnamen vergeben, da eindeutige Vendor- oder “geographische” Bus-Bezeichnungen nicht ermittelbar sind.)

Mein Dank gilt den Verfassern der oben genannten Artikel, die zumindest bei mir eine Verständnislücke geschlossen haben.

Linux – Dell U2515H – questions regarding KDE adjustments and older graphics cards

Posted on by

Some months ago I wrote 2 blog articles about the use of (multiple) DELL U2515H screens on a Nvidia GTX750 TI graphics card on a Linux system.

Linux – Nvidia GTX 750 TI – Parallelbetrieb von 2 Dell U2515H mit 2560×1440 plus einem 1920×1200 Schirm
Linux – Nvidia GTX 750 TI – Dell U2515H – HDMI – 2560×1440 Pixel

Last week a reader, who had found these blog articles, asked me the following:

I am currently using a Dell U2412m with 1920×1200 resolution but I am planning to upgrade to a 2560×1440 and thought about the U2515H but I am a bit worried about how Plasma shows on such a high dpi panel. Do you have any issue with interface elements which are showed too small and are not tuneable?

Second thing I am a bit worried of my GTS 450 performance but I will upgrade my video card after the new nVidia series is launched.

I found these questions interesting and present my answers in form of this blog contribution.

Warning statement regarding older graphics cards

Before I get to the question regarding KDE and a high resolution screen as the DELL U2515H I want to make a warning statement:

The graphics card you want to use together with a Dell U2515H and the graphics card drivers MUST support high resolution HDMI (vers. 1.4, 2.0) or display port connections. Reason: The Dell U2515 does NOT provide any DVI connections!

Do not underestimate this topic for older graphics cards! Actually, I had very bad experiences in the past with a GTX 460 which provides a mini HDMI port: I never got a high resolution HDMI connection to run with this card (not under Opensuse 13.1/13.2). Despite high quality cables and in contrast to another system with a GTX 750 TI. And I really tried a lot of settings and driver versions until I gave up.

And note: Even the GTX 750TI required some effort and fiddling – but eventually it worked. This is the reason why I wrote about it.

So, if you have some money and want to avoid frustration with the DELL U2515H, I would suggest to buy a reasonable modern card which offers support for (several) display ports and/or high resolution HDMI. If gaming under Linux is not a topic (as in my case) but still some 3D applications or CUDA floating point operations are part of your work then presently a GTX 960 or the GTX 750 could be a reasonable alternative regarding the price-value relation. But look out for the number of ports supported – especially if you want to use several screens.

KDE and high resolution screens in general

It is quite clear that a screen resolution of 2560×1440 will significantly reduce the visible size of fonts and desktop elements scaled with font size. So, what you need is a very flexible scalability of fonts both for the desktop and window control elements as well as for applications you use.

The question whether Linux desktops as KDE are prepared for high resolution screens was also posed in an article with the title “Skaliert” (Scaled) published in the German “linuxuser” 10/2015. See http://www.linux-community.de/Internal/Artikel/Print-Artikel/LinuxUser/2015/10/Skaliert. Unfortunately, this article costs money to read it online. Actually, relatively small problems were described for KDE. This is very consistent with my own experience with both KDE 4.14 and KDE 5.x.

You can adjust almost all required basic font settings for the KDE desktop via KDE’s “systemsettings” and in addition most
applications offer scrollable and relatively seamless font scaling (e.g. via mouse scrolling). Playing around with font smoothing plus an enforcement of dpi resolution may pay off in case you care for smooth font displaying. (Actually I never had to apply any special contrast settings of the screen itself beyond standards for the screen to get a clear, but nevertheless smooth font display).

The spectrum of applications I primarily use consists of a mixture of QT and GTK applications:

KDE konsole and other terminal emulations, different types of graphical KDE file editors, different types of browsers (primarily FF and chromium), libreoffice, eclipse mars, aptana studio, SVN frontends, crossover with ms office applications, vmware with different types of guests, kvm with different types of guests, sound and multimedia applications, blender, etc., etc.

Almost all of my favorite applications offer internal font adjustment capabilities and the typical graphical elements of these applications scale seamlessly with font size. So, no reason to worry about KDE and its plasma desktop: In my opinion KDE is well prepared for high resolution screens.

A problem may, however, be the smooth integration of some GTK applications (as e.g. eclipse) into high resolution KDE, which is based on QT – but also there you have sufficient options with different GTK themes – and most of the problems I had were independent of the screen resolution and more GTK theme dependent. You may have to play around a bit with KDE’s settings for GTK integration – especially with the choice of the GTK design or GTK theme.

KDE and screens with different resolutions

A real problem in my opinion may result from a mixture of 2 screens with different (!) native resolutions. There is no way known to me to apply different font-settings to different screens on a KDE desktop comprising several screens in form of a Nvidia Xinerama combination.

As long as I used 2 screens – one with a resolution of 1920×1200 and one with 2560×1440 – I really suffered a bit from the display discrepancies regarding font size. Especially when I wanted to open several windows of one and the same application – as 2 windows of Eclipse – on both screens or whenever I wanted to stretch one application (e.g. VMware) over the 2 screens. You may try to find compromises – but it will never be perfect.

However, in my present daily work with 3 screens – 2 with 2560×1440 and 1 with 1920×1200 – the different display of font sizes may become even an advantage: Just by moving an application to the lower resolution screen you get a better view on details. (But I admit, this is pure luxury, not only for development work.)

Nevertheless it would be fun if KDE in the future could provide a possibility to adjust font-sizes per screen in a Xinerama version.

Performance?

I do not know exactly how a GTS 450 graphics card performs. But my guess is that even for 2 screens (with 2560×1440) performance for the simple 3D effects of a plasma desktop should be no topic at all – even for this card. Actually, it is really frustrating that you cannot use high resolution HDMI with older graphics cards – despite the fact that the graphics card may support a combined resolution of 2 x 2560×1440 for DVI capable screens and provide a sufficient performance for it.

I should, however, mention that for three screens (2 x 2560×1440, 1x 1920×1200) my GTX 750 TI works constantly with high frequencies of both CPU and memory. The card never reduces this frequencies during normal use – so it will consume more electrical power than in a 2 screen situation. For 2 screens at 2560×1440 it always reduced frequencies to lower levels when only 2D applications were used on the desktop. However, despite constant high frequencies I never noticed any heat problem under normal conditions. The ventilators operate at basic speed and temperatures are between 36 and 40 &
deg; Celsius.

With high resolution 3D games you may have a different experience – but if I play (which is seldom) I never play with extreme resolutions. So, actually I do not know how high resolution games perform on a (3D) KDE desktop.

Summary

Regarding the use of KDE with the DELL U2515H in my opinion you need not worry about font scalability and performance. You should worry more about the support of high resolution HDMI and display ports by both the physical card and the drivers for older Nvidia cards. A combination of a DELL U2515H with a screen of lower resolution will lead to problems – as visible font sizes may differ significantly.

Remark, added 17.12.2015:
Meanwhile I had the chance to test a Nvidia GTX 960 from Gigabyte together with 2 DELL U2515H connected via display port and a 1920×1200 screen connected via DVI. Works without any problems. And I see no problems with native Linux 3D OpenGL games as Red Eclipse or Xonotic at high resolutions so far. Temperatures around 43° Celsius.