ACPI mit S3 funktioniert nicht

sandreas

Well-Known Member
Hallo zusammen,

bevor ich einen FreeBSD Bug-Report erstelle, wollte ich zunächst mal hier nachhören, ob jemand mir vielleicht helfen kann.

Zum Thema:

Ich würde gerne ACPI nutzen, um mein FreeNAS-Gerät in den Standby zu schicken (S3 - suspend to ram). Ich habe das ganze über folgenden Befehl versucht:

Code:
acpiconf -s 3


Das ganze funktioniert auch, allerdings kann ich den PC danach nicht mehr hochfahren, egal ob ich es über Wake-on-LAN versuche oder über den Einschalter am Knopf.

Daraufhin habe ich mich auf die Suche nach dem Fehler begeben und folgende Seite entdeckt:
http://www.freebsd.org/doc/de/books/handbook/acpi-debug.html

Hier meine Ein- und Ausgaben zum debuggen:
http://pastebin.com/FCwe0s0w

Was kann das "out of inodes" denn sein?
 
Das heißt eigentlich es gibt zu viele Dateien im Dateisystem. Was ist denn mit /data?

Nur was hat python damit zu tun? Ist das irgendwas mit ZFS?

Und wie hast du das gemacht, wenn das System nicht mehr aufwacht?
 
@kamikaze: Danke für die fixe Antwort.

Das heißt eigentlich es gibt zu viele Dateien im Dateisystem. Was ist denn mit /data?
Data ist soweit ich weiß unter FreeNAS die Datenpartition, auf der Daten persistent gespeichert werden. Alles andere läuft denke ich auf readonly oder in einer RAMDISK.

Nur was hat python damit zu tun?
Das Webinterface von FreeNAS ist in Python geschrieben. Ich nehme an, dass es damit zu tun hat. Python wird als Grundlage für alle WebInterface-Aktionen genutzt. Vielleicht gibt es hier einen Fehler in der Implementierung. Obwohl ein Konsolenbefehl über SSH ja eigentlich nicht zu einem Python-Fehler führen sollte. Vielleicht gibt es einen in Python geschriebenen Daemon, der den Zustand der Partitionen überwacht.


Ist das irgendwas mit ZFS?
Ich werde mal recherchieren, ob FreeNAS die data-Partition als ZFS anlegt. Könnte sein, dass ein 4GB USB-Stick da Probleme macht.


Also du gehst davon aus, dass es nicht mit FreeBSD zu tun hat, sondern mit FreeNAS / ZFS bzw. dessen Struktur? Weil dann gehört der Bug-Report ja eher in die Ecke FreeNAS.

Interessant ist im Übrigen auch, dass nach dem "simulierten" S3 normale Konsolenbefehle wie reboot nicht mehr funktionieren. Das würde ja heißen, dass die Root-Partition ausgehängt wurde.
 
Nicht die geringste Ahnung. Wie weit kommt er denn bei einem echten s3? Schmiert es beim Aufwecken ab oder reagiert das System erst gar nicht auf das Power-on?
 
Gerade hat mir ein User im IRC den entscheidenden Tipp gegeben. Da das root-Dateisystem auf dem USB-Stick liegt, beim ACPI -S3 aber USB-Geräte ausgehängt werden, zieht er sich quasi selbst den Boden unter den Füßen weg.


Kann man das irgendwie verhindern oder vielleicht über einen eSATA Stick umgehen?
 
Verhindern, dass USB abgeschaltet wird? Kann ich mir kaum vorstellen. Das System in eine Ramdisk tun? Hat das Teil genug Speicher für so was?
 
sandreas schrieb:
Was kann das "out of inodes" denn sein?
Wörtlich bedeutet es "Dateisystem voll". Aber es muss natürlich nicht der Fall sein, z.B. kann das Dateisystem dem Prozess auch unter dem Hinter weggezogen worden sein was zu einer falschen Fehlermeldung führt. Das wäre z.B. der Fall, wenn es auf einem USB-Laufwerk liegen würde. Denn viele USB-Geräte melden sich beim Suspend ab.
 
Zurück
Oben