Mon netbooke LDLC Mercure (Clevo M1111 pour les intimes) est affecté par ce bug. Le BIOS est pourri car les développeurs ont utilisé le compilateur Microsoft, plus permissif que celui d'Intel. J'ai tenté le aspm=force, mais sans grand résultat sur l'autonomie, et des blocages plus fréquents en retour de veille.
J'avais donc suivi la procédure: désassemblé les tables du BIOS, corrigé les erreurs de compilation apparaissant avec le compilateur Intel... Et là c'est le drame. La fonctionnalité permettant de simplement indiquer un fichier externe correspondant à la table DSDT à utiliser a été retirée pour des raisons de sécurité, la politique actuelle étant que ce type de choses doit être corrigé dans le kernel, et pas en local chez les utilisateurs. J'ai eu la flemme de recompiler un kernel ou bidouiller mon initrd pour ça...
Au final, savoir que l'utilisateur lambda qui n'a pas forcément de connaissances poussées va pouvoir bénéficier de ces avancées est très positif. Ce qui l'est moins, c'est tout le temps qui s'est écoulé entre la détection du problème et sa correction, et ensuite sa propagation dans les différentes distributions Linux. Du coup, un problème de ce genre impacte les utilisateurs pendant facilement un an, alors que le libre a la réputation d'être réactif. Il faut encore progresser...
# Enfin !
Posté par liberforce (site web personnel, Mastodon) . En réponse à la dépêche Une solution au problème de consommation du noyau Linux. Évalué à 7.
Mon netbooke LDLC Mercure (Clevo M1111 pour les intimes) est affecté par ce bug. Le BIOS est pourri car les développeurs ont utilisé le compilateur Microsoft, plus permissif que celui d'Intel. J'ai tenté le aspm=force, mais sans grand résultat sur l'autonomie, et des blocages plus fréquents en retour de veille.
J'avais donc suivi la procédure: désassemblé les tables du BIOS, corrigé les erreurs de compilation apparaissant avec le compilateur Intel... Et là c'est le drame. La fonctionnalité permettant de simplement indiquer un fichier externe correspondant à la table DSDT à utiliser a été retirée pour des raisons de sécurité, la politique actuelle étant que ce type de choses doit être corrigé dans le kernel, et pas en local chez les utilisateurs. J'ai eu la flemme de recompiler un kernel ou bidouiller mon initrd pour ça...
Au final, savoir que l'utilisateur lambda qui n'a pas forcément de connaissances poussées va pouvoir bénéficier de ces avancées est très positif. Ce qui l'est moins, c'est tout le temps qui s'est écoulé entre la détection du problème et sa correction, et ensuite sa propagation dans les différentes distributions Linux. Du coup, un problème de ce genre impacte les utilisateurs pendant facilement un an, alors que le libre a la réputation d'être réactif. Il faut encore progresser...