Molte persone hanno problemi con Ubuntu 14.04, 16.04 e 16.10 in cui il sistema si blocca completamente e io sono uno di loro.
Voglio sapere se Ubuntu 17.04 risolverà quel problema o meno, se è già stato risolto sull'immagine ISO di prova di 17.04, prima di provare a scaricarlo e testarlo.
Risposte:
Questi blocchi si verificano quando il processore tenta di entrare in uno stato di basso consumo (stato c) che il kernel non supporta. Questo problema è stato introdotto da
commit 8fb55197e64d5988ec57b54e973daeea72c3f2ff
Date: Tue Apr 7 16:20:28 2015 +0100
drm/i915: Aggressive downclocking on Baytrail
Questo è andato a monte nel kernel 4.2, e da allora abbiamo riscontrato problemi. Come spiegato nella risposta di heynnema (e in questo post in cui ho cercato di raccogliere informazioni ) c'è una soluzione semplice ed efficace, passando un parametro di avvio che disabilita gli stati di basso consumo.
La versione beta di 17.04 attualmente disponibile utilizza 4.9 (è basato sull'upstream 4.9.6, per quanto ho capito), e quando la versione uscirà ad aprile, credo che utilizzerà 4.10 . Il problema esiste ancora in questi kernel, quindi ho concluso che non è stato risolto al momento . Ho controllato i log delle modifiche del kernel Ubuntu e non ho trovato nulla, ma per favore correggimi se sbaglio.
Ho seguito il bug c-state qui su kernel.org da molto tempo. Nel gennaio 2017, Mika Kuoppala ha aggiunto questa patch al thread. Apparentemente, ripristina il commit precedente che ha causato il problema. Si chiama la patch
drm/i915/byt: Avoid tweaking evaluation thresholds
I test indicano risultati molto buoni con questa patch, che è stata inviata ai proprietari dei driver i915 il 25 gennaio. Tutto bene, potrebbe essere unito nella finestra 4.11. Il kernel 4.11 potrebbe essere rilasciato verso la fine di aprile. Una versione di questa patch è stata unita nella finestra 4.11 e i rapporti indicano che il bug è stato corretto in 4.11.
Ciascuno dei fastidiosi processori BayTrail si comporta in modo leggermente diverso con ciascun kernel diverso. Nel 16.04 (kernel 4.4) il mio tempo di attività su Atom Z3735F senza il parametro intel_idle era di circa 15 minuti prima del congelamento. Ho testato la beta 17.04 ISO in modalità live e non ho avuto un congelamento in 90 minuti, quindi mi sembra di essere fortunato con questo kernel. Puoi fare la stessa cosa per testare qualsiasi immagine sul tuo sistema: basta creare un USB avviabile e "provare Ubuntu senza installare" e testarlo il più a lungo possibile.
Quando è uscito 17.04, l'ho installato e nelle prime due settimane l'ho eseguito senza il intel_idleparametro, ho avuto solo tre blocchi dello stato c, che è un enorme miglioramento rispetto alle versioni precedenti.
La cosa più sicura da fare è usare il parametro boot. Sulla base della mia ricerca, mi aspetto che il bug venga corretto in 17.10 (e in altre versioni di distro entro la fine dell'anno) che utilizzerà un kernel> = 4.11, ma non in 17.04.
Tuttavia, c'è sempre la possibilità che Ubuntu Kernel Team possa correggerlo da solo. Se puoi tollerare di eseguire occasionalmente un sistema instabile, puoi controllare i progressi eseguendo aggiornamenti regolari ( sudo apt update && sudo apt full-upgrade) e testando ogni nuovo kernel senza il parametro di avvio quando arriva. Puoi anche leggere i log delle modifiche quando vengono installati nuovi pacchetti o (di nuovo, se riesci a tollerare l'instabilità) installare un kernel mainline .
i915quindi probabilmente risolto dalla stessa patch, ma la segnalazione di bug riguarda problemi risolti dal parametro intel_idle e se ciò non funziona per te si tratta di un bug diverso a seconda del gente del kernel. Potete per favore fornire una segnalazione di bug o un thread del forum (dite che altri condividono il vostro problema) dove posso saperne di più, così posso consigliarvi cosa fare dopo? (Penso che potresti dover fare una nuova domanda)
C'è una correzione per questo in Come impostare intel_idle.max_cstate = 1 .
In terminal, digitare:
gksudo gedit /etc/default/grub
e cambia questa riga:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
per includere questo:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=1"
Quindi fa:
sudo update-grub
reboot
Questo è un problema Intel, non un problema Ubuntu, ma meno male che abbiamo una soluzione.
Nessuno sa se Ubuntu 17.04 richiederà questa correzione o no.
Secondo il commento # 1013 nella segnalazione di bug , ora è stato corretto:
Non ho controllato questa discussione da molto tempo, ma ho pensato che avrei dovuto pubblicare i miei risultati nel caso 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.