Riparto dal messaggio originale. E` un po' che non metto mano in queste
cose quindi non volevo dire bestialita`, ma ho visto degli errori in
alcune altre risposte.
Prima di tutto, no, questa volta non dico sia colpa di systemd :)
[3730483.156140]
Questo e` il tempo dall'accensione, in secondi. 43.17 giorni. Il
sistema internamente non usa il tempo esterno perche` non e`
affidabile (se l'utente o ntp cambia l'ora che succede?)
INFO: task kworker/0:2:32752 blocked for more than 120 seconds.
Dopo dice "task:kworker/0:2" a conferma che 32752 e` il pid
di kworker/0:2 . Quindi fare "ps" e` inutile.
Non e` "andato in timeout", espressione che indica il fallimento di
qualcosa. Ci ha messo piu` di 120 secondi a fare quello che doveva
fare. Se il messaggio e` per 120 secondi, e non 120ms, vuol dire che
e` abbastanza normale che ci metta un po'.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Cercherei in rete o nei sorgenti "hung_task_timeout_secs", sapendo che
la prima fonte e` piena di falsi. Sono fuori sede e non ho un
linux.git sotto mano, ma prima o poi ci guardo per curiosita` mia.
[3730483.156210] Workqueue: events_freezable mmc_rescan
Questa e` la coda di cose da fare per questo processo. Quindi immagino
stia facendo mmc_rescan, che potrebbe essere un'operazione lunga, in particolare se la memoria e` in uso (quindi l'I/O di rescan va
intercalato con gli altri I/O). Ma non so cosa sia mmc_rescan, va
controllato.
[3730483.156233] Call trace:
[3730483.156237] __switch_to+0xf8/0x1e0
[3730483.156252] __schedule+0x2a8/0x830
[3730483.156260] schedule+0x60/0x100
Qui si vede che il messaggio avviene durante un cambio di contesto
(switch_to, schedule), quindi non e` detto che quanto sta nello stack
trace sia significativo. Su un'altra macchina mi capita spesso e lo
stack trace non ha relazione col baco che genera il ritardo.
[3730483.156269] __mmc_claim_host+0xbc/0x208
[3730483.156276] mmc_get_card+0x3c/0x50
[3730483.156283] mmc_sd_detect+0x28/0x98
[3730483.156290] mmc_rescan+0xa0/0x2c8
[3730483.156297] process_one_work+0x208/0x480
[3730483.156307] worker_thread+0x50/0x428
In realta` sembra che la cosa sia significativa. Il processo che
subisce schedulazione sta facendo mmc_rescan (e non ha schedulato per
piu` di 120 secondi: non ci dice quanto perche` non e` ancora
successo). Andrebbe verificato cosa sia questa cosa. Non e` che la macchina
ha un secondo slot sd, non popolato, che viene erronemaente rilevato
per un bogone sul segnale di presenza ("card inserted")?
Comunque non e` nulla di fatale, tanto che si puo` disabilitare il
messaggio. Certo, la sdcard non e` eterna, in particolare se ci si
scrive molto.
Mi dovrei preoccupare?
Il giusto, non di piu` non di meno.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)