Display-Port-Adapter arbeiten morgens nicht

[Rüdiger Kupper]

Das Problem mit den Adaptern besteht leider weiter, heute funktionierten in 5.53 und 5.55 die rechten Monitore jeweils zunächst nicht. Ein- und Ausstecken des Adapter löste das Problem.

Hier brauchen wir eine Lösung, wir können nicht morgens jeweils einmal den Adapter ausstecken.

Ich habe gerade noch mal das BIOS durchgeschaut, ob es irgendwelche Power-Einstellungen gibt, habe aber nichts gefunden.

Ich habe in 5.55 den Adapter nun mal in Display Port 1 gesteckt statt 2. Vielleicht verhält er sich da ja anders …

[Rüdiger Kupper]

@bau: Haben wir einen Monitor, der einen Display Port hat und können wir den mal testweise dranhängen, um zu sehen, ob der das selbe Verhalten zeigt?

Dann wüssten wir, ob es ein Problem des Adapters ist (wie vermutet), oder ob vielleicht der Rechner selbst den DP nicht initialisiert?

[Rüdiger Kupper]

Möglicherweise verwandtes Problem:
​https://forum.manjaro.org/t/monitor-doesnt-detect-displayport-connection-if-its-turned-on-after-the-computer/73815

-> Kann es mit den Master-Slave-Steckdosen zusammenhängen? Vielleicht ist der Monitor noch aus, wenn das BIOS die Ports checkt?

[bau]

Da das ganze gestern bei dir auch bei einem Neustart funktioniert hat,
ist beim Booten irgendwo kein Strom drauf. Der Rechner ist dauerhaft unter Strom!

Da es jetzt in 5.55 reproduzierbar schon wieder so ist, werde ich mir den mal genauer ansehen.

[bau]

Ich war in 5.55 - das Problem ist nicht reproduzierbar!

Ich habe den Rechner

• einfach mal eingeschaltet
• vorher den Umschalter auf Visualizer gestellt
• direkt nach dem Einschalten den Umschalter auf Visualizer gestellt

in allen Fällen war nach dem Booten der zweite Bildschirm verfügbar.
Bei allen Tests war der Rechner aus, die Monitore und der Umschalter stromlos!

[bau]

Ich habe am Montag in 5.18 mit dem DP-Monitor gearbeitet - heute half mal wieder nur Aus/Einstecken
Was ist das komisches?
Ich habe den DP nun auch in Port 1 gesteckt.

[Rüdiger Kupper]

Heute wieder bekanntes Problem in 5.21. Ich stecke dort jetzt auch nach Port 1 um – falls das irgend etwas bringt.

[Rüdiger Kupper]

Ich habe zumindest einen Workaround, wenn der Adapter nicht geht: Rechner komplett runterfahren (so, dass es aus ist), dann neu anschalten. Das kann man tun, ohne einen Schlüssel für die Kiste zu brauchen.
Warmstart (Reboot) reicht *nicht*!

[Rüdiger Kupper]

Heute trat das Problem auf in 5.18, 5.20, 5.09. 5.18 scheint ein Raum zu sein, in dem es besonders oft passiert.

[Rüdiger Kupper]

Da bau auch einen komplett defekten Adapter gefunden hat, wäre ein Versuch, den Adapter in 5.18 gegen einen anderen auszutauschen – womöglich arbeiten manche der Dinger nicht richtig.

[bau]

Solcherlei Probleme kennt auch die LML:
​https://ask.linuxmuster.net/t/displayport-schwarzer-bildschirm/3745/19

Ich habe mal einen DP-Adapter gezogen (5.30):
​https://zefanjas.de/bildschirme-automatisch-spiegeln-hdmi

# udevadm monitor --environment --udev
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing

