Este hilo de la comunidad contiene un experimento de estabilidad útil y verificado por usuarios, pero no una causa raíz del kernel demostrada. Un Aoostar R1 con Intel N150 ejecutaba ZimaOS durante aproximadamente un día y luego se bloqueaba por completo: la pantalla quedaba en blanco, el ping dejaba de responder y la WebUI se volvía inaccesible hasta reiniciar el equipo cortando la alimentación.
El autor original del hilo finalmente añadió varios parámetros de administración de energía de Intel i915, además de un parámetro de estado de energía de NVMe, a la línea de comandos de arranque de ZimaOS. Cuatro días después informó que el sistema seguía funcionando de forma continua y consideró que el cambio había tenido éxito. Esto constituye una verificación significativa por parte del usuario, pero ningún volcado de errores vinculó el fallo a una función específica de i915, al controlador NVMe o a ambos.
Fue un bloqueo total del host, no el fallo de una sola aplicación
Los síntomas descritos en la fuente fueron una pantalla en blanco, ping sin respuesta, una WebUI inaccesible y la necesidad de cortar físicamente la alimentación. Este tipo de fallo es más amplio que un contenedor Docker bloqueado o una sesión del navegador obsoleta, por lo que debe investigarse a nivel del host, el kernel o el hardware.
El mismo mini PC había sido estable con Unraid
El usuario afirmó que el Aoostar R1 se había mantenido estable durante varios días con Unraid mientras preparaba las unidades, pero comenzó a congelarse a diario después de instalar ZimaOS. Esto hacía plausible una interacción de software o controladores, aunque distintos sistemas operativos utilizan kernels, controladores y políticas de energía diferentes en el mismo hardware.
La administración de energía de i915 y NVMe se convirtió en la principal hipótesis de la comunidad
El usuario encontró la línea de comandos de arranque de ZimaOS en /mnt/boot/cmdline.txt y añadió:
nvme_core.default_ps_max_latency_us=0
i915.enable_psr=0
i915.enable_fbc=0
i915.enable_dc=0
i915.enable_guc=0Estos fueron parámetros de diagnóstico seleccionados por el usuario, no una configuración estándar prescrita por IceWhale para sistemas Intel N100/N150.
El usuario informó de cuatro días de funcionamiento continuo después del cambio
El 21 de noviembre, el autor original volvió a informar que el sistema había alcanzado cuatro días de funcionamiento continuo y seguía en marcha. Esto respalda la conclusión de que los cambios mejoraron la estabilidad de ese equipo, pero no permite determinar qué parámetro fue decisivo.
IceWhale sugirió por separado realizar pruebas con la búsqueda desactivada
Zima-Giorgio señaló otros informes en los que desactivar la búsqueda de ZimaOS mejoró la estabilidad en algunas máquinas. Esta es una recomendación oficial de diagnóstico independiente y no debe combinarse con la teoría de i915/NVMe como si IceWhale hubiera confirmado la misma causa.
Las pruebas de fallos son más valiosas que modificar todos los ajustes de energía posibles
Otro participante advirtió que, sin volcados ni registros del arranque anterior, los usuarios pueden terminar cambiando la energía de la GPU, la energía de NVMe, ASPM, los estados C, la red y la búsqueda sin saber qué capa falló realmente. En un caso actual, recopila los registros del kernel y de los servicios del arranque anterior después de recuperarte de un fallo y compara las marcas de tiempo en torno a la última actividad correcta.
La compatibilidad genérica con x86 no significa que todas las políticas de energía de los mini PC estén validadas previamente
Actualmente, ZimaOS es compatible oficialmente con hardware x86-64 genérico, pero las placas base, los controladores de almacenamiento, los adaptadores gráficos y las tarjetas de red de terceros pueden requerir comprobaciones de compatibilidad adicionales.
Consulta los límites actuales de solución de problemas para x86 de terceros antes de asumir que un bloqueo en un N150 tiene una única solución universal.
Un orden actual de diagnóstico más seguro
- Actualiza a la versión estable actual de ZimaOS.
- Anota la versión de la BIOS y restaura los valores predeterminados conservadores del firmware.
- Recopila los registros del kernel y de los servicios del arranque anterior después de un fallo.
- Comprueba el estado, la temperatura, la memoria RAM y la alimentación de la unidad SSD/NVMe.
- Comprueba si la búsqueda u otra carga de trabajo reproducible se correlaciona con el bloqueo.
- Cambia un parámetro de arranque cada vez siempre que sea posible.
- Conserva una copia de la línea de comandos de arranque original para poder revertir el cambio.
Preguntas frecuentes sobre los bloqueos del Aoostar N150
¿El usuario de la fuente informó de una mejora de la estabilidad?
Sí. Informó de cuatro días de funcionamiento continuo después de cambiar parámetros de arranque relacionados con la energía de i915 y NVMe.
¿IceWhale confirmó que i915 era la causa raíz?
No. IceWhale sugirió por separado realizar pruebas con la búsqueda desactivada; ningún registro de volcado confirmó el origen exacto del fallo.
¿Debería todo usuario de ZimaOS con un Intel N150 desactivar PSR, FBC, DC y GuC?
No. Esos ajustes fueron un experimento de diagnóstico específico de la fuente, no una configuración recomendada universalmente.
