Un BSOD lié à un CPU AMD plutôt chiant !

Illustration AMD Phenom
AMD Phenom

Mon PC n’ est plus tout jeune, les pièces datent pour les plus vieilles de 2006 (M2N-SLI Deluxe) et pour les plus jeunes de 2008 (HD4850) mais il continue malgré tout de me convenir la puissance requise aujourd’hui n’ ayant pas explosé puis … je joue moins qu’ avant. Relié en plus sur un 27 pouces en 2560*1440 (IPS coréen) je n’ ai pas besoin d’anti aliasing poussé, le GPU ne souffre donc pas trop. Pourtant depuis que j’ ai acheté mon CPU, un AMD Phenom 9850 Black Edition (et le Black Edition est important pour rire ou pleurer ensuite) , c’ est la galère et cette galère se nomme A clock interrupt was not received on a secondary processor within the allocated time interval.

A l’ époque nous étions encore en plein age d’or de Windows XP, même si l’arlésienne Windows Vista avait commencé, comme pratiquement tout le monde donc j’étais sur un système 32bits et comme je ghostait mon système pour l’upgrade je ne risquais pas de passer en 64 bits tout de suite. Côté Linux je ne me posais guère la question, il y avait bien sûr une version 64 bits de Debian ou Ubuntu mais à l’époque passer sur un noyau 64bits pour du Desktop c’était se priver de pas mal de choses. Tout allait donc bien dans le meilleurs des mondes jusqu’à ce que j’essaye d’installer un système 64 bits sur la machine. A partir de là les choses ce sont gâtés, sous Linux le système s’installait bien, je pouvais rester dessus entre 10 minutes et parfois 6 heures (plus souvent 2 heures maximum), autant dire qu’au début la stabilité légendaire du noyau Linux en a pris un coup, surtout que les logs n’indiquaient strictement rien. Pour Windows c’est venu plus tard, quand j’ai commencé à me sentir bridé avec la limite des 2,5Go de RAM (puisque la CG a 1Go) j’ai voulu installer Windows 7 64bits et là le drame, BSOD systématique à chaque installation avec ce fameux A clock interrupt was not received on a secondary processor within the allocated time interval et hier comme aujourd’hui il était très difficile de trouver des infos sur ce foutu écran bleu pas très explicite. Je me souviens avoir plus ou moins tout tenté pour installer ce foutu Windows 7 en 64bits (tournant déjà sur cet OS en 32), enlever la Sound Blaster, ne laisser que le minimum vital activé (Cool’ n Quiet, raid, etc. désactivés) et relié (HUB USB, manette, etc., débranchés) ou encore upgrade le BIOS mais en vain. Pendant plusieurs années j’ai essayé de temps à autre toujours sans succès.

En juillet dernier ma ligne téléphonique a été décâblée accidentellement (-_-), passer la crise de nerf il a bien fallu tuer le temps, j’ai donc décidé de me ré attaquer à ce problème de CPU en 64bits. Monitorant en permanence ma machine avec Open Hardware Monitor j’avais bien remarqué depuis longtemps que le CPU était cadencé au maximum à 2512Mhz au lieu des 2500Mhz par défaut, je pensais plus que c’était un problème de lecture des données avec la carte mère ASUS (déjà rencontré) que la cadence réel. Mais en fait pas du tout il s’agissait bien de la fréquence réel car le bus au lieu d’être en 200Mhz est à 201Mhz et il m’a été impossible de corriger cet erreur. Dans le BIOS c’est bien réglé à 200Mhz, pour compliqué l’affaire c’est le minimum, je ne peux pas descendre à 199Mhz par exemple. J’ai donc modifié les réglages du BIOS pour compenser ce (très) léger overclock et bingo, plus de BSOD à l’installation de Windows. La machine était capable de tenir le 64 bits parfois toute une journée, avec par contre un écran bleu systématique dans les dix premières minutes après le boot.

Cependant j’ai rencontré un nouveau problème, dès que j’installai un programme j’avais presque systématiquement l’écran bleu qui revenait. J’ai donc cherché une solution que j’ai fini par trouver en passant bêtement le mode d’énergie à économie lors d’une installation mais c’était vite lourd alors j’ai trouvé une solution définitive j’ai réglé l’utilisation maximale du CPU à 99% dans le mode d’énergie normal et depuis plus aucun plantage. Pour Linux c’est plus compliqué il ne plante pas spécialement sur une action particulière, c’est totalement aléatoire dès qu’on utilise du CPU et je n’ai pas encore trouvé de logiciel capable de bloquer l’utilisation du CPU à une utilisation maximale et il n’est pas du tout possible de faire cela avec le système de gouverneur de Linux.  Pour l’instant je fais donc avec les crash, même si certaine journée il n’y en a pas.

Quoi qu’ il en soit je suis fortement déçu d’AMD que j’ intègre pourtant dans des configuration depuis le début des années 2000. Pour un processeur haut de gamme soit disant Black Edition et donc normalement testé avant la sortie d’usine pour ses capacités d’ overclocking c’est tout même un comble qu’ il ne tienne pas un overclock de 0.5%, overclock manifestement provoqué en plus par un bug du bus de la CM  et donc non volontaire. Je regrette de ne pas avoir compris plus tôt qu’ il ne s’ agissait pas d’un bug software mais hardware, il serait sinon retourné illico d’ où il venait. Ajouté à cela les drivers minables qu’on se traîne sur Linux depuis des années (même si il semble y avoir des améliorations que je ne peux constater puisque ma CG est maintenant legacy….) avec des performances exécrables et l’impossibilité d’avoir un big desktop de plus de 4000*4000 autant dire que pour moi AMD c’est pour le moment terminé. La prochaine machine ce sera Intel et Nvidia, même si pour ce dernier le rapport perfs/prix est moins bon que AMD (ATI).

Laisser un commentaire

%d blogueurs aiment cette page :