UDEV  [7923.312289] change   /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
ACTION=change
COMMENT=PCI device 0x8086:0x1912 (i915)
DEVLINKS=/dev/dri/by-path/pci-0000:00:02.0-card
DEVNAME=/dev/dri/card0
DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card0
DEVTYPE=drm_minor
HOTPLUG=1
ID_FOR_SEAT=drm-pci-0000_00_02_0
ID_PATH=pci-0000:00:02.0
ID_PATH_TAG=pci-0000_00_02_0
MAJOR=226
MINOR=0
SEQNUM=3588
SUBSYSTEM=drm
TAGS=:master-of-seat:uaccess:seat:
USEC_INITIALIZED=8526555
net.ifnames=0

Mal testen, was der Befehl

udevadm info -p /devices/pci0000:00/0000:00:02.0/drm/card0

bei einem Client mit schwarzem rechten Bildschirm ausgibt, normal ist:

P: /devices/pci0000:00/0000:00:02.0/drm/card0
N: dri/card0
S: dri/by-path/pci-0000:00:02.0-card
E: COMMENT=PCI device 0x8086:0x1912 (i915)
E: DEVLINKS=/dev/dri/by-path/pci-0000:00:02.0-card
E: DEVNAME=/dev/dri/card0
E: DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card0
E: DEVTYPE=drm_minor
E: ID_FOR_SEAT=drm-pci-0000_00_02_0
E: ID_PATH=pci-0000:00:02.0
E: ID_PATH_TAG=pci-0000_00_02_0
E: MAJOR=226
E: MINOR=0
E: SUBSYSTEM=drm
E: TAGS=:uaccess:seat:master-of-seat:
E: USEC_INITIALIZED=5557479
E: net.ifnames=0

[bau]

Neu einlesen der udev-Geräte siehe:
​https://wiki.ubuntuusers.de/udev/

Ich suche mir mal einen Rechner ohne DP-Adapter,
da wäre dann ein auszuprobieren

udevadm trigger 

eventuell auch ein

reload udev

[Rüdiger Kupper]

weyh beschreibt das Problem heute in 5.31.

[Rüdiger Kupper]

Replying to kup:

Da bau auch einen komplett defekten Adapter gefunden hat, wäre ein Versuch, den Adapter in 5.18 gegen einen anderen auszutauschen – womöglich arbeiten manche der Dinger nicht richtig.

