illys a écrit 3 commentaires

  • # Instabilité Dedibox en 64 bits, suite !

    Posté par  . En réponse au message Crashs Linux 64 bit / Dovecot avec proc Nano U2250. Évalué à 3.

    En continuant encore à creuser un peu, j'ai trouvé ça :

    1) La promo du U2250 sur le site de Via :

    Les premiers mots sont : "**The first 64-bit**, superscalar processors in VIA's x86 platform portfolio".
    Ce qui tend à confirmer le manque de maturité du jeu d'instructions 64 bits sur ce processeur.
    A priori, inutile donc de déclarer des bugs aux équipes Dovecot, gcc ou noyau Linux.

    Source : http://www.via.com.tw/en/products/processors/nano/

    2) Maintenant que j'arrive à mettre des mots sur le coeur du problème, Google est redevenu mon ami et je me sens de moins en moins seul :

    J'ai en particulier trouvé un fil sur les forums d'Online.net qui montre un large groupe d'utilisateurs qui se plaignent d'instabilité de leur Linux sur Dedibox. La solution du passage en 32 bits est évoquée et marche aussi pour eux. De plus sur ce fil, des administrateurs interviennent (visiblement employés par Online). Je cite le message de Poiuyt (un client) du 25 octobre 2013 :


    (…) Vraisemblablement à la lecture de l'ensemble des bug reports de Coreboot ou de Redhat, le soucis se trouve dans le microcode du processeur VIA qui ne gère pas forcément très bien certaines instructions amd64 et particulièrement des instructions ou séquences qui touchent aux modifications de fréquence du CPU.

    (…)

    Plusieurs solutions au problème :

    • passer en OS 32 bits

    • utiliser un kernel qui ne pose pas de problème avec le CPU des Dedibox SC (genre PAS Debian 7 ou Ubuntu 12.04 ou supérieur, à savoir ce que les gens censés vont prendre pour faire un serveur stable et maintenu)

    • changer de fournisseur de serveur (…)

    (…)

    En bref, nous sommes sans doute des centaines à utiliser des Dedibox SC actuellement, donc les machines redémarrent (ou pas) sans arrêt parfois plusieurs fois par jour, il y a un moment ou l'escroquerie doit s'arrêter.

    Arnaud, merci de répondre par un argument technique ou au mieux commercialement valable. Je me doute que Xavier est au courant et il conviendrait de faire quelque chose pour en finir.


    Source : http://forum.online.net/index.php?/topic/3542-important-probl%C3%A8me-de-stabilit%C3%A9-sur-les-sc/page-4

    Du coup je commence à trouver mon contact au support nettement moins sympa et disponible, je le trouve même d'une incompétence coupable :

    1) j'ai perdu mes soirées pendant 2 semaines pour un problème qui doit toucher des centaines de Dedibox
    2) lors de l'installation de Debian sur leur console, le 64 bits est recommandé
    3) la solution est disponible sur leur forum depuis des mois
    4) l'administrateur intervient quelques messages plus bas en demandant les numéros de ticket et en disant "Une nouvelle fois, le problème est connus et les solutions sont très simples."
    5) depuis des mois, la majorité de leurs tickets sur des machines Linux doit être directement liée à ce problème !

    Bref si on oublie le 64 bits, ça reste une très belle offre au niveau du rapport qualité-prix, mais le service humain est rendu par des clowns !

    Excusez-moi si je vide mon sac, mais je préfère témoigner pour que ceux qui passeront derrière moi sachent à quoi s'en tenir et ne perdent pas leurs soirées et week-ends.

  • [^] # Re: Il n’y a pas que Dovecot

    Posté par  . En réponse au message Crashs Linux 64 bit / Dovecot avec proc Nano U2250. Évalué à 1.

    Est-ce que vous pouvez essayer de réinstaller l'OS en 32 bits et nous dire si ça règle le problème ?

  • [^] # Re: j'ai déplacé le post dans la rubrique 'astuces'

    Posté par  . En réponse au message Crashs Linux 64 bit / Dovecot avec proc Nano U2250. Évalué à 1.

    Merci pour le classement plus pertinent.

    Pour les plantage, je ne suis pas sûr que ce soit à l'équipe de Dovecot de faire quelque chose : s'il s'agit bien d'un comportement spécifique au processeur, le problème n'est pas dans l'algorithme de Dovecot mais dans le code binaire généré lors de la compilation…

    Peut-être que c'est le comportement du compilateur (gcc ?) qu'il faut adapter.

    A ma connaissance le noyau est aussi capable d'intercepter et de prévenir l'exécution de certains opcodes lorsqu'un bug processeur est connu.
    En effet, un système ne doit pas exploser en vol sous la simple action d'une application. D'autant que ça peut être exploité comme une vulnérabilité par des attaquants.

    Enfin bref, je ne sais pas trop à qui soumettre un bug dont je ne connais que l'expression sur un logiciel donné.

    Pour l'instant je me suis donc contenté de signaler mon hypothèse et une façon de résoudre le problème sur les deux forums qui en parlaient… Histoire que ceux qui luttent contre ce problème aient une chance de trouver cette solution sur les moteurs de recherche.