Sofortige Wiederaufnahme des S3-Ruhezustands, wenn das Ethernet-Kabel angeschlossen ist

562
user19087

Das Problem:

  • Der Computer wird innerhalb von 5 Sekunden nach dem Suspend-Modus aus dem S3-Ruhezustand (Suspend-to-Ram) versetzt, wenn das Ethernet-Kabel angeschlossen ist

Hardware:

  • Intel E2180
  • Gigabyte P35-DS3L
  • Realtek RTL8111b (mit dem Modul r8169)

Software:

  • Ich habe das ACPI-Wakeup für alle Geräte deaktiviert /proc/acpi/wakeup
  • Kernel-Protokolle pro Dmesg sehen normal aus - kein Suspend-Treiber für den Treiber oder andere Probleme. Die Protokolle eines erfolgreichen Suspend (Ethernet-Kabel getrennt) und eines unterbrochenen Suspend (Ethernet-Kabels angeschlossen) sind gleich.
  • Bei S3 Suspend-to-Ram aktiviert der Kernel das ACPI-Wakeup für die PCI-e-Bridge. Ich vermute, das ist normal.
  • BIOS: USB-Maus- / Tastatur-Wakeup deaktiviert, Wake-On-Ring deaktiviert, Wake-On-PME aktiviert
  • ethtool berichtet, dass WOL auf ug eingestellt ist .

Ich hatte den Verdacht, dass ein fehlerhaftes Gerät kontinuierliche WOL-Pakete emittiert, aber Wireshark zeichnet keine WOL-Pakete auf, während der Computer eingeschaltet ist.

Dies tritt auch dann auf, wenn alle anderen Anschlüsse (USB) nicht verbunden sind (VGA / Ethernet bleibt erhalten).

Ich werde auch WOL-Funktionalität benötigen

Bearbeiten:

  • Das Deaktivieren von WOL auf der Netzwerkschnittstelle mit ethtool verhindert die sofortige Wiederaufnahme.
0
Was machst du mit dieser Maschine? Es ist sehr alt, es wird sicherlich nicht mehr unterstützt? Chopper3 vor 7 Jahren 0
Ich folge nicht, die Hardware wird noch von Linux unterstützt? user19087 vor 7 Jahren 0
Das mag der Fall sein, aber was ist mit dem Systemboard-Hersteller? Unterstützen sie es noch? Was ist der Anwendungsfall für dieses Setup? Chopper3 vor 7 Jahren 0
Medienserver, WOL, um Strom zu sparen, alle meine Remote-Apps unterstützen bereits WOL. Da das letzte BIOS-Update vor Jahren war, bezweifle ich, dass die Systemplatine immer noch Updates erhält. user19087 vor 7 Jahren 0
Was sendet das WOL-Paket / die WOL-Pakete? und warum ist es nicht 24 Stunden am Tag? Chopper3 vor 7 Jahren 1
Im Moment nichts, per Wireshark. Eventuell einige Remote-Apps, die das Senden von WOL unterstützen. Ich unterbreche den Mediaserver, wenn er nicht verwendet wird, um Strom zu sparen. user19087 vor 7 Jahren 0
Das Problem wurde auf das Modul r8169 beschränkt. user19087 vor 7 Jahren 0
Ist das eine Frage zu Hause? Chopper3 vor 7 Jahren 0
Ja. Aber ist es wirklich wichtig, ob sich der Server in einer häuslichen Umgebung befindet oder nicht? Wenn Serverfault nur bestimmte Hardware unterstützt, hätten Sie meine Frage sofort migriert, da ich meine Hardware anfangs veröffentlicht hatte. Die Antwort stellte sich als umweltunabhängig heraus. user19087 vor 7 Jahren 0
Bitte lesen Sie die Hilfeseiten für serverfault.com, wenn Sie können. Selbst die ersten Zeilen machen deutlich, warum Sie die falsche Site ausgewählt haben, auf der diese Seite veröffentlicht werden soll. Chopper3 vor 7 Jahren 0
Ja, danke, dass du meine Frage verschoben hast. user19087 vor 7 Jahren 0

2 Antworten auf die Frage

0
user19087

Es stellt sich heraus, dass dies ein Missverständnis der Schnittstelleneinstellungen des Kernels für Wake-on-Lan ist. Aus dem Handbuch von ethtool :

Sets Wake-on-LAN options. Not all devices support this. The argument to this option is a string of characters specifying which options to enable.  p Wake on PHY activity u Wake on unicast messages m Wake on multicast messages b Wake on broadcast messages a Wake on ARP g Wake on MagicPacket™ s Enable SecureOn™ password for MagicPacket™ d Disable (wake on nothing). This option clears all previous options.

Ich nahm an, dass die Unicast- oder Broadcast-Flags die Quelle des magischen Pakets einschränken würden, das heißt:

  • ug: nur aufwachen, wenn ein Unicast-WoL-Paket empfangen wurde
  • bg: nur aufwachen, wenn ein Broadcast-WoL-Paket empfangen wurde

Die Unicast- oder Broadcast-Flags stimmen jedoch mit beliebigen Unicast- oder Broadcast-Paketen überein . Was passiert eigentlich:

  • ug: wake, wenn ein Unicast-Paket empfangen wurde oder ein WoL-Paket empfangen wurde (Unicast oder Broadcast; spielt keine Rolle, solange der MAC übereinstimmt)
  • bg: wake, wenn ein Broadcast-Paket empfangen wurde oder ein WoL-Paket empfangen wurde (Unicast oder Broadcast; spielt keine Rolle, solange der MAC übereinstimmt)

Natürlich gilt die übliche Unicast-Einschränkung für die Unicast-Flags (u) und WoL (g): Unicast-Pakete können nur empfangen werden, wenn die MAC des Ziels noch in der ARP-Tabelle gespeichert ist.

0
Nicolas V

Ich habe das gleiche Mainboard und das gleiche Problem ... Sie waren ziemlich nahe daran, eine Lösung zu finden. Ändern Sie die Konfiguration der Netzwerkschnittstelle, so dass nur "magicpacket" akzeptiert wird. Vergessen Sie Multicast / Unicast ...

sudo ethtool -s eth0 wol g

Dies hat den Trick für mich getan, und als Bonus kann ich den Computer (mit Etherwake) aus dem Netzwerk aufwecken.

Verwandte Probleme