bau hatte den Adapter schon getauscht, das war es also nicht :-(.

[Rüdiger Kupper]

Replying to bau:

Solcherlei Probleme kennt auch die LML:
​https://ask.linuxmuster.net/t/displayport-schwarzer-bildschirm/3745/19

Das Problem, dass das Erkennen von der Einschaltreihenfolge abhängt, beschreiben auch andere unabhängig von der LML. Das war eins der ersten Dinge, die ich bei uns getestet habe, doch ich konnte das bei uns nicht bestätigen: Es ist egal, in welcher Reihenfolge man Rechner und Monitor einschaltet, es funktioniert in der Regel.

Das ist also nicht unser Problem – außer, es tritt nur mit einer bestimmten Wahrscheinlichkeit auf.

Hier sind Vorschläge, was wir in 5.18 (dem Raum, bei dem das Problem am häufigsten auftritt), testen können:

1. Adapter tauschen: hatte keinen Effekt
2. Monitor tauschen
3. Monitor von der MS-Steckdose nehmen und immer am Strom lassen
4. Rechner tauschen
5. Andere Adapter besorgen (das wäre vielleicht eine der ersten Maßnahmen, um es möglichst schnell in den Griff zu bekommen).

Noch eine weitere Maßnahme: den rechten Monitor über DVI anschließen, dann sieht man dort zwar nicht das Elmo-Bild, aber vielleicht klappt das wenigstens stabil.

[bau]

Wie kommt das Bild dann auf den Beamer?

[Rüdiger Kupper]

Replying to kup:

Replying to bau:

Solcherlei Probleme kennt auch die LML:
​https://ask.linuxmuster.net/t/displayport-schwarzer-bildschirm/3745/19

Das Problem, dass das Erkennen von der Einschaltreihenfolge abhängt, beschreiben auch andere unabhängig von der LML.

Siehe comment:2 oben.

[Rüdiger Kupper]

@bau

Kannst Du bitte eine Mail an alle schreiben zum Workaround in comment:7? Die Kollegen fangen ziemlich deutlich an, sich zu ärgern, dass die Monitore nicht funktionieren. Jetzt haben wir immerhin etwas, was sie tun können. Doch sie müssen wissen, wie sie den Rechner wirklich komplett ausschalten und nicht nur schlafen legen (was typischerweise passiert, wenn man den Ein/Ausschalter drückt).

[bau]

Mail ist raus

[Rüdiger Kupper]

@bau: Glaubst Du, die Kollegen verstehen, was Du mit »IO-Button« meinst?

[Rüdiger Kupper]

Ich habe heute nach viel Probieren herausgefunden, wie man von ferne abfragen kann, ob der Monitor läuft oder nicht:

root@rechner-5-54:~# cat /sys/devices/"pci0000:00/0000:00:02.0"/drm/card0/card0-HDMI-A-{2,3}/enabled
enabled
disabled

• card0-HDMI-A-2 ist display port 1
• card0-HDMI-A-3 ist display port 2
• (und card0-HDMI-A-1 ist der DVI-Port, der muss immer laufen)

So kann ich z.B. sehen, dass an rechner-5-53 gerade der Monitor nicht geht:

root@rechner-5-53:~# cat /sys/devices/pci0000\:00/0000\:00\:02.0/drm/card0/card0-HDMI-A-{2,3}/enabled
disabled
disabled

Leider habe ich aber keine Möglichkeit gefunden, den Adapter zu beleben, wenn er nicht läuft. Ich fürchte auch, dass das gar nicht geht.

[bau]

Hervorragende Arbeit!
Damit können wir wenigstens aus der Ferne nachprüfen, ob der Adapter geht.
Workaround wäre dann: Herunterfahren und kurz darauf wieder einschalten.

[Rüdiger Kupper]

Wow. Mit diesem Test sehe ich, das von den 32 Rechnern in den Us insgesamt 8 ohne zweiten Monitor hochgefahren sind. Also jeder vierte!

[7] 17:18:14 [FAILURE] rechner-5-18 Exited with error code 1
[10] 17:18:14 [FAILURE] rechner-5-42 Exited with error code 1
[12] 17:18:14 [FAILURE] rechner-5-32 Exited with error code 1
[15] 17:18:14 [FAILURE] rechner-5-20 Exited with error code 1
[17] 17:18:14 [FAILURE] rechner-5-30 Exited with error code 1
[19] 17:18:14 [FAILURE] rechner-5-44 Exited with error code 1
[21] 17:18:14 [FAILURE] rechner-5-55 Exited with error code 1
[24] 17:18:14 [FAILURE] rechner-5-46 Exited with error code 1

[Rüdiger Kupper]

Aufruf war:

parallel-ssh -ih rechner-us "cat /sys/devices/pci0000\:00/0000\:00\:02.0/drm/card0/card0-HDMI-A-{2,3}/enabled | grep enabled" | grep "code 1"

In der Datei rechner-us stehen alle Rechner in den Us.

[Rüdiger Kupper]

Okay, das habe ich jetzt auch ausprobiert: Den neusten Hardware-Enablement-Stack installieren (aktueller Kernel und aktuelle X-Server). Habe ich eben auf den Rechnern ausgerollt und neu gestartet. Hat aber nichts genützt: 10 der 32 Rechner sind ohne Monitor gestartet.

[Rüdiger Kupper]

Die Fehlerrate ist mir viel zu hoch: 25%-31% Ausfälle morgens. Das können wir nicht jeden Morgen leisten.

[Rüdiger Kupper]

Vorschlag 1

Wir koppeln die rechten Monitore von der MS-Steckdose ab und versorgen sie dauerhaft mit Strom. Inzwischen habe ich die Einschaltreihenfolge wieder stärker im Verdacht.

Vorschlag 2

Wir besorgen andere Adapter.

Wir auch immer, mit dieser Fehlerrate können wir nicht arbeiten, wir müssen schnellstens eine Lösung finden.

[Rüdiger Kupper]

Für den Anfang würde ich vorschlagen, dass wir die MS-Steckdosen einfach ganz deaktivieren, um zu testen, ob die Einschaltreihenfolge wirklich ausschlaggebend ist. Wenn ich mich recht erinnere, geht das mit einem langen Druck auf den Knopf der Steckdose.

[Rüdiger Kupper]

Ich rudere gerade gedanklich zurück:
Wieso brechen wir uns hier einen ab, um die Rechner und ihre Peripherie nachts stromlos zu schalten?

• Weil wir den Strom von den Stadtwerken bekommen, und die verteilen den üblichen Mix, der nach wie vor großenteils auf Atomstrom beruht (oder?)
• Würde uns die Stadt mit Energie aus regenerativen Quellen versorgen, dann gäbe es dafür keinen Grund.
• Anstatt unsere äußerst winzige Arbeitszeit dafür zu investieren, mit dem schädlichen Strommix der Stadtwerke umzugehen, sollten doch lieber die Stadtwerke grüne Energie liefern.

Wir geben das Stromproblem also nach oben zurück. - Das scheint mir langfristig eh das einzig Sinnvolle.

[Rüdiger Kupper]

Oder wir wechseln zu einem anderen Stromanbieter, bei meinem Privathaushalt habe ich das ja auch gemacht.

[Rüdiger Kupper]

@Jens

Wenn wirklich die MS-Steckdosen das Problem verursachen, dann haben wir damit schon Stunden über Stunden von Arbeitszeit verschwendet. Auch in 5.13. habe ich schon viele Stunden investiert, um zu verstehen, warum die Rechner nicht richtig starten und das dann auf die MS-Steckdosen zurückgeführt. (Kleiner Hinweis: In 5.13 habe ich deshalb alle MS-Steckdosen deaktiviert.) Wer ist denn hier in der Verantwortung? Wir, weil wir für die allseits so geschätzte Digitalisierung Strom verbrauchen, oder unser Schulträger, weil er uns schmutzige Energie liefert?

[Rüdiger Kupper]

Überschlag halt mal, wie viel wir für Hardware (Master-Slave-Steckdosen, Kabel, …) ausgegeben haben und unsere darin investierte Arbeitszeit (bin nicht auf dem aktuellen Stand, doch vor ein paar Jahren habe ich bereits ca. 23€/h berechnet), das mal Personen im Netzwerkteam – wir viel Geld wurde hier in den letzten, sagen wir mal, fünf Jahren an unserer Schule verbrannt? Und hätte uns mit eben diesem Geld nicht die Stadt sorgenfrei mit regenerativer Energie beliefern können? Dann hätten wir die gleiche Energie in die Modernisierung der Schule investiert.

[bau]

Immerhin hatten wir sogar mal eine KlimaCaptain-veranstaltung an der Schule.
Ich denke, wir können nicht einfach gedankenlos Strom verpulvern.
Äußerst ärgerlich finde ich das monetäre Argument - Geld darf eigentlich nicht die Welt regieren - tut es aber leider.

Wenn aber der rechte Monitor funktioniert, wenn dieser nicht in der MSSteckdose steckt (ist noch nachzuweisen), dann stecken wir den halt dauerhaft ein. Eventuell folgen dann aber noch der VGA-Umschalter und der Splitter, die mit Ausschaltern des Rechners auch stromlos sind.

[Rüdiger Kupper]

Ja, lass uns das mal prüfen. Parallel können wir ja auch noch mal ein anderes Adaptermodell ausprobieren.

[bau]

Problem beim Testen ist halt, dass sich das ziemlich zufällig verhält. Ich habe am Donnerstag und gestern Stunden damit zugebracht, einen Zusammenhang herauszufinden - es war aber keiner feststellbar.
Zu einem sinnvollen Test benötigen wir eine Automation an mehreren Testrechnern

• Zustand wie jetzt
• Monitor dauerhaft am Strom
• Umschalter dauerhaft am Strom (also USB am Rechner eingesteckt)
• Splitter dauerhaft am Strom (Netzteil erforderlich)

-> Einschalten per Script - testen - herunterfahren und das Ganze von Vorne.

[Rüdiger Kupper]

Am Freitag konnte ich in 5.53 jedenfalls den Zustand herstellen, indem ich das Stromkabel des rechten Monitors gezogen habe, dann den Rechner eingeschaltet, dann das Stromkabel wieder eingesteckt (also: Monitor geht nach dem Rechner an). Allerdings musste ich es zwei mal machen, beim ersten Mail hat der Monitor dennoch funktioniert.

Das ist eine der blödesten Eigenschaften dieses Problems, dass es offenbar statistisch auftritt. Zum Glück gibt es dafür aber einen Namen: Wir haben es hier ganz offenbar mit einem Mandelbug zu tun.

​https://www.techopedia.com/definition/31977/mandelbug

[Rüdiger Kupper]

Auch das hat leider nichts gebracht: Den gdm3-Greeter von Wayland auf XOrg umstellen. Keinerlei Effekt. Ich glaube nicht, dass wir softwareseitig irgend etwas an dem Problem tun können.

Immerhin das hat es gebracht: Das Image hat jetzt den neusten "Hardware Enablement Stack". Vielleicht laufen ja jetzt die USB3-Platten der Kollegen.

[bau]

OK - das ist ja schonmal ein Hinweis: Wenn Monitor nicht an, dann geht DP-Adapter nicht.
Was ich noch überlegt habe: Was passiert, wenn wir Port (1) und (2) vertauschen. Dann geht zuerst der Visualizer an den Start, mal sehen, was passiert, wenn der Adapter beim Umschalten quasi ein HotPlug macht. Dann ist der Monitor ja auf jeden Fall mit Strom versorgt.

[Rüdiger Kupper]

Replying to bau:

OK - das ist ja schonmal ein Hinweis: Wenn Monitor nicht an, dann geht DP-Adapter nicht.

Aber auch nicht immer. Beim ersten Mal hat es ja funktioniert. Aber vielleicht war die Steckdose da auch nicht lang genug aus. Es gibt leider ziemlich viele Faktoren.

Was ich noch überlegt habe: Was passiert, wenn wir Port (1) und (2) vertauschen. Dann geht zuerst der Visualizer an den Start, mal sehen, was passiert, wenn der Adapter beim Umschalten quasi ein HotPlug macht. Dann ist der Monitor ja auf jeden Fall mit Strom versorgt.

Könnte sein, dass das funktioniert. Ich würde vorschlagen, wir stellen einen der Faktoren aber erst einmal komplett ab: Die MS-Steckdosen lassen sich auf Dauerbetrieb stellen (ich glaube, man musste den Knopf 10s drücken). In 5.13 musste ich das ja auch tun – was war denn da eigenltich der Grund?

[Rüdiger Kupper]

Ah, in 5.13 haben sich einige der Steckdosen trotz laufendem Rechner immer wieder abgeschaltet. Vielleicht sind auch diese Steckdosen der eigentliche Schwachpunkt?
Haben wir die Dosen eigentlich korrekt "belehrt"? Bei denen muss die Leistungsschwelle für das Einschalten der Slave-Steckdosen ja stimmen. Vielleicht beeinflusst das den zeitlichen Verlauf?

Das könnten wir ja mal ausprobieren, z.B. in 5.18, der Raum ist ja fast immer dabei.

[lehm]

Soweit ich weiß haben die wir gar nicht belehrt, sondern direkt verbaut? Ich habe ein wenig den Faden verloren, funktionieren beide Bildschirme zuverlässig, wenn man die Master-Slave-Funktion deaktiviert, beide Monitore also immer am Netz hängen?

[bau]

Ich habe langsam den Verdacht, dass das ziemlich krasser Zufall ist ob der Bildschirm tut oder nicht.

• Zuverlässig tut aktuell nur der Hotplug (Adapter raus und wieder rein).
• Einigermaßen sicher sind wir, dass ein Herunterfahren des Rechners und gleich wieder einschalten zu einem funktionierenden Zustand führt (zumindest gibt es bislang kein Gegenbeispiel)
• Reset reicht anscheinend nicht aus

Die MS Steckdosen sind herstellerseitig vorkonfiguriert und tuen normalerweise out of the box. Bei manchen Räumen musste sie zusätzlich angelernt werden (Warum? Keine Ahnung!).

[bau]

Test in 5.18:

• Rechner war heute, 12 Uhr aus
• Kein zweiter Monitor nach dem Einschalten
• HotPlug: zweiter Monitor sofort da
• Heruntergefahren - VGA1 und VGA2 vertauscht
• Hochgefahren: Visualizer iat auf zweitem Monitr/Beamer
• Umschalten - Hotplug hat funktioniert
• Ausschalten

Mal sehen, wie das nach längerem Ausschalten aussieht.

Nach etwa 30 Minuten komplett ausgeschaltet: Gleiches Verhalten wie oben beschrieben.

Heute morgen (19.5.): Gleiches Verhalten wie oben beschrieben. :-)
Das ist ja schon fast nach Erfolg aus.
20.5.:

root@rechner-5-18:~# cat /sys/devices/pci0000\:00/0000\:00\:02.0/drm/card0/card0-HDMI-A-{2,3}/enabled
enabled
disabled

So langsam könnte man Hoffnung auf Erfolg haben :-)

[Rüdiger Kupper]

Replying to lehm:

Soweit ich weiß haben die wir gar nicht belehrt, sondern direkt verbaut? Ich habe ein wenig den Faden verloren, funktionieren beide Bildschirme zuverlässig, wenn man die Master-Slave-Funktion deaktiviert, beide Monitore also immer am Netz hängen?

Haben wir noch nicht ausprobiert. Sollten wir aber machen.

[Rüdiger Kupper]

Ich habe jetzt in allen Klassenzimmern die Steckdosen auf Dauerbetrieb geschaltet. (Ausnahme: Doppelräume, 5.44, 5.21, die waren besetzt.) Auf diese Weise finden wir am schnellsten heraus, ob die Dosen das Problem mit verursachen.

[bau]

??? hast du ​http://paedml.kg-fds.de/trac/ticket/3473#comment:42 gelesen ???

[bau]

in 5.53 habe ich die VGA-Ports vertauscht
5.31: Bildschirm ging heute morgen nicht, Reboot (hilft normalerweise nichts) mit Umschalter auf Digitizer: zweiter Bildschirm war sofort da.

