Sollte das Device
GLAN am Ende irgendein GbE-Adapter sein (einen anderen Namen, der an ein Netzwerk-Gerät erinnern würde, sehe ich nicht in der Liste - die Namen werden vom Hersteller in der DSDT festgelegt, wobei
GLAN ein gebräuchlicher für einen ebensolchen Adapter wäre)), dann darf der (nach der oben gezeigten Ausgabe) den PC aber nicht aus S4 holen. Ja, es gibt eigentlich bei Dir gar kein Gerät, was ein Aufwecken aus S5 bewerkstelligen könnte - das läßt mich daran zweifeln, daß Dein Mainboard das auch wirklich beherrscht. Auf einem (älteren) MacMini sieht der Eintrag für den GbE-Adapter (unter openSUSE Tumbleweed) hingehen so aus:
Rich (BBCode):
vidar:~ $ grep "^G" /proc/acpi/wakeup
GIGE S5 *enabled pci:0000:00:0a.0
und der kann dann - aber auch nur mit den passenden Einstellungen für den Netzwerk-Adapter per
ethtool - auch tatsächlich per WoL gestartet werden, solange er nur Strom hat - auch nach einem kompletten Power-Loss. Anhand Deiner Ausgabe oben würde ich nicht annehmen, daß dieses Gerät ÜBERHAUPT automatisch von S5 nach G0 wechseln kann - selbst anhand der RTC vermutlich nicht. Wobei fehlerhafte ACPI-Tabellen auch noch eine Erklärung sein könnten, dazu später.
Das "Testen" der verschiedenen Möglichkeiten mußt Du nun mal selbst übernehmen ... damit das WoL am Ende tatsächlich funktioniert, müssen die Einstellungen im BIOS und im OS dazu passen und das System (als Gesamtheit aus OS und BIOS) beim Herunterfahren auch die richtigen Einstellungen aktivieren. Egal, was das für ein Mainboard ist - das Handbuch dazu mußt Du Dir auch selbst suchen und ermitteln, ob die BIOS-Einstellung zum WoL TATSÄCHLICH auch das Aufwachen aus S5 betrifft.
Wenn das so wäre, sollte der PC ja IMMER per Magic-Packet geweckt werden können, solange er nur Strom hat - das sind aber in aller Regel "Fernwartungsfunktionen" (bis hin zum Einsatz der Intel Management Engine - IME), die auch Business-Computern vorbehalten sind (wo dann in der Nacht zentral irgendwelche Updates ausgespielt werden können) und die müssen auf Gaming-Mainboards nicht ebenso vorhanden sein. Das UEFI-BIOS der Apple-Geräte unterstützt das aber (s.o.) in aller Regel auch - wobei auch hier das verwendete OS noch jede Menge Mitspracherecht hat über das ACPI.
Wenn das OS die Einstellungen seinerseits passend setzt beim Herunterfahren (zumindest die, die es aus seiner eigenen Sicht sein sollten), dann muß das BIOS, um da noch diese Einstellungen "überstimmen" zu können, die entweder direkt beim ACPI-Aufruf ignorieren/ändern oder den "Abschaltbefehl" (der das System dann nach G2 schickt) noch einmal zum Anlaß nehmen, seinerseits die notwendigen Einstellungen (erneut) vorzunehmen.
Bei älteren BIOS-Versionen gab es noch einem Punkt "ACPI-aware OS" (oder ähnliches) - damit wurde dann die Programmierung der Sleep-Zustände komplett an das OS übertragen, egal was ansonsten noch im BIOS einzustellen war. Da interessierte die BIOS-Einstellung für WoL (sofern überhaupt vorhanden) dann auch nicht länger ... was das OS in Auftrag gab, wurde 1:1 so umgesetzt. Heute gibt es mit den ganzen UEFI-Implementierungen so viele unterschiedliche Möglichkeiten, daß man eben selbst probieren muß, was bei der eigenen Technik wirkt.
Der einfachste Test ist es schon mal, das aufzuweckende Gerät nicht wirklich "herunterzufahren", sondern nur in einem Stromspar-Zustand zu schicken, der max. bis S4 geht. Wenn das Gerät dann per Magic-Packet aufwachen kann, liegt es wohl doch daran, daß ein Aufwachen aus G2 gar nicht machbar ist. Wenn es dann (mit derselben Technik) vorher wirklich funktioniert haben sollte, dann hat da wohl das zuvor verwendete OS (so richtig schlau werde ich nicht aus dem oben Geschriebenen, WAS sich da nun geändert hat, daß es "plötzlich" nicht mehr funktioniert) von sich aus das Gerät nur in S4 geschickt beim "Herunterfahren" - das meinte ich oben, als ich schrieb, daß mit der Distro vermutlich ausreichend mangelnde Erfahrungen hier vorliegen (egal, auf welchem Zweig die basiert - die "Feinheiten" machen hier den Unterschied), um das wirklich sagen zu können.
Zumindest "im laufenden Betrieb" ist ja das Wecken durch
GLAN offensichtlich schon mal deaktiviert, wie man an Deiner Ausgabe sieht (das zu
ethtool Geschriebene solltest Du vielleicht auch noch einmal lesen und "abarbeiten") - wenn das nicht beim Übergang in einen der Stromspar-Zustände noch geändert wird, wird das Erwecken GAR NICHT funktionieren (zumindest nicht, solange nicht das BIOS mitarbeitet und das selbst übernimmt).
Den
wakeup-Status eines Gerätes kann man nebenbei bemerkt mit einem
echo [I]device [/I]> /proc/acpi/wakeup hin und her schalten - auch das wäre zumindest mal einen Versuch wert. Üblicherweise übernimmt heutzutage der
udevd (oder etwas ähnliches, ggf, auch der
systemd) beim Herunterfahren des Systems (oder auch beim Übergang nach G1) das Setzen der passenden Einstellungen - und wenn er (bzw. "das OS") das richtig macht, sollte man ihm nicht noch an anderen Stellen in die Parade fahren.
Man kann ja auch einfach mal per Skript dafür sorgen, daß beim Herunterfahren von MX-Linux (wenn die anderen Tests ergeben, daß das erfolgsversprechend sein könnte) der Wakeup-Status für
GLAN tatsächlich auch auf
enabled steht und ihn ansonsten noch ändern - vielleicht reicht das schon als "Nachhilfe". Ansonsten kann man ja auch selbst dafür sorgen, daß ein "Herunterfahren" eben in S4 endet und nicht in S5 - ein Unterschied hinsichtlich Stromverbrauch ist praktisch nicht existent.
Aber die verschiedenen Stellen, wo man da etwas einstellen kann, können sich ergänzen oder auch widersprechen (bzw. die Einstellungen wieder "überschreiben") - nicht ganz umsonst ist die vernünftige Konfiguration der Stromspar-Zustände über das ACPI immer noch eine der Schwachstellen von Linux - wobei da zu einem Gutteil die Hersteller schuld sind, weil die gerne mal mit unvollständigen/falschen ACPI-Tabellen auflaufen, solange nur ihre eigenen Tests mit Windows das richtige Ergebnis zeigten - das meinte ich weiter oben mit der Möglichkeit, daß die Anzeigen, die max. bis S4 gehen für alle Devices, auch durchaus fehlerhaft sein könnten.
Du wirst jedenfalls - wenn Du die "Diagnose" auf das Drücken des Buttons im FRITZ!OS-GUI und die Tatsache, daß der PC dann nicht angeht, reduzierst - auch durch ständiges "Probieren" nicht weiterkommen ... zumindest nicht durch wahlloses (denn systematisches Testen ist letztlich auch "Probieren"). Zunächst einmal solltest Du Dich auf eine Stelle festlegen, wo man das (sauber) konfiguriert - wie erwähnt, können dieselben Einstellungen an mehreren Stellen auch kontraproduktiv sein.
Wenn das BIOS tatsächlich das Aufwachen aus S5 unterstützen sollte (das findet man im Handbuch oder im Internet, denn das Mainboard ist vermutlich kein Einzelexemplar und es wird andere (Besitzer) mit ähnlichen Fragen geben), dann wäre das u.U. vorzuziehen, weil es (a) OS-unabhängig ist und (b) das System auch aus einem "tieferen" Schlafzustand holen kann. Wenn nicht, solltest Du das Ganze ausschließlich vom OS machen lassen.
Das heißt dann u.U. auch, die Einstellungen im BIOS ggf. wieder zu deaktivieren - wobei hier wirklich nur "Probieren" hilft, denn manchmal ist das auch (je nach BIOS) nur die "generelle Erlaubnis" und gar nicht das Programmieren der Interrupt-Controller. Hier kann man üblicherweise auch einfach testen, wie ein Herunterfahren das System hinterlassen hat - ist das System in S4 und kann geweckt werden, aber nach einem Aus- und Wiedereinschalten der Stromversorgung des PCs funktioniert auch das nicht mehr, dann hat eben das zuletzt verwendete System per ACPI alles korrekt eingestellt, aber das Unterbrechen der Stromversorgung diese "gemerkten Einstellungen" auch vergessen lassen.
Absolut gilt aber auch das nicht - denn es gibt bei vielen Mainboards ja auch die Einstellmöglichkeit, das System nach einem "Power loss" ausgeschaltet zu lassen, es einzuschalten oder den letzten Zustand wiederherzustellen und dafür muß dieser letzte Zustand dann auch irgendwo gespeichert sein ... daneben KANN durchaus auch noch die letzte WoL-Einstellung liegen und ebenfalls "restauriert" werden, wenn der PC nicht gleich eingeschaltet werden soll. Das hängt dann wieder vom Mainboard und dessen BIOS ab.
Das ist jedenfalls im Ganzen ein sehr komplexes Thema und mit dem einfachen Aktivieren oder Deaktivieren einer Option irgendwo in einem OS oder dem BIOS ist es nur selten auch wirklich schon erledigt. Auch unter Windows muß man dazu meist noch im Geräte-Manager (oder mit dem passenden CLI-Programm
powercfg) die richtigen Optionen setzen oder zumindest überprüfen, ob die anhand der ACPI-Daten schon korrekt eingestellt wurden.
Wenn Du hier tatsächlich die Linux-Distribution gewechselt hast (ansonsten verstehe ich nicht, WAS sich geändert haben soll), dann ist das nicht wirklich ein Mysterium, warum das dann "plötzlich" nicht mehr funktionieren könnte - jede Distro setzt nun mal unterschiedliche Schwerpunkte und damit muß man dann selbst "nacharbeiten", wenn das eine andere nicht ebenso gut beherscht, wie die zuvor genutzte. Wenn das alles erst mit der zusätzlichen Wakeup-Einstellung für Dein USB-Keyboard "zerstört" wurde (das
XHC dürfte der USB-Hub sein, der nach der Liste oben Dein System aufwecken kann), dann solltest Du das einfach wieder deaktivieren (im BIOS) und versuchen, das MX-Linux so zu konfigurieren, daß es ein Aufwecken auf den Tastendruck hin unterstützt. Wenn das zusammen mit WoL gar nicht funktionieren will, mußt Du vielleicht auch einfach auf eines von beiden verzichten - Du wärst auch unter Linux nicht der Erste, der in diesen sauren Apfel beißen muß.
Das reicht auch erst mal an Text als Erklärungsversuch ... das Ermitteln, woran es letztlich tatsächlich scheitert (im Kontrast zu dem reinen Konstatieren, daß es halt nicht geht), funktioniert nur bei Dir, denn dazu braucht es auch die passende Hardware.
