Cette page a pour but d'énumérer des pistes pour aider votre diagnostic :
La page diagnostic_outil vous donnera tous les outils clés pour vos recherches.
Le visionneur de journaux peut aussi être très utile pour repérer les messages d'erreurs et cibler les éléments défectueux.
La première chose est la recherche d'informations :
Les constructeurs corrigent leurs bios, soit pour ajouter des fonctionnalités (nouveau processeur pris en charge) soit pour corriger des bugs. c'est une bonne idée de voir les logs des dernières versions des bios.
Vous avez peut être donné de mauvaises options au bios, essayez de faire un clear CMOS.
Un cas particulier est une mauvaise table DSDT, qui ne pose pas de problème à Windows, mais plus à linux lors de l'utilisation de l'acpi. En principe les contournements existent dans le noyau linux, sauf pour des cartes trop récentes, si ça marche mieux avec noacpi au boot, c'est peut-être votre cas.
Plus rare de nos jours, mais il se peut que des IRQ entrent en conflit, par exemple suite à l'installation d'une nouvelle carte sur le port pci/agp/pci-e. Une lecture du manuel de la Carte Mère peut aider.
Vous pouvez tenter de changer les IRQ de certains périphériques intégrés, ou les désactiver.
Pensez aussi au clear CMOS, opération qui remet le bios dans sa config d'origine, des fois que vos dons d'overclockeurs soit néfastes à la stabilité.
Il arrive que certaines combinaisons de matériel aient des problèmes (DD/chipset, ram mal supportée…), un memtest avec juste le lecteur de cd branché sur la carte permet déjà de voir si la plate-forme parait stable. Ensuite on ajoute le reste en croisant les doigts.
Dans ce cas aussi les forums peuvent être d'une aide précieuse.
Les pilotes propriétaires ne sont pas toujours d'une très bonne facture. Leur développement reste fermé et a du mal à s'adapter au rythme des nouvelles versions d'ubuntu.
Pour désactiver les pilotes propriétaire passez par : Système>administration>Gestionnaire de pilote propriétaire.
Après de multiples installations d'Ubuntu sur des partitions différentes, un grand nombre de swap peuvent apparaitre. Un seul suffit largement. On peut supprimer ce surplus facilement à l'aide de Gparted. Le système ne s'en portera que mieux.
Un petit test avec memtest86 est peut être nécessaire. L'utilitaire est disponible au démarrage sur le liveCD.
Pour les possesseurs de carte ASUS (notamment P5Q3), il peut exister un problème de reconnaissance et de gestion automatique de la RAM qui cause des freezes à répétition (même avec un bios à jour et malgré les releases notes qui annoncent ce problème comme réglé -à ce jour février 2010-); Pour le résoudre, dans le bios il faut aller à l'onglet “Ai Tweaker menu” et régler le DRAM frequency et le DRAM voltage avec les spécifications du constructeur de votre RAM (par exemple pour une DDR3 : [1.8 V] [1333 Mhz] ) Voir : http://vip.asus.com/forum/view.aspx?id=20090602005541096&board_id=1&model=P5Q3&page=1&SLanguage=en-us
pour cela vous pouvez vous aider des outils de monitoring (lm-sensor, par exemple)
Vous venez d'ajouter un DD et ça ne marche plus comme avant, l'alim est-elle capable de tenir les tensions demandées ?
C'est l'été et le PC s'arrête brutalement ? regardez les températures CPU et GPU, et pensez à nettoyer les radiateurs.
le gel à lieu au lancement du noyau ? vous avez peut être un module qui a besoin de firmware no accessible à ce moment-là, essayez de blacklister les modules suspects.
Les messages du systèmes (logs) sont enregistrés en permanence dans des fichiers textes (.log) que vous pouvez consulter facilement dans le dossier /var/log/.
Par contre, le système d'enregistrement des logs est configuré par défaut pour ménager les disques, lors d'un crash certains messages peuvent donc ne pas être inscrit à cause de ce choix.
Pour débrider l'enregistrement et ainsi obtenir plus de preuves contre votre bug, il peut donc être intéressant de désactiver l'option en question.
Pour cela éditez le fichier /etc/syslog.conf ou /etc/rsyslog.d/50-default.conf sous Lucid Lynx avec les droits administrateur et supprimez le “-” devant /var/log/kern.log comme pour cette exemple :
Changez :
kern.* -/var/log/kern.log
pour :
kern.* /var/log/kern.log
(kern.log correspond aux messages du kernel : le noyaux)
Ensuite on redémarre le démon (service) pour prendre en compte les changements.
sudo /etc/init.d/sysklogd restart
ou sous Lucid Lynx :
sudo restart rsyslog
Après il n'y a plus qu'à faire planter votre système et essayer de récupérer de nouveaux messages d'erreurs. Plus d'information sur la gestion des logs ici
Une option d'affichage dans Nautilus semble être mal gérée par les pilotes propriétaires et peut provoquer de nombreux gels, notamment lors d'un déplacement d'une fenêtre.
Dans mon cas, pour stabiliser la situation, je suis allé dans Nautilus, Édition> Préférences> Onglet Affichage puis j'ai mis sur “Aucun” les trois sélecteurs dans “Libellés de Icônes”.
J'ai trouvé la solution ici : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506715
Contributeur principal : kao_chen.