Il sistema si blocca completamente con Intel Bay Trail

Il mio sistema si blocca completamente a intervalli casuali e frequenti. Ho iniziato ad avere lo stesso problema in Ubuntu 14.04 ma dopo il recente aggiornamento alla 16.04 non c'è alcun miglioramento, in effetti sembra peggiore.

Quando succede, è impossibile fare qualsiasi cosa. Ho provato di tutto in questo thread: cosa fare quando Ubuntu si blocca, ma non funziona nulla, devo eseguire un hard reset. Ho letto tutti i registri di sistema e journalctlnon ci sono mai informazioni che possano aiutare a diagnosticare il problema.

Questo è un sistema a doppio avvio con Windows 10 e non ci sono problemi, quindi non è un hardware difettoso.

Il mio laptop ha un processore Intel Bay Trail (Pentium N3540)

16.04 kernel intel

— Jack Dix
fonte

Rilevante: il problema con la CPU Intel Bay Trail sarà risolto in 17.04?

— Zanna

Risposte:

Il tuo processore è interessato dal bug c-state

Ciò provoca il blocco totale quando la CPU tenta di entrare in uno stato di sospensione non supportato. È un problema per molti dispositivi Bay Trail in particolare con i kernel (4. *) più recenti.

Processori interessati AFAIK:

Atom Z3735F (Asus X205TA, Acer Aspire Switch 10, Lenovo MIIX 3 1030) 
Atom Z3735G
Celeron J1900 (Asus ET2325IUK, shuttle XS35V4)
Celeron N2940 (Acer Aspire ES1-711, Chromebook)
Celeron N2840 (Acer Aspire ES1-311)
Celeron N2930 (Jetway JBC311U93, Zotac Nano CI320)
Pentium N3520 
Pentium N3530 (Acer V3-111P)
Pentium N3540 (Dell Inspiron 15 3000, Lenovo G50, ASUS X550MJ)

(per favore (suggerisci una) modifica per aggiungere il tuo dispositivo se interessato)

L'elenco completo dei processori Bay Trail è disponibile qui

C'è una semplice soluzione per questo fino a quando non viene correttamente risolto a monte.

Devi solo passare un parametro di avvio del kernel e il blocco casuale si arresta completamente. Il parametro può aumentare leggermente il consumo della batteria, ma ti darà un sistema utilizzabile.

Puoi farlo modificando il file di configurazione per GRUB:

Avvia Ubuntu e apri un terminale premendo Ctrl+ Alt+ Tquindi digita

sudo nano /etc/default/grub

Trova la linea che inizia GRUB_CMDLINE_LINUX_DEFAULT=

Questo deve essere cambiato per includere intel_idle.max_cstate=1

Quindi dopo la modifica si legge qualcosa di simile

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"

quiete splashsono parametri predefiniti per Ubuntu Desktop: non è necessario modificarli o altri parametri preesistenti

Ora salva il file premendo ctrl+, oquindi enteresci premendo ctrl+x

Adesso corri

sudo update-grub

Quindi riavviare.

Cosa fare se non si ha abbastanza tempo per farlo prima che il sistema si blocchi

Nessun problema. Come spiegato nella pagina di aiuto che ho collegato in precedenza, è possibile aggiungere il parametro a GRUB prima dell'avvio. Si noti che questo passa solo il parametro per l'avvio corrente, quindi è comunque necessario modificarlo /etc/default/grubdopo l'avvio per rendere permanente la modifica.

Devi accedere al menu di GRUB . Se si esegue il doppio avvio, questo apparirà comunque, in caso contrario è necessario tenere premuto (o toccare) shiftdopo aver premuto il pulsante di accensione per accendere.

Quando arrivi a questa schermata seleziona Opzioni avanzate per Ubuntu . È possibile spostare il cursore su un kernel diverso o lasciarlo in posizione per modificare le opzioni predefinite. Invece di premere enter, stampa ee si andrà in modalità di modifica, guardando vagamente come questo .

Sposta il cursore verso il basso nel punto in cui dice quiet splash, posiziona uno spazio dopo lo splash e digita attentamente intel_idle.max_cstate=1assicurandoti che ci sia uno spazio anche dopo di esso.

