Drei 4K-Monitore mit 60 Hz an einem kompakten Thin Client: Unter RangeeOS 12 war das kein Thema. Nach dem Umstieg auf RangeeOS 13 blieb bei derselben Konfiguration plötzlich der dritte Bildschirm schwarz. Hinter dem knappen Fehler steckten am Ende zwei Effekte, die sich gegenseitig verstärkt haben. Hier zeigen wir, wie wir sie gefunden haben und was dagegen hilft.
Kurz gesagt: In RangeeOS 13 ist die IOMMU (Intel VT-d) standardmäßig aktiv, und der Grafiktreiber rechnet dann 5 % mehr Speicherbandbreite. Auf manchen Geräten wählt der Linux-Treiber an HDMI zusätzlich einen 4K-Modus, der mehr Bandbreite braucht. Das erste lässt sich per Konfiguration abschalten, für das zweite kommt eine Korrektur mit der nächsten RangeeOS-Generation.
Das Symptom
Beim Einrichten der drei Monitore bricht die Anzeigekonfiguration von RangeeOS 13 ab:
XRandR fehlgeschlagen: XRandR returned error code 1:
b'xrandr: Configure crtc 2 failed\n'„crtc 2“ ist die dritte Anzeige-Pipeline, also der dritte Monitor. Aufschlussreicher ist das Debug-Log des Intel-Grafiktreibers i915:
icl_find_qgv_points: No QGV points provide sufficient memory bandwidth 7230
for display configuration(3 active planes).Der Treiber prüft vor jeder Änderung, ob der Arbeitsspeicher genug Bandbreite für alle Bildschirme liefert. Bei unseren Geräten mit Intel Alder Lake-N liegt die Grenze bei 6505 MB/s. RangeeOS 13 kam auf 7230 MB/s, RangeeOS 12 mit denselben Monitoren auf 6400 MB/s.
Der Testaufbau: RangeeOS 12 und 13 mit Ubuntu nachgestellt
RangeeOS basiert auf Ubuntu LTS: RangeeOS 12 auf Ubuntu 22.04 mit Kernel 6.5, RangeeOS 13 auf Ubuntu 24.04 mit Kernel 6.17.
Für die Fehlersuche brauchten wir Systeme, auf denen wir frei messen, Kernel tauschen und Boot-Parameter ändern können. Deshalb haben wir zwei Testgeräte mit identischer Hardware aufgesetzt: eines mit Ubuntu 22.04 als Stellvertreter für RangeeOS 12, eines mit Ubuntu 24.04 als Stellvertreter für RangeeOS 13, jeweils mit genau dem Kernel der RangeeOS-Version. Die Ergebnisse haben wir anschließend auf einem echten RangeeOS-13-System gegengeprüft.
Ubuntu 22.04 lief mit drei 4K-Monitoren sauber, Ubuntu 24.04 brach mit Configure crtc 2 failed ab. Die Ursache lag also in der gemeinsamen Ubuntu-Basis und nicht in RangeeOS selbst.
Schon unter RangeeOS 12 war es allerdings knapp. Ein 4K-Bild mit 60 Hz braucht rund 2133 MB/s pro Monitor, drei Monitore kommen auf 6400 MB/s. Bis zur Grenze blieben nur 105 MB/s, gerade einmal 1,6 %.
Ursache 1: Die IOMMU ist jetzt standardmäßig aktiv
Unser erster Verdacht war eine geänderte Bandbreitenrechnung im Treiber. Der Vergleich des i915-Codes von Kernel 6.5 und 6.17 zeigte aber: Die Rechnung ist in beiden Versionen gleich.
Geändert hat sich die Kernel-Konfiguration. Ubuntu baut seine Kernel seit Version 6.8 mit CONFIG_INTEL_IOMMU_DEFAULT_ON=y. Die IOMMU (Intel VT-d) ist damit ab Ubuntu 24.04 und auch in RangeeOS 13 standardmäßig aktiv. In diesem Fall schlägt der Treiber auf neueren Intel-Grafikeinheiten pauschal 5 % auf den Bandbreitenbedarf auf. Die Stelle in intel_bw.c (Kernel 6.17):
if (DISPLAY_VER(display) >= 13 && i915_vtd_active(i915))
data_rate = DIV_ROUND_UP(data_rate * 105, 100);Aus 6400 werden so 6720 MB/s, und das liegt über der Grenze. Mit abgeschalteter IOMMU liefert Kernel 6.17 exakt dieselben Werte wie 6.5, und alle drei Monitore laufen.
Ursache 2: An HDMI wählt der Treiber den teureren 4K-Modus
Auf manchen Geräten trat der Fehler auch mit abgeschalteter IOMMU auf, dann mit 6885 MB/s. Der Grund liegt in der Modusauswahl, denn 4K mit 60 Hz gibt es in zwei Varianten: den sparsamen CVT-RB-Modus mit 533 MHz Pixeltakt (2133 MB/s) und den TV-Modus nach CEA mit 594 MHz (2376 MB/s), der 11 % mehr braucht.
Der i915-Treiber liest aus der Video BIOS Table (VBT), einer Konfigurationstabelle der Intel-Grafik, für HDMI eine Obergrenze von 297 MHz und hält sich strikt daran. Die 533-MHz-Modi verwirft er deshalb, obwohl die Monitore bis 600 MHz unterstützen. Übrig bleibt der 594-MHz-Modus, den HDMI als YCbCr 4:2:0 mit halbem Takt überträgt. Für die Bandbreite zählt trotzdem der volle Pixeltakt, denn die Grafik liest weiterhin das komplette Bild aus dem Speicher. Mit einem Monitor an DisplayPort und zwei an HDMI ergibt das:
- ohne VT-d: 2133 + 2 × 2376 = 6885 MB/s
- mit VT-d: 6885 × 1,05 = 7230 MB/s, genau der Wert aus der Fehlermeldung
Auffällig ist, dass dieselben Geräte unter Windows problemlos mit drei 4K-Monitoren laufen. Wir haben das Verhalten außerdem auf unterschiedlichen Geräten beobachtet. Es liegt also nicht an einem einzelnen Gerät, sondern daran, wie der Linux-Treiber diese Angabe der Grafikplattform auslegt. Im Test haben wir die Grenze auf 594 MHz angehoben: Der Treiber wählt dann an allen drei Ausgängen 533 MHz, der Bedarf sinkt auf 6400 MB/s, und alle drei Monitore laufen. Die Prüfung ist in Kernel 6.5 und 6.17 identisch und hängt damit nicht an der RangeeOS-Version.
Alle Werte auf einen Blick
| Konfiguration | Bedarf | Ergebnis |
|---|---|---|
| RangeeOS 12 / Kernel 6.5, 3× 533 MHz | 6400 MB/s | ✓ läuft |
| RangeeOS 13 / Kernel 6.17, VT-d aktiv (Standard), 3× 533 MHz | 6720 MB/s | ✗ Fehler |
| Kernel 6.17, IOMMU aus, 3× 533 MHz | 6400 MB/s | ✓ läuft |
| RangeeOS 13, IOMMU aus, HDMI max. 297 MHz | 6885 MB/s | ✗ Fehler |
| dasselbe mit VT-d (Standard) | 7230 MB/s | ✗ Fehler |
| HDMI-Grenze testweise 594 MHz, IOMMU aus | 6400 MB/s | ✓ läuft |
Die Lösung
VT-d-Aufschlag: Die IOMMU lässt sich in RangeeOS 13 per Konfiguration abschalten (intel_iommu=off). Wie das geht, beschreiben wir im KB-Artikel Dritter 4K-Monitor bleibt schwarz – IOMMU abschalten. Die Grafik verzichtet damit auf die DMA-Isolation, so wie unter RangeeOS 12. Auf Geräten, bei denen die HDMI-Grenze nicht greift, laufen damit wieder alle drei 4K-Monitore.
HDMI-Grenze: Für die kommende RangeeOS-Generation auf Basis von Kernel 7.0 haben wir eine Anpassung des i915-Treibers vorbereitet. Sie erlaubt es, die HDMI-Grenze aus der VBT gezielt pro Gerätemodell zu übergehen, sodass der sparsame 533-MHz-Modus dort verfügbar wird, wo er nachweislich funktioniert. Die Anpassung befindet sich derzeit in Build und Test.
Bewusst verzichtet haben wir darauf, die Bandbreitenrechnung einfach schönzurechnen. Der Speicher müsste trotzdem dieselbe Datenmenge liefern, und es drohen Bildstörungen.
Fazit
Der Fehler hatte keine einzelne Ursache. Ein geänderter Standard in der Ubuntu-Basis und eine strenge HDMI-Grenze im Linux-Treiber haben eine Reserve aufgezehrt, die schon vorher nur 1,6 % betrug. Dass RangeeOS auf Ubuntu LTS aufbaut, hat die Suche deutlich erleichtert: Auf offenen Testsystemen ließ sich der Fehler nachstellen, messen und eindeutig zuordnen.
Wenn Sie mehrere 4K-Monitore an RangeeOS 13 betreiben und den Fehler sehen, schalten Sie zuerst die IOMMU ab, wie im KB-Artikel beschrieben. Bleibt der Fehler danach bestehen, greift auf Ihrem Gerät die HDMI-Grenze. Dann hilft Ihnen unser Support weiter.