Ich zweifle doch sehr an der Theorie mit den MS-Steckdosen, da der rechte Bildschirm beim Einschalten zuerst einmal das gleiche anzeigt, wie der linke (BIOS-Meldungen), dann schwarz wird und während dem Booten entweder schwarz bleibt oder auftaut - und das recht fuzzy-logic.

In 5.18 und 5.53 ist das Ergebnis auf jeden Fall nicht mit einzubeziehen, denn dort sind VGA 1 / 2 vertauscht.

[bau]

aktueller Stand:
VGA1/2 getauscht: 15 18 21 44 53
MS/Steckdosen Dauer-AN: 01 02 03 04 05 06 07 08 16 17 19 20 22 29 30 31 32 33 40 41 43 45 46 54 55

#	beim ersten WakeUP	zweiter	dritter
01		HDD	HDD
02
03	HDD	HDD	HDD
04	HDD	HDD	HDD
05
06
07
08
15	HDD, MS lässt sich nicht auf Dauer stellen	HDD	HDD
16		HDD	HDD
17	HDD	HDD	HDD
18
19
20
21	MS lässt sich nicht auf Dauer stellen
22	hat nicht gebootet, BIOS umgestellt
29
30
31			HDD
32
33
40	HDD	HDD	HDD
41
43
44	MS lässt sich nicht auf Dauer stellen
45
46
53
54
55
#	alle mit zwei BS	alle mit zwei BS	alle mit zwei BS

