Soluzione della community

ZimaOS si blocca ogni giorno su un Aoostar R1 N150: impostazioni di alimentazione i915/NVMe e limiti delle prove

A November 2025 Aoostar R1 N150 thread where ZimaOS hard-locked after about a day. The user changed i915 power-saving and NVMe deep-power-state boot parameters and then reported four days of uptime. IceWhale separately suggested testing with Search disabled, but no dump log confirmed the exact root cause.

Questo thread di origine contiene un utile esperimento di stabilità verificato dalla community, ma non dimostra una causa principale nel kernel. Un Aoostar R1 con Intel N150 eseguiva ZimaOS per circa un giorno, poi si bloccava completamente: il display diventava nero, il ping smetteva di funzionare e la WebUI diventava irraggiungibile finché non veniva tolta e ridata alimentazione.

L’autore originale aggiunse infine diversi parametri di gestione dell’alimentazione di Intel i915, oltre a un parametro relativo allo stato di alimentazione NVMe, alla riga di comando di avvio di ZimaOS. Quattro giorni dopo riferì che il sistema era rimasto continuamente operativo e definì efficace la modifica. Si tratta di una verifica significativa da parte dell’utente, ma nessun dump di arresto ha collegato il problema a una specifica funzione i915, al controller NVMe o a entrambi.

Si trattava del blocco completo dell’host, non del semplice arresto anomalo di un’app

I sintomi descritti nella fonte erano un display nero, ping non funzionante, WebUI irraggiungibile e la necessità di un ciclo di alimentazione fisico. Questa classe di errore è più ampia del crash di un container Docker o di una sessione del browser rimasta inattiva e dovrebbe essere analizzata a livello di host, kernel o hardware.

Lo stesso mini PC era rimasto stabile con Unraid

L’utente ha dichiarato che l’Aoostar R1 era rimasto stabile per diversi giorni con Unraid durante la preparazione delle unità, poi aveva iniziato a bloccarsi quotidianamente dopo l’installazione di ZimaOS. Ciò rende plausibile un’interazione software o dei driver, ma sistemi operativi diversi utilizzano kernel, driver e criteri di gestione dell’alimentazione diversi sullo stesso hardware.

La gestione dell’alimentazione di i915 e NVMe è diventata la principale ipotesi della community

L’utente ha trovato la riga di comando di avvio di ZimaOS in /mnt/boot/cmdline.txt e vi ha aggiunto:

nvme_core.default_ps_max_latency_us=0
i915.enable_psr=0
i915.enable_fbc=0
i915.enable_dc=0
i915.enable_guc=0

Si trattava di parametri selezionati dall’utente per la diagnosi, non di una configurazione standard prescritta da IceWhale per i sistemi Intel N100/N150.

L’utente ha riferito quattro giorni di operatività dopo la modifica

Il 21 novembre l’autore originale è tornato riferendo che il sistema aveva raggiunto quattro giorni di operatività ed era ancora in esecuzione. Ciò supporta la conclusione che le modifiche abbiano migliorato la stabilità di quella macchina, ma non permette di determinare quale parametro sia stato determinante.

Zima-Giorgio ha indicato altri report secondo cui la disattivazione della ricerca di ZimaOS aveva migliorato la stabilità su alcune macchine. Si tratta di indicazioni ufficiali separate per la risoluzione dei problemi e non devono essere associate alla teoria su i915/NVMe come se IceWhale avesse confermato la stessa causa.

Le prove del crash sono più utili che modificare ogni possibile impostazione di alimentazione

Un altro partecipante ha avvertito che, in assenza di dump o log del precedente avvio, gli utenti possono finire per modificare alimentazione della GPU, alimentazione NVMe, ASPM, stati C, rete e ricerca senza sapere quale livello abbia effettivamente avuto un problema. In un caso attuale, dopo il ripristino raccogli i log del kernel e dei servizi dell’avvio precedente e confronta gli orari attorno all’ultima attività completata correttamente.

Il supporto x86 generico non significa che ogni criterio di alimentazione dei mini PC sia stato convalidato in anticipo

Attualmente ZimaOS supporta ufficialmente hardware x86-64 generico, ma schede madri, controller di archiviazione, adattatori grafici e schede di rete di terze parti possono richiedere ulteriori verifiche di compatibilità.

Consulta gli attuali limiti per la risoluzione dei problemi su sistemi x86 di terze parti prima di presumere che un blocco su N150 abbia un’unica soluzione universale.

Un ordine di risoluzione dei problemi più sicuro

  1. Aggiorna all’attuale versione stabile di ZimaOS.
  2. Annota la versione del BIOS e ripristina impostazioni firmware conservative.
  3. Dopo un crash, raccogli i log del kernel e dei servizi dell’avvio precedente.
  4. Controlla lo stato dell’SSD/NVMe, la temperatura, la RAM e l’alimentazione.
  5. Verifica se la ricerca o un altro carico di lavoro riproducibile è correlato al blocco.
  6. Quando possibile, modifica un solo parametro di avvio alla volta.
  7. Conserva una copia della riga di comando di avvio originale, così da poter annullare la modifica.

Domande frequenti sui blocchi di Aoostar N150

L’utente della fonte ha riferito una maggiore stabilità?

Sì. Ha riferito quattro giorni di operatività dopo aver modificato i parametri di avvio relativi alla gestione dell’alimentazione di i915 e NVMe.

IceWhale ha confermato che i915 fosse la causa principale?

No. IceWhale ha suggerito separatamente di eseguire un test con la ricerca disabilitata; nessun log di dump ha confermato l’origine precisa del problema.

Ogni utente di ZimaOS con Intel N150 dovrebbe disabilitare PSR, FBC, DC e GuC?

No. Queste impostazioni erano un esperimento diagnostico specifico della fonte, non una configurazione consigliata universalmente.