suspend/resume

h^2

hat ne Keule +1
Nachdem es mir lange zeit egal war, wollte ich jetzt dochmal einen Anlauf machen. Der Laptop wrd hauptsächlich mobil benutzt und nicht mehr als Desktop-Ersatz, jetzt soll er auch irgendwie praktischer werden. Besonders da Startup-Zeit unter FreeBSD ja auch nicht ohne ist (dann kommt noch geli-action hinzu etc).

Ich habe mal ein bisschen rumgegoogelt und es kam raus, dass wohl ein einfaches
Code:
acpiconf -s 3
suspend-to-ram machen soll.

Wenn ich das mache, geht auch irgendwie alles aus. Direkt danach geht es aber von alleine wieder an, wobei der Bildschirm bunte Linen anzeigt und nichts mehr reagiert.

Der Laptop ist von Dell und hat normales Intel-zeugs drin (Dual-Core 32Bit, i945-GraKa etc).

Irgendwo auf forum.freebsd.org meinte jemand suspend wäre allgemein unter freebsd-x86 kaputt, Yamagi erwähnte in einem andere Fred etwas ähnliches, stimmt das? Ist das so vorgesehen oder wird daran gearbeitet?

Zur Not wäre ich auch bereit auf ein anderes BSD auszuweichen, wenn das da besser funktioniert. Der Laptop ist, wie gesagt, nicht mehr Hauptarbeitsgerät, soll aber dann wenigstens die Mobilsachen gut machen.

Danke!
 
Also ich kann nur bestätigen, dass Suspend unter FreeBSD/i386 nicht will. Das Thinkpad schlief zwar ein, wachte aber nie wieder auf und es war auch mit allen Tricks nicht möglich, einen Coredump zu bekommen oder in den Debugger zu gelangen. Mit FreeBSD/amd64 läuft es einwandfrei. Beides ist unter FreeBSD 8.1-RC1 gewesen.
 
Also bei meinem Thinkpad T41 (FreeBSD/i386, FreeBSD8.0-Release) läuft das ganze recht einwandfrei!
Resume dauert vielleicht etwas länger als suspend, aber damit kann ich leben.
 
