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.