Ich würde meine Kiste gerne schlafen schicken, wenn ich sie
vorübergehend nicht brauche - Mint 19 bietet dafür unter Quit im
Hauptmenü Suspend an.
Das funktioniert auch, der Rechner schaltet alles ab, was er nicht
braucht, nur dummerweise wacht er dann sofort wieder auf.
cat /proc/acpi/wakeup | sort ergibt folgende Ausgabe:
1
Device S-state Status Sysfs node
2
EHC1 S4 *enabled pci:0000:00:1d.0
3
EHC2 S4 *enabled pci:0000:00:1a.0
4
GLAN S4 *disabled
5
HDEF S4 *disabled pci:0000:00:1b.0
6
P0P1 S4 *disabled
7
PEG0 S4 *disabled pci:0000:00:01.0
8
PEG1 S4 *disabled
9
PEG2 S4 *disabled
10
PEG3 S4 *disabled
11
PEGP S4 *disabled
12
PS2K S4 *disabled
13
PS2M S4 *disabled
14
PXSX S4 *disabled
15
PXSX S4 *disabled
16
PXSX S4 *disabled
17
PXSX S4 *disabled
18
PXSX S4 *disabled
19
PXSX S4 *disabled
20
PXSX S4 *disabled pci:0000:03:00.0
21
PXSX S4 *disabled pci:0000:04:00.0
22
RP01 S4 *disabled pci:0000:00:1c.0
23
RP02 S4 *disabled
24
RP03 S4 *disabled
25
RP04 S4 *disabled
26
RP05 S4 *disabled pci:0000:00:1c.4
27
RP06 S4 *disabled pci:0000:00:1c.5
28
RP07 S4 *disabled
29
RP08 S4 *disabled
30
UAR1 S4 *disabled pnp:00:06
31
XHC S4 *enabled pci:0000:00:14.0
Suspend müsste eigentlich S3 sein - dafür fehlen aber sämtliche
Vorgaben.
Was ist da faul?
Uhu U. schrieb:> Was ist da faul?
Das kann ich dir auch nicht sagen, aber soviel (Mint 19.1):
Drei verschiedene Hardwareplattformen, dreimal unterschiedliches
Verhalten.
Notebook Dell Latitude E6230: Es funktioniert, wie's soll. Aufwachen
allerdings nur per kurzen Druck auf die Power-Taste möglich.
HTPC Atom N370 auf NVidiaION: Schläft ein, bleibt auch im Schlaf,
allerdings für immer. Nur eine spezielle Manipulation schafft es
manchmal, das Teil wieder zu erwecken. 3 Sekunden Druck auf Power-Taste,
ganz kurz Loslassen, dann Powertaste nochmal antippen. Ist der erste
Druck oder die Pause zu lang, landet die Sache beim Aufwachen in einem
Reset oder einer Kernel-Panic.
Desktop mit Core2Duo E8500: Verhalten genau wie von dir beschrieben.
Witzig: benutze ich statt des GUI einfach die Sleep-Taste auf dem
Keyboard, dann schläft er ordentlich ein. Allerdings: wieder aufwachen
mittels Keyboard klappt nicht, aber immerhin zuverlässig mit einem
kurzen Druck auf die Power-Taste.
Sieht irgendwie nicht wie ausgereifte Software aus, zumal alle drei
Hardware-Plattformen nicht gerade taufrisch sind. Insbesondere ärgerlich
ist das mit dem HTPC. Das hat da schonmal alles hervorragend
funktioniert, ich konnte den sogar mal per X10-Funk-FB in den
Hybernate-Zustand schicken (also S5!) und auch sauber wieder daraus
erwachen lassen. Das war so ungefähr bei Ubuntu 10.04. Seitdem hat nach
und nach immer weniger von dem Powermanagement-Kram funktioniert.
Irgendwann habe ich es dann aufgegeben, da hinterherzufrickeln. Die ein
bis zwei Mal, die ich das Teil in der Woche benutze, kann ich auch
hinlaufen und einfach auf den Knopf zum Einschalten drücken.
c-hater schrieb:> Sieht irgendwie nicht wie ausgereifte Software aus, zumal alle drei> Hardware-Plattformen nicht gerade taufrisch sind.
Dass es nicht auf jeder Hardware funktioniert, ist bekannt - das liegt
aber weniger an der Linux-Software, als am BIOS oder UEFI des Rechners,
der das unterstützen muss.
Der Rechner, auf dem ich das Problem mit Mint 19 habe, kann es - unter
Mint 17 hat es so lange einwandfrei funktioniert, bis irgend ein Update
dem ein Ende gemacht hat.
Uhu U. schrieb:> Der Rechner, auf dem ich das Problem mit Mint 19 habe, kann es - unter> Mint 17 hat es so lange einwandfrei funktioniert, bis irgend ein Update> dem ein Ende gemacht hat.
Genau das ist, was ich sage. Extrembeispiel für den "bit-rot" ist halt
der HTPC. Da hat, wie gesagt, vor vielen Jahren alles wunderbar perfekt
funktioniert. Mit den Updates kamen nach und nach die Probleme. Erst
ging Aufwecken aus S5 per FB nicht mehr, dann ging S5 überhaupt nicht
mehr. Fast gleichzeitig auch nicht mehr S4. Dass inzwischen auch S3
nicht mehr geht, hatte ich garnicht mitbekommen, erst durch die von
deinem Posting angeregten Tests haben mir das gezeigt.
> das liegt> aber weniger an der Linux-Software, als am BIOS oder UEFI des Rechners,> der das unterstützen muss.
Ach watt, das ist doch Unsinn. Das BIOSe aller drei Kisten haben sich
doch schon sehr lange nicht mehr geändert, speziell das des HTPC
(BIOS-Date aus 2009) dürfte immer noch exakt das sein, was schon zu
Ubuntu10.04-Zeiten auf der Kiste gewerkelt hat. Es ist natürlich gut
möglich, ja sogar recht wahrscheinlich, dass die ACPI-Tabellen von dem
Ding mehr oder weniger kaputt sind. Aber dann waren sie das auch vor 10
Jahren schon und es ging TROTZDEM. Das ist der Punkt.
Das hilft mir aber alles nicht, das Problem los zu werden.
Die Kiste geht ja offensichtlich in S3, nur bekommt sie von irgendwoher
sofort wieder das Wecksignal.
Die Frage ist, woher und wie man das unterdrücken kann.
Die Steuerung geht über /proc/acpi/wakeup, aber dort steht nichts von
S3.
Uhu U. schrieb:> Die Kiste geht ja offensichtlich in S3, nur bekommt sie von irgendwoher> sofort wieder das Wecksignal.>> Die Frage ist, woher und wie man das unterdrücken kann.
Tja, nach den Beobachtungen an meinem Desktop würde ich sagen: von der
Maus. Denn wie gesagt: mit der Sleep-Taste am Keyboard funktioniert es,
wie es soll. Der eigentliche PM-Mechanismus scheint also in Ordnung zu
sein.
Das wird bestätigt durch einen Versuch an meinem Notebook. Einfach mal
eine USB-Maus angeschlossen und diese zur Bedienung des GUI benutzt
(statt des Touchpad, was ich normalerweise benutze) ergibt das gleiche
Fehlverhalten, wenn über das GUI in den Standby gewechselt werden soll.
Also: das Aufwach-Event kommt ziemlich sicher von einem Maus-Move.
Uhu U. schrieb:> Die Steuerung geht über /proc/acpi/wakeup, aber dort steht nichts von> S3.
Was da an Modi steht, ist jeweils der TIEFSTE Schlafmodus, für den das
Event überhaupt zum zum Aufwecken verfügbar ist.
Konfigurieren kannst du nur, ob das Event überhaupt zum Aufwachen führen
soll oder nicht.
D.h.: Modus S5, angegeben ist S4: dann kannst du Enabled haben oder
nicht, er wird nicht aufwachen. Oder Modus S3, angegeben ist S4: wenn
das Event enabled ist, wird er aus S3 aufwachen und auch aus S4, Wenn
disabled, dann weder aus S3 noch aus S4.
Soweit die Theorie...
Praktisch stimmt das zumindest manchmal nicht. Z.B. nicht bei meinem
HTPC. Da könnte lt. /proc/acpi/wakeup nur die Netzwerk"karte" und der
Power-Button das Teil aus S5 wecken. Aber ich habe es, wie gesagt auch
schon mal geschafft, dass ein per USB angebundener Empfänger für eine
X10-Funk-FB dazu in der Lage war.
Das war damals dadurch möglich, das ich für alles im Tree bis zu dieser
Node einfach nur explizit die Stromversorgung für S5 aktiviert habe.
Offensichtlich kommt es beim Aufwachen aus S5 (sofern von der Hardware
überhaupt unterstützt) nur noch darauf an, dass überhaupt irgendein
Interrupt generiert wird, scheißegal welcher.
Bei S4 und höher muss er aber wohl wirklich passen, d.h.: ab S4 aufwärts
greifen die Einstellungen von /proc/acpi/wakeup. Manchmal...
Es scheint, dass die Konfiguration der Stromversorgung der Komponenten
nicht korrekt berücksichtigt bzw. beim Einschlafen korrekt hergestellt
wird, so dass auch eigentlich disabelte Komponenten wakeups generieren
können.
Uhu U. schrieb:> Wo ist das denn beschrieben?
Eine zusammenhängende Darstellung der Sache kenne ich nicht. Aber
speziell im Zusammenhang mit HTPC-Lösungen (VDR, MythTV usw.) findet man
unendlich viele Einzelinfos zum Thema.
Thread beobachten
Seitenaufteilung abschalten