Ora premi F10o Ctrl+ xper avviare.

— Zanna
fonte

@Arronical hehe grazie! Devo saperlo - il mio sistema rimarrà attivo per ~ 15 minuti senza di esso, ma con il parametro, non viene mai congelato una volta :) Tutto merito agli hacker davvero fantastici che lo hanno capito

— Zanna,

Grazie! Questo interrompe la mancata risposta a Ctrl Alt REISUB? Anche la risposta alla modifica di GRUB sopra era che se è impostato il timeout nascosto, la modifica di cui sopra non funzionerà. Come aggirare questo problema se il problema persiste?

— clr

@clr i blocchi dello stato c non rispondono al sysrq magico REISUB, ma questa correzione blocca i blocchi dello stato c. Se il sistema si blocca per qualche altro motivo, REISUB potrebbe funzionare. GRUB_HIDDEN_TIMEOUT non ha alcun effetto sui parametri di avvio e dovresti essere in grado di accedere al menu premendo shift all'avvio. Se non è possibile, nel caso in cui il sistema si blocchi troppo rapidamente per poter essere modificato /etc/default/grub, è una seccatura, ma puoi provare ad avviare una sessione live di una versione con un kernel più vecchio per modificare il file - monta la partizione di root /mnte modifica /mnt/etc/default/grubin aggiungi il parametro.

— Zanna,

Grazie per le istruzioni chiare. Spero che questo funzioni. Riporterò qui se non lo fa. Attualmente sto eseguendo il 16.10 su uno Zotac Nano CI320. Avevo provato 16.04 e Debian 8 in precedenza, e ho anche sperimentato blocchi casuali. Ho provato il 16.10 sperando che il problema andasse via con un kernel più recente. È interessante notare che una volta ho provato REISUB (non ricordo quale sistema operativo) funzionasse, quindi potrebbe risultare che sto affrontando un problema diverso.

— Jeremy Cook,

@JeremyCook Ho appena installato il 16.10 e la prima cosa che ho fatto è stato modificare i miei parametri di avvio - dovrei davvero dare un'occhiata a questo nuovo kernel! Per favore fatemi sapere se funziona o no qui.

— Zanna,

I processori Linux on Bay Trail e Braswell si bloccano casualmente con dispositivi video integrati.

Il problema è con il controllo della temperatura. Basta rimuovere il modulo thermald:

sudo apt-get remove thermald

— Genia Li
fonte

Credo che il bug di Bay Trail sia nel driver i915 (CPU Intel). Il processore cerca costantemente di entrare in stati di sospensione che non sono supportati da esso. I problemi per gli utenti di Bay Trail sono iniziati dopo un commit a i915, quindi è sempre stata incolpata. Tuttavia, forse c'è un'altra causa per alcuni, e non ho idea del congelamento di Braswell e sarebbe bello sapere che sono stati risolti da qualche azione (sicura?). Hai qualche riferimento per queste informazioni o puoi dirci su quale hardware è stato testato e funzionato?

— Zanna,

Sembra che questo sia ancora un problema con 19.04. Speravo in qualche modo che fosse risolto ormai. È successo sul mio laptop da dopo il 14.04. 15.10 era quasi impossibile da risolvere.

— crip659

Per le persone che seguono questo bug ecco un aggiornamento. Vai a: Bug 109051 - intel_idle.max_cstate = 1 richiesto su baytrail per evitare arresti anomali e premere il Endtasto. Se necessario, premere Page Upsul messaggio # 1013.

Secondo il commento # 1013 ora è stato corretto nei kernel recenti:

Non ho controllato questa discussione da molto tempo, ma ho pensato di pubblicare i miei risultati nel caso in cui fosse utile a nessuno.

Un computer di fascia bassa dotato di un Intel N2807 che non ha mai funzionato per più di 30 minuti senza crash quando non ho impostato ... max_cstates = 1 ora funziona perfettamente con un kernel stock v. 5.3.1 o 4.19.75. L'ho eseguito per un paio di giorni con ogni versione senza problemi. Anche il consumo medio di energia è diminuito di poco più del 10%.

Sono stati necessari circa quattro anni per correggere questo bug segnalato per la prima volta l'8 dicembre 2015.

— WinEunuuchs2Unix
fonte