Bonjour,
J’ai actuellement un serveur sous debian qui plante regulierement, je cherche a diagnosticer d’ou cela pourrait venir, memtest se deroule tranquillement, y a t’il a votre connaissance, un genre de cd bootable qui permettrait de faire un diagnostic complet d’une machine?
Merci par avance!
Tu as un livecd de réparation ( sysresccd.org/Index.fr.php ) qui dispose d’outils de base pour le diagnostic, outils que tu retrouveras dans debian par ailleurs, mais un soft qui analyse n’importe quel hard, je vois mal comment ça pourrait exister (à part dans une fausse annonce de sortie comme il en existe en permanence sous windows). AMA, c’est du même ordre que le mouvement perpétuel.
Par contre, si tu peux décrire plus précisément tes plantages, on peut peut être renifler avec toi les endroits qui sentent l’erreur, et t’inspirer des tests.
En fait la machine fonctionne correctement, mais tous les 4 jours plus rien sur l’ecran on voit des messages de plantage de noyau alors que le meme hd dans une machine identique fonctionne parfaitement ce qui me laisse penser que le probleme vient du hardware 
Ben déjà, programmes un reboot la nuit tous les 3 jours en attendant d’avoir résolu le pb 
Sinon, c’est quoi les messages de noyau plus précisément ?
Tu dis qu’elle n’affiche rien mais elle est figée ? plus moyen d’y accèder par ssh ?
As tu essayé de changer la carte graphique ? Il y a aussi de la mêmoire qui peut planter dedans, sais tu ?
Et as tu bien vérifié tous les branchements internes sur la carte mère ?
(en sortant et en réenfichant tous les cables, la mêmoire, et toutes les cartes, pour s’assurrer que tout est bien enfoncé)
Oui je l’ai fait 4 fois c’ets un probleme recurrent sur cette machine mais j’aimerait pouvoir isoler le probleme parce que ca ferait mal au coeur de jetter un rack supermicro tout entier
télécharge ulimatebootcd c’est le seul que je connaisse qui dispose autant d’outils de diagnostiques.
je vais essayer encore mais bon je commence a criser
Voici les messages d’erreurs lors du plantage:
kernel: Stack: 209d40df 00000004 dfb18180 dfa16480 dfb18204 00000020 de2740c0 c016da85
kernel: 00000000 dfa164d0 00000001 dbff3aa0 00000000 dfe52000 dbff3aa0 c011b08f
kernel: fffffff4 dbcd4000 c011b6d9 df62bfbc bfb0b7d4 01200011 00000000 dbff3aa0
kernel: Call Trace:
kernel: [] d_alloc+0x142/0x18f
kernel: [] copy_files+0x3d/0x54
kernel: [] copy_process+0x454/0x10a9
kernel: [] get_empty_filp+0x99/0x15f
kernel: [] do_fork+0x91/0x17a
kernel: [] sys_socketcall+0xc1/0x181
kernel: [] sys_clone+0x28/0x2d
kernel: [] sysenter_past_esp+0x56/0x79
kernel: Code: 03 74 02 f3 a4 8b 75 0c 89 d1 8b 7b 0c f3 a5 89 c1 83 e1 03 74 02 f3 a4 8b 4c 24 24 31 f6 eb 21 8b 7c 24 10 8b 17 85 d2 74 06 90 42 14 eb 06 8b 43 10 0f b3 30 83 44 24 10 04 89 11 46 83 c1
kernel: EIP: [] dup_fd+0x1b9/0x2c0 SS:ESP 0068:df62bed4
Effectivement ça peut venir d’une mémoire, mais le d_alloc est une allocation de mémoire quand on utilise le VFS linux ( gelato.unsw.edu.au/~dsw/publ … r4956.html ). Le plantage semble bien venir d’une allocation, mais je ne sais pas si cette allocation ne se fait pas physiquement sur le cache du chip ATA. Le pb pourrait venir de cette mêmoire plutôt que de la RAM.
Le fait que ça n’arrive qu’au bout de 4 jour me parait tout de même bizarre, parcequ’avec une mêmoire foireuse, le pb devrait arriver aléatoirement, AMA.
Mais savoir ça n’aide pas beaucoup.
As tu pu voir dans les logs ce que faisait ta machine lors des plantage, des fois que ce soit toujours sur une même tâche administrative demandant beaucoup de ressources disque ?
L’autre machine qui tourne mieux avec le même disque, elle a des différences de hard avec l’autre (en particulier au niveau du chip ATA) ?
Au fait, as tu simplement testé un autre noyau ?
Si tu veux jeter ton supermicro, je le prend 