Laptop Acer: problema resume dopo sospensione

[Gica78R]

Ciao!

Ho un portatile Acer Extensa 5620 con pochi mesi di vita sul quale sono installati Vista ( ) e Debian Testing. Su questo portatile si verifica uno strano problema in seguito alla sospensione in memoria o sul disco, con effetti abbastanza fastidiosi. Tali problemi sembrano verificarsi solo con Linux e non con Windows. Vi descrivo quel che accade: in pratica, dopo aver messo in sospensione il sistema (cosa che va a buon fine), al ripristino sembra che l'alimentazione venga a mancare per qualche istante per poi riprendere dopo pochi secondi. Se avevo fatto la sospensione su disco non ho nessun problema, in quanto l'immagine di memoria salvata nell'area di swap rimane a disposizione e viene ripristinata correttamente; se invece avevo fatto la sospensione su ram, quella breve mancanza di alimentazione provoca la perdita del contenuto della memoria e quindi un non corretto ripristino (nella fattispecie, il led che segnala l'accensione resta acceso, la ventola inizia a girare, ma il monitor è nero e il laptop non dà alcun segno di vita, per cui sono costretto a resettare brutalmente).
Questi brevi blackout si verificano di tanto in tanto anche al riavvio dopo un normale spegnimento del sistema (parlo sempre di Linux), come se lo spegnimento non fosse avvenuto correttamente.

Io sospetto che ci possa essere un problema nel gestire l'acpi, ma sinceramente non so dove mettere le mani per indagare sulla faccenda.

Suggerimenti?

[Gica78R]

Scusate se aggiungo un nuovo messaggio invece di editare il precedente...

Mettendo il valore 3 nel file /proc/sys/kernel/acpi_video_flags (il valore originale era 0) e poi mandando il portatile in suspend2ram sembra che il resume vada a buon fine. Il problema dovrebbe essere dovuto ad una non corretta capacità di resume della scheda video. Questa cosa l'ho trovata leggendo il file Documentation/power/video.txt della documentazione del kernel (ora sto usando il 2.6.25.4 appena compilato, ma anche con quello della mia distribuzione è lo stesso) ed anche questa documentazione su s2ram; impostare quel valore a 3 vuol dire passare al kernel il parametro acpi_sleep=s3_bios,s3_mode.

Visto che la cosa funziona, vorrei sapere come fare affinché quel parametro resti impostato a 3 e non ritorni a 0 al prossimo riavvio. Riuscite a dirmelo prima che lo scopra da solo?

[dennyv]

Originariamente inviato da Gica78R

Visto che la cosa funziona, vorrei sapere come fare affinché quel parametro resti impostato a 3 e non ritorni a 0 al prossimo riavvio. Riuscite a dirmelo prima che lo scopra da solo?

Dovrebbe bastare la riga

kernel.acpi_video_flags = 3

nel /etc/sysctl.conf e per applicare l'impostazione da subito lancia sysctl -p

Ciao!
Daniele

[Gica78R]

Originariamente inviato da dennyv

Dovrebbe bastare la riga

kernel.acpi_video_flags = 3

nel /etc/sysctl.conf e per applicare l'impostazione da subito lancia sysctl -p

Ciao!
Daniele

Grazie mille! Ho imparato una cosa nuova

Ciao

[dennyv]

Originariamente inviato da Gica78R

Grazie mille! Ho imparato una cosa nuova

Ciao

Figurati

Vale per qualsiasi voce di /proc/sys e come avrai intuito la sintassi è in pratica sostituire nel percorso gli slash con un punto partendo da /porc/sys come base poi metti uguale e il valore asseganto.

Ciao!

[Gica78R]

Originariamente inviato da dennyv

Figurati

Vale per qualsiasi voce di /proc/sys e come avrai intuito la sintassi è in pratica sostituire nel percorso gli slash con un punto partendo da /porc/sys come base poi metti uguale e il valore asseganto.

Ciao!

Si, l'avevo capito

Però ho scoperto che quella specie di workaround dà risultati aletori... A volte funziona, a volte no
Proverò ad impostare il parametro al valore 2...

EDIT: no, niente da fare

[Gica78R]

Novità:

dopo parecchie prove, attraverso le quali ho verificato che, avviando il sistema con una shell come processo di init, il suspend to ram funziona perfettamente usando il comando