Neuster Gag: HDDs werden vom BIOS nicht korrekt erkannt, GRUB kann dann nicht von der SSD booten (HDD).
Auch das Problem kommt relativ zufällig, bei einigen aber dann doch regelmäßig.
Fazit: Beides hilft zuverlässig: MS ausschalten oder VGA tauschen um das Timing-Problem zu beheben.

[bau]

ToDo:

• VGA 1/2 tauschen
• MS Steckdosen wieder aktiv schalten
• Bei den Rechnern mit HDDProblemen schauen, ob im BIOS was einzustellen ist, ansonsten Plattentausch versuchen.

[Rüdiger Kupper]

Replying to bau:

ToDo:

• VGA 1/2 tauschen
• MS Steckdosen wieder aktiv schalten
• Bei den Rechnern mit HDDProblemen schauen, ob im BIOS was einzustellen ist, ansonsten Plattentausch versuchen.

Das Festplattenproblem tritt dann doch häufiger auf als gedacht. Sehr unangenehm, denn der Rechner befindet sich dann in einem Zustand, in dem man ihn nicht über's Netz erreichen kann.
Das sind doch die selben Platten, die zuvor in den anderen Rechnern steckten? Dann muss es ja eher am BIOS der neuen Rechner liegen?

Bei den Steckdosen können wir noch probieren, ob es vielleicht hilft, sie richtig zu "belehren". Vielleicht wirkt sich die Schaltschwelle auf das Timing aus. Also beim zurückschalten so vorgehen:

