Suspend/Save to both: Wenn RAM-Nutzung > 20% von 12 GB, mehrere Versuche nötig

@Sauerland:

Danke für den Tipp.

Aber was den openSuse-Kernel angeht, bleibe ich vorläufig lieber beim 3.7.10.

Denn mit dem (selbstgebauten) 3.15er hatte ich von Beginn an noch ein weiteres Problem: Nach dem Resume aus dem Suspend/Tiefschlaf ist nämlich jedesmal das ATAPI-CD-ROM-Laufwerk tot. 3.14 und früher funktionieren diesbezüglich aber einwandfrei.

Und ich glaube auch nicht, daß die OpenSuse-Leute den Kernel-Bug 47931 behoben haben, ohne die Kernel-Entwickler darüber zu informieren. Das wäre doch nicht nett.

OM

toxa:

Stimmt, experimentieren bringt da nichts.

Deshalb habe ich ja auch den Link zu dem Bug gepostet - damit andere da gar nicht erst unnütz Zeit verschwenden.

OM

Zitat von Sauerland

Nur das wir nicht aneinander vorbeireden:
Im Repo Kernel:stable gibt es den aktuellen stabilen Kernel (momentan 3.15) als rpm, den kann man mit einem Befehl installieren und mit einem Befehl deinstallieren.
http://download.opensuse.org/repositorie…table/standard/

Das hatte ich nicht bedacht. Wenn ich den auf diesem Weg zusätzlich zum 3.7.10 installieren kann, ist es einen Versuch wert – auch wg. des Problems mit dem CD-ROM-Laufwerk.

Werde dann kurzes Feedback geben.

Zitat von Sauerland

Mit selbstgebaut verstehe ich die den Kernel von kernel.org selbst einzurichten, selbst zu bauen und zu installieren.

Genau.

OM

Hier die kurze Rückmeldung bzgl. 3.15.7 aus dem openSuse-Repo "stable":

1. suspend/save to disk: unverändert.

2. ATAPI-CD-ROM-Laufwerk: unverändert (tot nach Resume).
- Meldung von syslogd: "kernel:[2784.783099] Disabling IRQ #17". An dem hängt das Laufwerk.

Fazit: Kernel 3.15 (selbstgebaut/openSuse) löst das ursprüngliche Problem nicht und bringt dazu ein weiteres, schwerwiegenderes. Nichts für mich.

OM

Da es sich um einen Kernel-Bug handelt, den wohl nur die Kernel-Entwickler beheben können, schlage ich vor, das Thema hier vorläufig als erledigt zu betrachten.

Ich bleibe aber am Ball.

OM

Hatte ja versprochen, am Ball zu bleiben.

Das Problem steht im Zusammenhang mit VirtualBox. Wenn die Eigenschaft "Large pages" einer VirtualBox-VM (Virtuelle Maschine) auf "off" gestellt ist, steigt der Linux-Speicherwert "NR_FILE_MAPPED" stark an. Dies wiederum führt dazu, dass s2disk unnötigerweise scheitert.

Es handelt sich dabei wohl eher um einen Bug in VirtualBox als im Kernel. Nichtsdestotrotz arbeiten wir an einer Kernel-Lösung: https://bugzilla.kernel.org/show_bug.cgi?id=97201.

Man kann mit dem Kommandozeilen-Befehl

~> VBoxManage showvminfo "Name der VM" --details

überprüfen, auf welche Werte die Parameter eingestellt sind. Man erhält dann u. a.
...
Hardw. virt.ext: on
Nested Paging: on
Large Pages: off
VT-x VPID: on
VT-x unr. exec.: on
...

Bei Intel-CPUs kann man mit

~> VBoxManage modifyvm "Name der VM" --largepages on

Large Pages auf "on" stellen. Die VM muss dazu heruntergefahren sein. Soll sogar einen Performance-Gewinn von 5 % bringen (s. VB-Handbuch).

Für AMD-CPUs scheint das lt. VB-Handbuch nicht zu gehen. Kann ich aber nicht beurteilen.

Mit "Large Pages: on" sollten die NR_FILE_MAPPED-Werte dann im grünen Bereich sein. Die kann man mit

~> cat /proc/meminfo

überprüfen (Punkt "Mapped").

Wer also bei der Verwendung von VirtualBox Probleme mit s2disk hat, sollte die Einstellung für "Large pages" prüfen und ggf. ändern.

Bis dann!

OpenMind