Ce fil de discussion contient une expérience de stabilité utile, vérifiée par la communauté, mais pas une cause racine du noyau établie. Un Aoostar R1 équipé d’un Intel N150 exécutait ZimaOS pendant environ une journée, puis se bloquait complètement : l’écran devenait noir, le ping cessait de répondre et l’interface Web devenait inaccessible jusqu’à la mise hors tension.
L’auteur original a finalement ajouté plusieurs paramètres de gestion de l’alimentation Intel i915 ainsi qu’un paramètre d’état d’alimentation NVMe à la ligne de commande de démarrage de ZimaOS. Quatre jours plus tard, il a signalé un fonctionnement continu et considéré la modification comme réussie. Il s’agit d’une vérification utilisateur significative, mais aucun vidage mémoire n’a établi que la panne était liée à une fonctionnalité i915 précise, au contrôleur NVMe ou aux deux.
Il s’agissait d’un blocage complet de l’hôte, pas du simple plantage d’une application
Les symptômes signalés étaient un écran noir, un ping sans réponse, une interface Web inaccessible et la nécessité d’effectuer une mise hors tension physique. Ce type de panne dépasse le cadre d’un conteneur Docker qui aurait planté ou d’une session de navigateur obsolète et doit être examiné au niveau de l’hôte, du noyau ou du matériel.
Le même mini-PC était auparavant stable sous Unraid
L’utilisateur a indiqué que l’Aoostar R1 était resté stable pendant plusieurs jours sous Unraid lors de la préparation initiale des disques, puis avait commencé à se figer quotidiennement après l’installation de ZimaOS. Cela rend plausible une interaction logicielle ou de pilote, mais les différents systèmes d’exploitation utilisent des noyaux, des pilotes et des politiques de gestion de l’alimentation différents sur un même matériel.
La gestion de l’alimentation d’i915 et du NVMe est devenue l’hypothèse principale de la communauté
L’utilisateur a trouvé la ligne de commande de démarrage de ZimaOS dans /mnt/boot/cmdline.txt et y a ajouté :
nvme_core.default_ps_max_latency_us=0
i915.enable_psr=0
i915.enable_fbc=0
i915.enable_dc=0
i915.enable_guc=0Il s’agissait de paramètres de dépannage choisis par l’utilisateur, et non d’une configuration standard prescrite par IceWhale pour les systèmes Intel N100/N150.
L’utilisateur a signalé quatre jours de fonctionnement continu après la modification
Le 21 novembre, l’auteur original est revenu indiquer que le système avait atteint quatre jours de fonctionnement continu et était toujours opérationnel. Cela permet de conclure que les modifications ont amélioré la stabilité de cette machine, mais pas d’identifier le paramètre qui a fait la différence.
IceWhale a séparément recommandé de tester le système avec la recherche désactivée
Zima-Giorgio a mentionné d’autres rapports selon lesquels la désactivation de ZimaOS Search avait amélioré la stabilité sur certaines machines. Il s’agit d’une recommandation de dépannage officielle distincte, qui ne doit pas être fusionnée avec l’hypothèse i915/NVMe comme si IceWhale avait confirmé la même cause.
Les éléments de preuve issus des journaux sont plus utiles que la modification de tous les paramètres d’alimentation possibles
Un autre participant a averti qu’en l’absence de vidages mémoire ou de journaux du démarrage précédent, les utilisateurs risquaient de modifier la gestion de l’alimentation du GPU, du NVMe, de l’ASPM et des états C, ainsi que le réseau et Search, sans savoir quelle couche avait réellement échoué. Dans un cas actuel, recueillez les journaux du noyau et des services du démarrage précédent après la récupération, puis comparez les horodatages autour de la dernière activité réussie.
La prise en charge générique de x86 ne signifie pas que chaque politique d’alimentation des mini-PC a été prévalidée
ZimaOS prend officiellement en charge le matériel x86-64 générique, mais les cartes mères, contrôleurs de stockage, adaptateurs graphiques et cartes réseau tiers peuvent nécessiter des vérifications de compatibilité supplémentaires.
Consultez les limites actuelles du dépannage x86 tiers avant de supposer qu’un blocage sur N150 possède une solution universelle.
Ordre de dépannage actuellement recommandé, plus sûr
- Mettez à jour vers la version stable actuelle de ZimaOS.
- Notez la version du BIOS et rétablissez des paramètres de micrologiciel prudents par défaut.
- Recueillez les journaux du noyau et des services du démarrage précédent après un plantage.
- Vérifiez l’état de santé, la température et l’alimentation du SSD/NVMe, ainsi que la mémoire vive.
- Testez si Search ou une autre charge de travail reproductible est corrélée au blocage.
- Lorsque cela est possible, ne modifiez qu’un seul paramètre de démarrage à la fois.
- Conservez une copie de la ligne de commande de démarrage originale afin de pouvoir annuler la modification.
FAQ sur les blocages de l’Aoostar N150
L’utilisateur cité a-t-il signalé une amélioration de la stabilité ?
Oui. Il a signalé quatre jours de fonctionnement continu après avoir modifié des paramètres de démarrage liés à la gestion de l’alimentation d’i915 et du NVMe.
IceWhale a-t-il confirmé qu’i915 était la cause racine ?
Non. IceWhale a séparément recommandé de tester le système avec Search désactivé ; aucun journal de vidage mémoire n’a confirmé la source exacte de la panne.
Chaque utilisateur de ZimaOS équipé d’un Intel N150 devrait-il désactiver PSR, FBC, DC et GuC ?
Non. Ces réglages constituaient une expérience de dépannage propre à cette source, et non une configuration universellement recommandée.
