Come posso eseguire il debug di un problema Suspend-to-RAM su Linux?

15

Spero di ottenere suggerimenti basati sull'esperienza su come eseguire il debug del problema di sospensione su RAM. I consigli specifici per la mia situazione (dettagliati di seguito) sarebbero ottimi, ma sono anche interessato a consigli generali su come eseguire il debug di tali problemi.

Il problema:

Spesso, quando provo a sospendere la mia macchina, si blocca in uno stato "non sospeso ma non sveglio". Spesso lo schermo sarà completamente nero ma a volte avrà il seguente messaggio di errore:

GLib-WARNING **: getpwuid_r(): failed due to unknown user id (0)

Inoltre, questo stato sarà anche accompagnato dai fan che danno il massimo. L'unico modo per uscire da questo stato è spegnere manualmente il laptop.

Alcune informazioni

$ uname -a
Linux baltar 2.6.35-22-generic #34-Ubuntu SMP Sun Oct 10 09:26:05 UTC 2010 x86_64 GNU/Linux

$ lsb_release -a
Distributor ID:    Ubuntu
Description:    Ubuntu 10.10
Release:    10.10
Codename:    maverick

Ho dato un'occhiata /var/log/dmesge /var/log/pm-suspend.log, ma non so cosa sto cercando e niente spicca. Non sono sicuro che sia correlato, ma ho trovato molte delle seguenti in /var/log/kern.log:

EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro,commit=600

linux debugging suspend

— Steven D
fonte

1

Se ritieni di essere stato morso da un bug specifico che menziono qui, ti preghiamo di non pubblicare una risposta "anch'io", poiché in realtà non è una risposta. Sentiti libero di votare questa domanda per incoraggiare gli altri a rispondere ad essa. Alla fine, una buona risposta fornirebbe non solo consigli per risolvere questo particolare problema, ma consigli per il debug di questo tipo di problemi.

— Steven D,

Eliminato dopo chiarimenti sulla Lounge degli insegnanti. Le uniche informazioni potenzialmente preziose vengono No LSB modules are available.visualizzate subito dopo lsb_release -a.

— Maciej Piechotka,

Ho segnato una risposta "ha funzionato per me", ma penso ancora che una risposta più generale "come eseguire il debug della sospensione su RAM" sarebbe davvero utile qui.

— Steven D,

3

Hai un chipset grafico Intel? Stavo ottenendo quello che sembra lo stesso problema sul mio ThinkPad X200s con Ubuntu 10.10 e questa soluzione alternativa (dal 2008!) L'ha risolto per me: http://ubuntuforums.org/showpost.php?p=6105510&postcount=12

— lawnjam
fonte

6

PM_DEBUG e PM_TRACE sono apparentemente le strutture di debug più profonde attualmente disponibili. Quando non si ottiene nulla di significativo dai registri di livello superiore, AFAIK questo è l'unico meccanismo su cui ripiegare quando si incontra il temuto "misterioso schermo vuoto al ripristino". Molto spesso abbiamo a che fare con un driver di dispositivo rotto, abbastanza spesso sottilmente. Puoi anche dare un'occhiata alla mia saga di debug del driver wireless Broadcom brcmsmac al bug del kernel 34682 per ciò che gli sviluppatori del kernel suggeriscono e cercano.

— lkraav
fonte

1

Ho il sospetto che il problema potrebbe essere dovuto al fatto che il BIOS non riporta correttamente su ciò che in realtà utilizza.

Per impostazione predefinita questa opzione è attiva:

memory_corruption_check_size=64K

Puoi provare a impostarlo su valori più grandi per fare in modo che lo scanner di corruzione della memoria esamini un pezzo più grande di lowmem.

Cerca "memory_corruption_check_size" in

http://lxr.linux.no/#linux+v2.6.35.7/Documentation/kernel-parameters.txt

eccetera.

Sarei interessato a sapere cosa trovi, se non altro.

0

La mia esperienza di lavoro in questo settore è stata in Windows CE, piuttosto che in Linux.

Durante il ciclo di sospensione / ripresa, il sistema operativo spegnerà progressivamente la funzionalità del sistema operativo limitando la possibilità di ottenere informazioni affidabili e precise su ciò che sta accadendo utilizzando la funzionalità del sistema operativo. Inoltre, la connessione di monitoraggio può (ad es. Se il problema è legato al tempo) alterare il risultato.

Gli strumenti di preferenza iniziano con una connessione debugger C / C ++ con il sistema operativo nella fascia alta e, a un livello molto basso, invio di dati tramite una porta seriale / codici POST o su debugger JTAG hardware non equivalente o equivalenti. Il risultato finale sono lunghe ore per elaborare il flusso di codice e trovare il punto in cui si comporta diversamente dal comportamento normale. A quel punto, la correzione è generalmente ovvia. Tieni appunti positivi e apporta una modifica alla volta.

Sono state necessarie 6 settimane per identificare il problema di accensione che abbiamo avuto con Windows CE. Avevamo una scheda processore PC104 che potevamo spegnere per 10 o 60 secondi e accendere senza problemi. Tuttavia, se l'alimentazione fosse rimossa per 25 secondi, non si accenderebbe. Si è scoperto che avevamo abbastanza capacità per mantenere intatti i contenuti della DRAM senza alimentazione per circa 20 secondi, quindi su un breve ciclo di spegnimento, Windows CE pensava che stesse riprendendo da uno stato sospeso. Quando tutta la memoria fosse conservata, sarebbe effettivamente riuscita a eseguire un curriculum, quando la memoria era parzialmente corrotta, si sarebbe piuttosto confusa durante il curriculum.

In bocca al lupo.

— Michael Shaw
fonte