Hm, also kann ich dawohl nichts machen :(

Weiß jemand ob bei den anderen BSDs die unterstützung besser ist?
 
Hi,

Hm, also kann ich dawohl nichts machen :(

Weiß jemand ob bei den anderen BSDs die unterstützung besser ist?

Bei NetBSD soll es nach Aussagen von einigen Usern recht gut funktionieren.

Ich habe die Erfahrung gemacht, dass man für ein funktionierendes SUSPEND/RESUME die Unterstützung für den so genannten APIC - nicht ACPI!!! - abschalten muss. Natürlich darf auch die Spielerei mit einigen SystCttl-MIBs nicht fehlen.
Es ist ziemlich zeitaufwändig, ein lauffähiges System auf die Beine zu stellen.
Schau mal hier: http://www.thinkwiki.org/wiki/Installing_FreeBSD_7_(i386)_on_a_ThinkPad_T43

Viele Grüße

JueDan
 
Also bei mir funktioniert das Einschlafen auf nem eeePC recht gut. Hatte bisher noch kaum Probleme wenn ich mich recht entsinne.
 
Moin olhe,

Wenn ich mich recht entsinne läuft aber ohne APIC kein SMP.

Das stimmt. Auch die Zahl der verfügbaren IRQs ist sehr, sehr eingeschränkt. Das habe ich bei meinem T43 schmerzlich erfahren dürfen, weil bei abgeschaltetem APIC die Adaptec-PCMCIA-SCSI-Karte nicht mehr funktionierte...
Aber nur bei abgeschaltetem APIC funktionierte suspend/resume.

Vor langer Zeit hat irgend jemand aus der Entwicklergruppe mal geschrieben, dass der APIC-Code buggy ist. Man wollte auch mal den entsprechenden AMD64-Code nach i386 portieren. Aber das ist lange her.

@h^2: Es wurde auch mal berichtet, dass auf manchen Intel DualCores die amd64-Variante funktionieren soll. Probiers doch mal

JueDan
 
Ja, das hier ist ein Core2Duo, der unter FreeBSD/amd64 inzwischen recht zuverlässig einschläft und wieder aufwacht. Ganz zufrieden bin ich noch nicht, aber das ist ein iterativer Prozess. Damit meine ich vor allem /etc/rc.suspend und /etc/rc.resume, welche ich ziemlich anpassen musste, damit da nicht irgendwelche Module im Kernel blockieren und so. Ich würde so vorgehen:

1. Das System im so viele Treiber wie möglich erleichtern. Vor allem USB, Sound und Firewire sind klassische Kandidaten, welche Suspend / Resume blockieren können. Dann schauen, ob das System einschläft und wieder aufwacht. Wenn es kein Bild zeigt, mal mit SSH probieren. Grafikkarten blockieren gern mal.

2. Versuchen die Grafikkarte nach dem Aufwachen zum Laufen zu bringen. "dpms.ko" (erst ab 8.1 in die Richtung wirklich zu gebrauchen) kann helfen, sonst auch sysutils/vbetool.

3. Durch simples Ausprobieren herausfinden, welche Treiber zuverlässig einschlafen und aufwachen. Alle anderen in rc.suspend entladen und in rc.resume wieder nachladen.

4. Während der regulären Benutzung weitere Probleme erkennen und beseitigen. Ganz klassisch sind da vor allem Timecounter-Probleme, gerade der "ACPI-Fast" Timecounter neigt zu große Ärger wie massiv springenden Uhren, rückwärtsaufenden Prozessen und co. Hier helfen dann andere Timecounter. Auch spinnendes WLAN (wlan-device zerstören und neu erstellen) gehören dazu. Das habe ich inzwischen schon hin, ich jage nur noch einem Speicherleck im Kernel nach.

Mit einem relativ großen Aufwand und Geduld kommt man so eigentlich zu brauchbaren Ergebnissen, sofern Schritt 1 umsetzbar ist. Wichtig ist noch, sich mit aggressiven Stromspargeschichten (z.B. RTC abschalten) zurückzuhalten, bis alles so funktioniert wie es soll und sie dann ebenfalls schirttweise mit exzessivem Testen umzusetzen.
 
Nachtrag: Hier einmal meine minimale Kernelconfig (alles als Modul) für 7.2. Funktioniert so auch mit späteren Versionen, lediglich COMPAT_IA32 muss zu COMPAT_FREEBSD32 umbenannte werden. Sonst bootet der Kernel nicht, baut aber. Außerdem muss /usr/src/sys/amd64/conf/DEFAULTS leer sein. Sonst gibt es ebenfalls Probleme. Eine zugehörige /boot/loader.conf kann ich leider erst morgen Abend einstellen.

Code:
# Allgemein -- CPU
machine		amd64
cpu		HAMMER
ident		BEISPIEL
options		SMP

# Allgemein -- Options
options         SCHED_ULE
options         INET
options         INET6
options		IPSEC
options		SCTP
options         KBD_INSTALL_CDEV
options         ADAPTIVE_GIANT
options         PREEMPTION
options		STOP_NMI
options		KTRACE
options		AUDIT
options		KSE
options		PRINTF_BUFR_SIZE=256

# Allgemein -- Debug
options         STACK

# Allgemein -- Dateisysteme

# UFS2
options		FFS
options		SOFTUPDATES
options		UFS_ACL
options		UFS_DIRHASH
options		QUOTA
options         UFS_EXTATTR
options         UFS_EXTATTR_AUTOSTART

# Allgemein -- Kompatiblität
options		COMPAT_FREEBSD4
options         COMPAT_FREEBSD5
options		COMPAT_FREEBSD6
options		COMPAT_43TTY
options		COMPAT_IA32
options         _KPOSIX_PRIORITY_SCHEDULING
options         SYSVSHM 
options         SYSVMSG
options         SYSVSEM

# Hardware -- GraKa
device		vga
device		splash

# Hardware -- Console
device		sc

# Hardware -- Netzwerk
device 		loop
device 		ether
device          bpf

# Hardware -- Pseudodevices
device		pty

# Hardware -- Keyboard
device		atkbdc
device		atkbd

# Hardware -- Controller
device          isa
device		eisa
device		pci
device		acpi

# ALTQ
options         ALTQ
options         ALTQ_CBQ
options         ALTQ_RED
options         ALTQ_RIO
options         ALTQ_HFSC
options         ALTQ_CDNR
options         ALTQ_PRIQ
options         ALTQ_NOPCC

# Serielle Schnittstelle
device		uart
device          uart_ns8250

# Crypto fuer IPSEC
device		crypto

# Kein reboot bei strg-alt-entf
options		SC_DISABLE_REBOOT

EDIT: Ich sehe gerade, die ist nur für 7.2. Eine aktuellere für 8.0 gibt's morgen.
 
Zuletzt bearbeitet:
3. Durch simples Ausprobieren herausfinden, welche Treiber zuverlässig einschlafen und aufwachen. Alle anderen in rc.suspend entladen und in rc.resume wieder nachladen.
Sogar so panicked (wie zur Hölle macht man deutsches Passiv mit Anglizismen?) meine bge0 Intel GBit LAN.
 
Hmm... Mein bge0 tut es nicht. Aber das hat nicht viel zu sagen, da dort jede Menge BIOS / Firmware Magie mit hineinspielt. Ich stelle nächste Woche mal die komplette Konfiguration hier ein. Vielleicht hilft das dem Einen oder Anderen. :)
 
Gibts es denn irgendwelche Knobs für eine nicht mehr reagierend Tastatur? Oder überhaupt eine Anlaufstelle für die wichtigsten Dinge in puncto Laptop? Teils ist das alles sehr verstreut, Informationen eventuell veraltet.
 
Meine Strategie war immer einen Laptop kaufen und dann so lange mit PRs und E-Mails um mich werfen, bis das was mir wichtig ist funktioniert.
 
Zurück
Oben