s2ram -f -a3

ho modificato il file /etc/hibernate/ram.conf aggiungendo all'inizio (prima delle opzioni TryMethod, come suggerito nello stesso file) le opzioni

USuspendRamForce yes
USuspendRamAcpiSleep 3

Tuttavia il comportamento continuava ad essere abbastanza aleatorio.

Girando in rete ho poi trovato questo wiki in cui si dice che affinché il suspend to ram funzioni correttamente bisogna scaricare il modulo psmouse. Ho allora aggiunto nel suddetto file le righe

UnloadModules psmouse
LoadModules auto #Per ricaricare il modulo psmouse al resume

e la faccenda sembra funzionare. Speriamo continui così, sennò...

[dennyv]

Originariamente inviato da Gica78R

Si, l'avevo capito

Però ho scoperto che quella specie di workaround dà risultati aletori... A volte funziona, a volte no
Proverò ad impostare il parametro al valore 2...

EDIT: no, niente da fare

Tra l'altro anche io ho un Acer, un Travelmate 6292... però la sospensione (solo su ram... stupidamente ho fatto la swap da 512MB ) funziona come un orologio e la uso ormai in qualunque occasione... e dovrebbero essere imparentati. Con testing non l'ho provato, ma con la unstable funzionava... hai provato altre distro con kernel più recenti? Tipo Ubuntu/Fedora..

Ciao!

[Gica78R]

Originariamente inviato da dennyv

hai provato altre distro con kernel più recenti? Tipo Ubuntu/Fedora..

Si, con Fedora 8 all'inizio dava lo stesso problema; successivamente, con qualche aggiornamento, la faccenda sembrava risolta. Fedora 9 l'ho provata ma siccome non mi piaceva l'ho tolta subito e non ricordo se il s2ram andava bene. Idem con Ubuntu...

Comunque il mio scopo è farlo funzionare con Debian

[dennyv]

Originariamente inviato da Gica78R

Si, con Fedora 8 all'inizio dava lo stesso problema; successivamente, con qualche aggiornamento, la faccenda sembrava risolta. Fedora 9 l'ho provata ma siccome non mi piaceva l'ho tolta subito e non ricordo se il s2ram andava bene. Idem con Ubuntu...

Comunque il mio scopo è farlo funzionare con Debian

Riesci a mandarmi il dsdt disassemblato?
Se non vuoi stare a fare la trafila (ti serve il compilatore/decompilatore, dovrebbe essere nei repository, si chiama iasl, trovi info su google) mandami il dsdt così com'è:

sudo cat /proc/acpi/dsdt > dsdt && bzip2 dsdt

Poi mandami dsdt.bz2 a dennyvatwork(chiocciolina)la casella di google(punto)com
Così, solo per un confronto con il mio... visto che al dilà del processore il resto dovrebbe essere quantomeno simile!

Ciao,
Daniele

[Gica78R]

Mandato

Comunque dopo l'ultima modifica (scaricamento del modulo psmouse) sembra andare...


Ciao

[Gica78R]

Ho scritto una mezza guida che illustra la risoluzione di questo problema; la trovate qui

Ciao

[Gica78R]

Dopo aver eliminato definitivamente Vista dal portatile e reinstallato Debian da zero, ho ripetuto la configurazione del suspend to ram ma, per qualche inspiegabile motivo, la faccenda è tornata ad essere incredibilmente instabile

Che nervi!

EDIT: ho sostituito Klaptop con Kpowersave e, inoltre, ho messo le opzioni con cui invocare s2ram in un file all'interno della directory /etc/pm/config.d/ piuttosto che modificando i files in /etc/hibernate/. Sambra che ora vada come si deve

Anche per Kpowersave ho scritto una mini-guida...

[Gica78R]

Originariamente inviato da Gica78R

Sembra che ora vada come si deve

No! Nemmeno adesso!

[Gica78R]

Originariamente inviato da Gica78R

No! Nemmeno adesso!

Ritorno alla carica perché ho capito alcune cose

• il modo migliore per gestire il suspend to ram è attraverso i tool del pacchetto uswsusp, vale a dire s2ram e compagni, ma ci sono anche strumenti integrati nel kernel e un certo tuxonice che non ho approfondito
• tali tool di uswsusp possono essere avviati dagli script pm-utils (pm-actions, pm-suspend, ecc...)
• gli script del pacchetto pm-utils possono essere avviati da HAL
• HAL e acpi possono pestarsi i piedi a vicenda
• klaptop usa acpi, mentre kpowesave usa HAL