1. Rechner *ausschalten*
2. Knopf auf der Steckdosenleiste gedrückt halten, bis die LED blinkt.
3. Warten, bis die LED von allein aufhört zu blinken.

Die Dose hat sich dann die Leistungsaufnahme des Rechners gemerkt.

Die Anleitung zur Dose habe ich übrigens in den Netzwerktauschordner gelegt (Tausch-Kollegium/_Fachschaften/Netzwerkbetreuung).

[Rüdiger Kupper]

Habe die Rechner grade noch mal aufgeweckt und bestätige, dass an allen der Monitor läuft.
Die Sache, dass der Adapter direkt nach dem Einschalten ja offenbar immer geht, dann aber später seinen Dienst versagt, reime ich mir folgendermaßen zusammen (ist aber reine Spekulation):

• Sobald der Adapter Strom bekommt, versucht er herauszufinden, ob und welcher VGA-Monitor angeschlossen ist. Vermutlich versucht er die EDID-Daten abzurufen. Wenn der Monitor erst mit leichter Verzögerung angeht (verursacht durch eine etwas spät schaltende MS-Steckdose), bekommt der Adapter keine Infos.
• Der Boot-Bildschirm funktioniert trotzdem, vermutlich, weil der in Standard-VGA-Auflösung läuft und das eine Art Fallback-Modus ist.
• Startet dann das Betriebsystem, möchte es auf hohe Auflösung umschalten und fragt die Display-Ports nach den möglichen Auflösungen der angeschlossenen Monitore. Hier gibt der Adapter dann nichts zurück, oder vielleicht die Info, dass er "nichts weiß".
• Daraufhin beschließt das Betriebsystem, dass es da keinen Monitor gibt.

Dort, wo Du die VGA-Kabel vertauscht hast, bekommt der Adapter dann die EDID-Daten der Dokumentenkamera und die scheinen irgendwie schneller da zu sein. Um da sicher sein zu können, müssen wir das aber wohl auch in allen Räumen testen.

Komfortabler wäres aber, wenn nach dem Hochfahren nicht zuerst die Kamera aktiv geschaltet ist, denn die ist dann ja ausgeschaltet, so dass man doch wieder ein schwarzes Bild auf dem Monitor hat. Gleichzeitig hat man aber den erweiterten Desktop, was viele Kollegen verwirren könnte, weil da schnell mal der Mauszeiger verschwindet.
Desktop als Default wäre also vorzuziehen. Vielleicht bewirkt ja das Dosen-Belehren etwas, allerdings habe ich nicht viel Hoffnung.

[bau]

Die Spekulation hört sich recht plausibel an.
Bei den Visualizern ist es so, dass die erstmal aus sind und das Signal des (nicht angeschlossenen) Laptops durchreichen. Der DP-Adapter erhält also keine Information und begnügt sich anscheinend damit. Wenn man dann auf den Monitor umschaltet akzeptiert der DP-Adapter offenbar den HotPlug.

