c'est difficile de bousiller sa carte mère en mettant à jour son BIOS. Je me demande comment ton pote s'y est pris.
Renseignements pris, c’était une Gigabyte pas une Asus, et il s’agissait d’une série semi-pro mal testée et peu vendue. Mais par contre, aux débuts des amd64, c’était bien avec Asus qu’il y a eu plein de problèmes.
C'est pourtant bien une chose extrêmement importante à faire dans ton cas. Si ça se trouve le BIOS corrige un bug errata du chipset...
Ce qui me refroidit, c’est que lorsqu’on a une merde logicielle on tire la sauvegarde. Quand on a une panne matos, soit on renvoit en SAV (donc indisponibilité d’une semaine au grand minimum), soit on jette et on remplace, et il faut attendre que le nouveau matos arrive, le monter, le tester, etc.
Certes, on peut faire de la récup pour avoir des pièces détachées, ou être à l’affut des bons plans pour avoir du spare sous la main, voir même tout acheter en double. Mais dans tous les cas, ça demande du temps et/ou de l’argent... Ça se sent que j’aime pas le matos et que je préfère la partie logicielle ? :)
Avec le test hdparm et le fait que le réseau semblait pas touché, je pensais que le problème était logiciel (du genre bug dans le VFS, ou un truc comme ça), pas matériel. Du coup, l’intérêt de flasher le bios me semblait limité.
Sauf qu’en fait, tout ce que le test hdparm et le réseau montrent, c’est que le problème se pose uniquement à l’écriture (voir mon commentaire plus haut). Donc, ça pourrait venir du matos, finalement.
comment savoir, les changelogs ASUS sont complètement bidons.
Ouais, j’étais déjà allé sur leur site pour voir si le changelog d’une màj bios comportait une mention qui évoquait mon problème. J’ai pu constater à quel point c’est laconique, on a que 2 types de màj : « Improve system stability » ou « Support new CPUs ». Paye tes détails...
Je suis partisan de mettre à jour son BIOS quand il y a une mise à jour (sauf si le changelog est suffisamment explicite pour voir que cela n'est pas pertinent bien sûr).
Et je suis partisan de pas réparer ce qui marche :)
Mais là, ça ne marche pas. Donc, à moins que quelqu’un ait une autre idée, je vais monter une machine de secours au cas où, et je vais tenter la màj du bios. Je vous tiendrais au courant quand ça sera fait. Ici en commentaire si ça marche ; avec un nouveau journal si ça continue à déconner, pour récolter de nouveaux avis.
J’ai aussi testé avec un livecd fedora
En 32 ou 64 bits ?
En 64 bits. Mais comme j’ai dit, le test n’a pas été assez long pour être réellement concluant (juste une nuit, alors que certaines fois le problème démarre après plusieurs jours d’uptimes).
Tu as une raison particulière de fonctionner en 32 bits ?
J’ai installé le système de ma machine perso il y a (très) longtemps, et depuis je l’ai dist-upgradé. Avant l’époque de puppet, je m’embêtais à réinstaller et tout reconfigurer pour d’autres machines. D’une part, après une réinstall, pendant plusieurs semaines je tombais en permanence sur des paquets que j’avais oublié d’installer ou de personnaliser sur le nouveau système. D’autre part, j’ai constaté que lorsque j’avais des bugs sur ma machine perso (qui avait été dist-upgradée au lieu d’être réinstallée), je retrouvais exactement les mêmes bugs sur les systèmes "neufs". Conclusion, je vois pas l’intérêt de passer du temps à installer des paquets manuellement et refaire les configs, si on obtient le même état en faisant dist-upgrade.
Depuis, pour le premier point, de nos jours y’a puppet et compagnie. Sauf que sur ma machine de bureau, j’ai pas mal de trucs personnalisés (et non, tout ce qui est personnalisé n’est pas nécessairement dans ~) et beaucoup ne sont pas dans puppet : à commencer par tout ce qui n’est que sur cette machine de bureau.
Il faudra que je passe en 64 bits un jour, mais pour l’instant avec le PAE, les avantages du 64 bits me semblent pas justifier le temps que ça prendrait de tout reconfigurer sur ma machine perso.
[^] # Re: BIOS / x86-64
Posté par Ytos . En réponse au message Débit ridicule HD et SSD (suite). Évalué à 1.
Renseignements pris, c’était une Gigabyte pas une Asus, et il s’agissait d’une série semi-pro mal testée et peu vendue. Mais par contre, aux débuts des amd64, c’était bien avec Asus qu’il y a eu plein de problèmes.
Ce qui me refroidit, c’est que lorsqu’on a une merde logicielle on tire la sauvegarde. Quand on a une panne matos, soit on renvoit en SAV (donc indisponibilité d’une semaine au grand minimum), soit on jette et on remplace, et il faut attendre que le nouveau matos arrive, le monter, le tester, etc.
Certes, on peut faire de la récup pour avoir des pièces détachées, ou être à l’affut des bons plans pour avoir du spare sous la main, voir même tout acheter en double. Mais dans tous les cas, ça demande du temps et/ou de l’argent... Ça se sent que j’aime pas le matos et que je préfère la partie logicielle ? :)
Avec le test hdparm et le fait que le réseau semblait pas touché, je pensais que le problème était logiciel (du genre bug dans le VFS, ou un truc comme ça), pas matériel. Du coup, l’intérêt de flasher le bios me semblait limité.
Sauf qu’en fait, tout ce que le test hdparm et le réseau montrent, c’est que le problème se pose uniquement à l’écriture (voir mon commentaire plus haut). Donc, ça pourrait venir du matos, finalement.
Ouais, j’étais déjà allé sur leur site pour voir si le changelog d’une màj bios comportait une mention qui évoquait mon problème. J’ai pu constater à quel point c’est laconique, on a que 2 types de màj : « Improve system stability » ou « Support new CPUs ». Paye tes détails...
https://www.asus.com/Motherboards/H170-PRO-GAMING/HelpDesk_Download/
Et je suis partisan de pas réparer ce qui marche :)
Mais là, ça ne marche pas. Donc, à moins que quelqu’un ait une autre idée, je vais monter une machine de secours au cas où, et je vais tenter la màj du bios. Je vous tiendrais au courant quand ça sera fait. Ici en commentaire si ça marche ; avec un nouveau journal si ça continue à déconner, pour récolter de nouveaux avis.
J’ai installé le système de ma machine perso il y a (très) longtemps, et depuis je l’ai dist-upgradé. Avant l’époque de puppet, je m’embêtais à réinstaller et tout reconfigurer pour d’autres machines. D’une part, après une réinstall, pendant plusieurs semaines je tombais en permanence sur des paquets que j’avais oublié d’installer ou de personnaliser sur le nouveau système. D’autre part, j’ai constaté que lorsque j’avais des bugs sur ma machine perso (qui avait été dist-upgradée au lieu d’être réinstallée), je retrouvais exactement les mêmes bugs sur les systèmes "neufs". Conclusion, je vois pas l’intérêt de passer du temps à installer des paquets manuellement et refaire les configs, si on obtient le même état en faisant dist-upgrade.
Depuis, pour le premier point, de nos jours y’a puppet et compagnie. Sauf que sur ma machine de bureau, j’ai pas mal de trucs personnalisés (et non, tout ce qui est personnalisé n’est pas nécessairement dans ~) et beaucoup ne sont pas dans puppet : à commencer par tout ce qui n’est que sur cette machine de bureau.
Il faudra que je passe en 64 bits un jour, mais pour l’instant avec le PAE, les avantages du 64 bits me semblent pas justifier le temps que ça prendrait de tout reconfigurer sur ma machine perso.