Allora il modo più pulito per far fare la cosa giusta a s2ram è quello di rimuovere i vari pacchetti acpi, tranne acpid (che deve essere installato e attivo), rimuovere il pacchetto hibernate, installare ovviamente pm-utils e configurarlo affinché lo script pm-suspend (avviato da un evento hal, ad esempio attraverso kpowersave) invochi s2ram con i parametri giusti (che variano a seconda dell'hardware). I file di configurazione di pm-utils si trovano in /usr/lib/pm-utils/, ma è meglio non toccarli e usare, come consigliato, la directory /etc/pm/config.d/ all'interno della quale, per poter assegnare correttamente i valori alle variabili di interesse, bisogna creare un file chiamato defaults. Se si chiama il file con un nome differente, gli script pm-utils lo scambiano per un file da eseguire generando errori. In tutto questo ambradam credo di aver rilevato un piccolo bug riguardante il file di log pm-suspend.log: questo file va creato manualmente in /var/log/ altrimenti lo script, non trovandolo, si rifiuta di crearlo.

Tornando al mio caso specifico (Acer Extensa 5620, scheda grafica intel) per far funzionare il suspend to ram bisogna scaricare il modulo psmouse e invocare s2ram coi parametri "-f -a3" oppure "-f -p -m" (sto vedendo quale è meglio). Per farlo, nel file /etc/pm/config.d/defaults si mette quanto segue:

SLEEP_MODULE = "uswsusp"
SUSPEND_MODULES = "psmouse"
S2RAM_OPTS = "-f -a3" # oppure S2RAM_OPTS = "-f -p -m"

In questo modo la sospensione in memoria funziona sempre e il resume funziona quasi sempre; a volte succede che al monitor si riaccendono le luci ma il sistema non risponde e tocca resettare brutalmente. Se non altro non c'è più il problema dello spegnimento inaspettato subito dopo il resume, ed è già qualcosa

L'inconveniente che però si verifica sempre riguarda il touchpad: al resume funziona tutto, ma il touchpad sembra aver "dimenticato" le opzioni della sezione synaptics nel file xorg.conf, quindi non ha il comportamento che mi aspetto (cioè il tap disbilitato, lo scroll verticale, ecc...) e su questo non riesco a trovare nulla in giro che possa aiutarmi. Facendo il logout da KDE e quindi nuovamente il login il touchpad torna normale, ma questo perché forse dopo ogni logout viene riavviato il server grafico

Sapete se c'è un modo per dire al server grafico di rileggersi il file di configurazione o di ricaricare un driver senza riavviare il server stesso? Ho provato aggiungendo l'opzione SHMConfig a synaptics, ma non funziona.

Se avete suggerimenti non siate timidi!

Ah, vi segnalo questo wiki Debian: è una buona fonte di informazioni sul suspend.

[DanieleC88]

Originariamente inviato da dennyv

/porc/sys

A parte scherzi, rispondo a Gica78R: non vedo quale possa essere la causa di questo malfunzionamento, ma con una rapida ricerca ho trovato un tizio su un forum in inglese che consiglia, al ripristino dalla sospensione, di scaricare/ricaricare il modulo psmouse con modprobe e poi uscire da X cambiando VT (vai ad una qualsiasi console) e poi ritornando in X con la stessa tecnica, con un Control+Alt+F7. Certo, non sarà il massimo, ma almeno ti evita la trafila logout/riavvio X/login.

ciao

[Gica78R]

Originariamente inviato da DanieleC88

A parte scherzi, rispondo a Gica78R: non vedo quale possa essere la causa di questo malfunzionamento, ma con una rapida ricerca ho trovato un tizio su un forum in inglese che consiglia, al ripristino dalla sospensione, di scaricare/ricaricare il modulo psmouse con modprobe

Si, questo lo faccio già via pm-utils attraverso hal

e poi uscire da X cambiando VT (vai ad una qualsiasi console) e poi ritornando in X con la stessa tecnica, con un Control+Alt+F7.

Questa non la sapevo... Ora ci provo.

Grazie!