Ich denke, das ist das kleinere Übel, denn diesen Zustand bekommen die Kollegen häufiger, nämlich wenn vorher ein Kollege mit seinem Laptop unterwegs war oder den Visualizer benutzt hat - dann steht der Umschalter auch vermeintlich falsch. Ich denke, da werden sie sich am ehesten dran gewöhnen.

Um die SSDs kümmere ich mich mal heute.

[bau]

Weiterbehanldung des HDD-Problems in Ticket #3485

[Rüdiger Kupper]

Bin gerade durch alle Us gegangen und habe die MS-Steckdosen wieder aktiv geschaltet (und gleichzeitig die Einschaltschwelle belehrt). Anschließender Test: Wieder 7 Rechner ohne Monitor :-(.

Also: VGA-Anschlüsse tauschen!

[Rüdiger Kupper]

Ich habe jetzt in allen Eckräumen und 5.55 VGA1/2 getauscht, so dass nach dem Einschalten zuerst die Kamera durchgeschaltet ist.

Interessanter Weise ist der HDMI-Port mit dem DP-Adapter nach dem Hochfahren dann auch "enabled" (woher bekommt der das denn mit?) Unser Remote-Test funktioniert also weiter, wir können von Ferne prüfen, ob der Adapter läuft.

TODO

In den übrigen Räumen in den Us ebenfalls VGA1/2 tauschen.

(Glücklicherweise muss man dazu nicht den festgeklebten Umschalter abreißen wie in 5.55 – hier brauchen wir noch mal etwas Klebeband). Einfach in der Kiste die beiden schwarzen zum Umschalter führenden Kabel vertauschen. Hatte nur keine Lust, das heute noch überall zu machen. Vielleicht mag jemand mithelfen.

[Rüdiger Kupper]

Für's Protokoll: VGA-Anschlüsse sind getauscht in

• 5.55
• 5.45
• 5.31
• 5.21 (war schon)
• 5.04

Es fehlen noch die Nicht-Eckräume (und natürlich die Doppelräume)

[Rüdiger Kupper]

Mit den Rechnern, an denen bau schon getauscht hatte (siehe comment:47) haben wir nun 9 Rechner mit getauschten VGA-Kabeln. Erster Test: Nach dem Hochfahren ist bei allen der DP-Adapter aktiv.

Püh, hoffentlich ist das die Lösung!

[Rüdiger Kupper]

Ich bin gerade durch die restlichen Klassenzimmer gelaufen und habe die VGA-Kabel vertauscht (außer Doppelräume und 5.44 (besetzt)).

Test: Nach dem Hochfahren ist an *allen* Rechnern der DP-Adapter aktiv :-D.

Ich teste heute Abend noch mal, wenn die Rechner längere Zeit aus waren.

[Rüdiger Kupper]

Test heute Morgen: Alle DP-Adapter laufen. Das scheint die Lösung zu sein.

TODO: Mail an Kollegen schreiben, die das geänderte Verhalten erklärt.

[Rüdiger Kupper]

Im komplett anderen Kontext habe ich das erfahren:

Man kann dem Linux-Kernel einen Parameter übergeben, der die Erkennung von Display-Adaptern übergeht und sie zwangsweise aktiviert oder deaktiviert.

Verweise:

• ​https://www.osadl.org/Single-View.111+M5f0e4909445.0.html
• ​http://trac.gateworks.com/wiki/linux/display
• ​https://unix.stackexchange.com/questions/187775/how-does-the-linux-kernel-initialize-console-graphics
• ​http://distro.ibiblio.org/fatdog/web/faqs/boot-options.html
• ​https://askubuntu.com/questions/344903/install-on-a-laptop-with-external-monitor-only

[Rüdiger Kupper]

Demnach hätten wir die ganze Umstöpselaktion vermeiden können mit dem Kernel-Parameter:
video=HDMI-1:e

[Rüdiger Kupper]

(Adapter HDMI-1 zwangsweise aktivieren)