Mon PC servant de serveur s'est arreté tout seul ??

Mon PC servant de serveur s'est arreté tout seul ?? - Matériels & problèmes divers - Hardware

Marsh Posté le 20-10-2009 à 19:35:07    

Mon PC servant de serveur (un Pentium mmx 166 Mhz, 64Mo de EDO) s'est arreté aujourd'hui en mon absence, et sans que j'en connaisse la raison  :heink:  
 
En fait je l'ai retrouvé pas complètement eteint, les ventilos tournaient et le voyant de marche etait allumé, mais les disque dur etait... arretés ! (ce qui m'a mis la puce à l'oreille c'est que déjà au toucher ils etaient froids...)
 
Donc voila à votre avis qu'a t-il pu se passer, piratage du serveur ? ou problème matériel...
 
Je ne comprend pas comment les ventilos peuvent tourner et le voyant marche être allumé si les disques dur (il y en a 2) sont à l'arret  :pt1cable:  
 
Pis là je l'ai vraiment eteint (bouton marche) et rallumer, il a l'air de tourner nickel :??:
 
Mais que s'est t-il passé :(
 
Si vous voulez (entre autre) des photos du "serveur" en question, allez directement dessus maintenant qu'il refonctionne, il a été HB certified... (mais c'était pas le but du tout):
 
http://macgyver974.homelinux.org
 
Edit: le serveur est sous Linux, et dans le dmesg là après reboot j'ai ça, mais je ne sais pas si ça peut avoir un lien avec le problème d'arret des 2 disques dur... :
 

Citation :


EXT4-fs (hda3): delayed allocation enabled                                    
EXT4-fs: file extents enabled                                                
EXT4-fs: mballoc enabled                                                      
EXT4-fs (hda3): orphan cleanup on readonly fs                                
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 19446        
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44171        
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44169        
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44168        
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44167        
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44166        
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44165        
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44163        
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44162        
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44161        
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44160        
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44159        
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44157        
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44156
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44155
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44154
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44150
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44149
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44148
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44147
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44146
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44145
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44143
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44142
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44141
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44140
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44138
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44135
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44134
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44133
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44132
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44131
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44130
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44129
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44127
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44126
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44125
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44124
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 44064
EXT4-fs (hda3): ext4_orphan_cleanup: deleting unreferenced inode 40596
EXT4-fs (hda3): 40 orphan inodes deleted
EXT4-fs (hda3): recovery complete



Message édité par Mac Gyver 974 le 20-10-2009 à 19:44:25
Reply

Marsh Posté le 20-10-2009 à 19:35:07   

Reply

Marsh Posté le 20-10-2009 à 19:45:52    

Salut,
 
1/ commences par contrôler les log (surtout le kernel, ssh)
2/ si tu n'a rien de rien, alors c'est peut-être un pb venant de l'age du matos, au mieux l'alim, si c'est pas un config AT tu peux encore changer, au pire la mobo.
 
Linux ne plante pas tout seul, jamais, quand ça tourne durant des mois sans soucils et que le kernel n'a pas subbit de modif' entre temps, alors tu es quasi sur que le pb vient du hardware.
 
T'inquiète, j'ai eu le même pb avec mon routeur linux la semaine dernière, Pentium MMX 166MHz, 64Mo de ram EDO, etc..., il a commencé à rebooter tout seul, d'ailleurs au reboot il n'arrivait pas à ouvrir une session ppp tout de suite mais dans la minute qui suit (comportement totalement anormal vu qu'il est censé le faire avant même d'arriver sur le prompt/login), à la fin il crashait caréement sans reboot, comme c'était une alim AT, je l'ai dégagé et j'ai mis un pc à base de pIII avec 392Mo de ram dans un boitier serveur HP 19" 5U à la place, j'avais pas moins puissant :lol:
 
Quand ça arrive sur du matos qui a 13 ans d'age, et 2 ans de 24/7 derrière lui, à la fin la conclusion rapide c'est : *dead, game over*
 
edit : après ton ajout du log, ben c'est de l'ext4 quoi, je ne sais pas si c'est très judicieux de l'utiliser pour un serveur "en prod" (on va dire), disont qu'on ne peut pas le considérer stable à 100%, moi perso, je ne l'utilise absolument pas pour ne pas me créer de nouveaux problèmes (j'en ai déjà bien assez), si je veux faire un gros fs (genre 12To ou plus), je me contente du XFS qui est ultra stable vu les 18 ans d'existance et d'améliorations de ce fs.
Bon après c'est un fs journalisé, ce que tu vois dans le log, à mon avis ce n'est pas la cause mais une conséquence du pb.
 
scénario type : alim mourrante => pc reboot => fs mal démontés donc forcément fsck moyennement net au démarrage
 
Si le pb est d'ordre matos, à voir, ça paraîtrait crédible.
Vérifie aussi le smart des disques avec smartctl, pour voir si ils n'ont pas de pb.
 
edit2: ah ouais, je l'ai déjà vu dans les HB ce serveur  [:athlonxp2100+]

Message cité 1 fois
Message édité par T3K le 20-10-2009 à 20:07:00
Reply

Marsh Posté le 20-10-2009 à 20:07:37    

T3K a écrit :

Salut,
 
1/ commence par contrôler les log (surtout le kernel, ssh)
2/ si tu n'a rien de rien, alors c'est peut-être un pb venant de l'age du matos, au mieux l'alim, si c'est pas un config AT tu peux encore changer, au pire la mobo.
 
Linux ne plante pas tout seul, jamais, quand ça tourne durant des mois sans soucils et que le kernel n'a pas subbit de modif' entre temps, alors tu es quasi sur que le pb vient du hardware.
 
T'inquiète, j'ai eu le même pb avec mon routeur linux la semaine dernière, Pentium MMX 166MHz, 64Mo de ram EDO, etc..., il a commencé à rebooter tout seul, à la fin il crashait caréement sans reboot, comme c'était une alim AT, je l'ai dégagé et j'ai mis un pc à base de pIII avec 392Mo de ram dans un boitier serveur HP 19" 5U à la place, j'avais pas moins puissant :lol:
 
edit : après ton ajout du log, ben c'est de l'ext4 quoi, je ne sais pas si c'est très judicieux de l'utiliser pour un serveur "en prod" (on va dire), disont qu'on ne peut pas le considérer stable à 100%, moi perso, je je l'utilise absolument pas pour ne pas me créer de nouveaux problèmes (j'en ai déjà bien assez), si je veux faire un gros fs (genre 12To ou plus), je me contente du XFS qui est ultra stable vu les 18 ans d'existance et d'améliorations de ce fs.
 
Si le pb est d'ordre matos, à voir, ça paraîtrait crédible.
Vérifie aussi le smart des disques avec smartctl, pour voir si ils n'ont pas de pb.
 
edit2: ah ouais, je l'ai déjà vu dans les HB ce serveur  [:athlonxp2100+]


 
J'utilise ext4 sur un PC qui tourne H24 sans avoir eu de soucis, mais là par contre smart est sans appel: le hdd contenant la partition root a eu une nette augmentation du nombre de secteur réalloué....mais j'avais vu ça plusieurs jours avant le plantage et comme y a pas eu de réallocation entre temps je me suis dit "aucun soucis", normal non ? d'ailleurs est-ce que les 22 secteurs réalloués sont vraiment un soucis ??
 

Citation :

Server-Pentium-mmx mac_gyver # smartctl -A /dev/hda
smartctl version 5.38 [i586-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
 
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 6
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x0029   100   253   020    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0027   090   087   020    Pre-fail  Always       -       4000
  4 Start_Stop_Count        0x0032   099   099   008    Old_age   Always       -       1039
  5 Reallocated_Sector_Ct   0x0033   098   098   020    Pre-fail  Always       -       22
  7 Seek_Error_Rate         0x000b   100   100   023    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0012   062   062   001    Old_age   Always       -       25152
 11 Calibration_Retry_Count 0x0013   100   100   020    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   099   099   008    Old_age   Always       -       1027
 13 Read_Soft_Error_Rate    0x000b   100   100   023    Pre-fail  Always       -       0
199 UDMA_CRC_Error_Count    0x001a   200   200   000    Old_age   Always       -       0


 
après le 1er démarrage du serveur, pleins de secteurs ont été réalloué jours après jour sur les 2 disques dur, mais ça c'est stabilisé et c'est plusieurs jours après la stabilisation que je viens d'avoir cet étrange plantage que je ne m'explique pas  
 
(surtout l'arret physique des 2 disques !)
 
L'autre hdd a eu bien plus de secteurs réalloué mais ça c'est passé sur plusieurs jours après le 1er démarrage puis stabilisé y a quelques jours aussi ! =>

Citation :


Server-Pentium-mmx mac_gyver # smartctl -A /dev/hdb
smartctl version 5.38 [i586-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
 
=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 5
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x0008   076   066   000    Old_age   Offline      -       189955003
  3 Spin_Up_Time            0x0006   070   070   000    Old_age   Always       -       0
  4 Start_Stop_Count        0x0013   099   099   020    Pre-fail  Always       -       1810
  5 Reallocated_Sector_Ct   0x0013   099   099   036    Pre-fail  Always       -       122
  7 Seek_Error_Rate         0x000b   060   060   030    Pre-fail  Always       -       64507143212
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0013   099   099   020    Pre-fail  Always       -       2029
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0


 
Mais ce dernier ne contient "que" /usr/portage, les sources du noyau et le home (dans lequel on a en lien symbolique le dossier /var/tmp et le dossier des documents html et autre images de apache)

Reply

Marsh Posté le 20-10-2009 à 20:15:03    

c'est quoi les disques en question ? vu le faible nb d'attributs, je pense que c'est des vieux bouzins, genre quantum, je me trompe ? :D
 
hdb est super inquiètant quand même, 122 secteurs réalloués ce n'est pas du tout rassurant. (sachant qu'il n'y a peut-être sûrement déjà plus de secteurs de secours), enfin il n'est pas encore en status FAILED donc à priori ce n'est pas encore pour ajourd'hui que les carottes sont cuites
 
honnêtement, à ta place, j'aurais déjà changé les hd et recopié les partoches avec un coup de dd puis redimentionné le tout avec un coup de gparted)
 
Tu as combien de jours/semaines de recul sur cette machine ?

Message cité 1 fois
Message édité par T3K le 20-10-2009 à 20:17:58
Reply

Marsh Posté le 20-10-2009 à 20:20:09    

T3K a écrit :

c'est quoi les disques en question ? vu le faible nb d'attributs, je pense que c'est des vieux bouzins, genre quantum, je me trompe ? :D
 
hdb est super inquiètant quand même, 122 secteurs réalloués ce n'est pas du tout rassurant. (sachant qu'il n'y a peut-être sûrement déjà plus de secteurs de secours)
 
honnêtement, à ta place, j'aurais déjà changé les hd et recopié les partoches avec un coup de dd puis redimentionné le tout avec un coup de gparted)
 
Tu as combien de jours/semaines de recul sur cette machine ?


 
ça doit faire 3 semaine que mon serveur tourne H24 là :??:, pour les hdd tu as tapé dans le mille, hda est un Quantum de 1,6Go  :lol:  
 
Quand au hdd avec 122 secteurs réalloué, c'est un Seagate de 3,2 Go ;)
 
Donc d'après toi je devrais vraiment m'interesser à l'état de mes hdd hda et hdb  :whistle:  
 
Mais est-ce que l'état des disques peut avoir comme conséquence (sous Linux) l'arret physique simultané des deux disques :??:
 
Edit: je suppose simultané, j'étais pas là


Message édité par Mac Gyver 974 le 20-10-2009 à 20:22:20
Reply

Marsh Posté le 20-10-2009 à 21:19:25    

non, je ne pense pas que l'état physique pourrait mettre les disques en veille
au pire, tu aurait des réinitialisation des disques (tu aurais des trucs pour kernel)
 
là ton histoire fait penser à un pb d'alim, franchement si c'est de l'ATX, essaye avec une autre alim  pour commencer
 
 
C'est quoi comme distro sinon ?

Reply

Marsh Posté le 20-10-2009 à 21:41:21    

Sympa en tout cas de réutiliser le vieux matos, mais j'avoue que je n'aurais aucune confiance en des disques du genre 1/2/4 Go vu leur âge :)
 


---------------
Guide OC x58 - Guide d'achat de config - ALIMS:qui fait quoi? - RKO - Radiooooo
Reply

Marsh Posté le 20-10-2009 à 21:44:09    

bah ça dépend, j'ai encore un disque (dans le routeur), c'est un quantum de 3.2Go et il est comme neuf (il est presque neuf : 500 heures au compteur, 0 secteurs défect.) \o/
 
il a juste tourné 24/7 depuis septembre, avant j'avais un disque plus petit mais il a commencé à avoir trop de secteurs défecteurs, donc je l'ai changé


Message édité par T3K le 20-10-2009 à 23:57:24
Reply

Marsh Posté le 21-10-2009 à 05:20:50    

T3K a écrit :

non, je ne pense pas que l'état physique pourrait mettre les disques en veille
au pire, tu aurait des réinitialisation des disques (tu aurais des trucs pour kernel)
 
là ton histoire fait penser à un pb d'alim, franchement si c'est de l'ATX, essaye avec une autre alim  pour commencer
 
 
C'est quoi comme distro sinon ?


 
C'est une Gentoo, l'alim est electriquement une AT (connecteurs P1, P2 et P3 pour alimenter la carte mère, P3 n'est pas utilisé sur ma mb), par contre mécaniquement elle est au format classique ATX. J'ai une alim. electriquement ATX qui traine, et on m'a expliqué sur HFR que moyennant bidouille elle peut servir dur une carte mère AT, donc si vraiment j'ai encore le problème des disques arreté je tenterais la bidouille. (le serveur sera encore plus HB dans ce cas là :D)

Reply

Marsh Posté le 21-10-2009 à 18:40:46    

Donc surement l'alim qui commence à merder (elle a 10/12 ans au moins), c'est le genre de trucs qui peut provoquer des secteurs défectueux sur les disques au passage.
 
allez hop, il ne reste plus qu'à trouver des dominos, et de l'adhésif double face à miroirs pour appliquer le hb qui va bien (ah nan c'est vrai : pas de boiter en tôles), tu peux même renforcer le bout des fils à passer dans les domino à coup de fer à souder, ça évitera de les effilocher (ma technique perso pour électrifier des lustres anciens qui doivent se démonter facilement, mais bon ça marche aussi très bien avec les alim PC  :pt1cable: )
Un HB digne de la nasa quoi \o/

Message cité 1 fois
Message édité par T3K le 21-10-2009 à 18:50:47
Reply

Marsh Posté le 21-10-2009 à 18:40:46   

Reply

Marsh Posté le 21-10-2009 à 19:54:36    

T3K a écrit :

Donc surement l'alim qui commence à merder (elle a 10/12 ans au moins), c'est le genre de trucs qui peut provoquer des secteurs défectueux sur les disques au passage.
 
allez hop, il ne reste plus qu'à trouver des dominos, et de l'adhésif double face à miroirs pour appliquer le hb qui va bien (ah nan c'est vrai : pas de boiter en tôles), tu peux même renforcer le bout des fils à passer dans les domino à coup de fer à souder, ça évitera de les effilocher (ma technique perso pour électrifier des lustres anciens qui doivent se démonter facilement, mais bon ça marche aussi très bien avec les alim PC  :pt1cable: )
Un HB digne de la nasa quoi \o/


 
Ah bon  :ouch: aie aie aie, il me faut donc agir des ce WE...enfin si j'ai le tps car j'ai un rendez vous galant normalement :o .
 
Bon ben HB sur l'alim. alors, surtout que le disque root fait des bruits étranges par moment, ça m'inquiete...(genre frottement de ventilo, sauf que là ça vient du disque...et ça le fait de plus en plus souvent...)
 
ça me fait chier car j'espère pouvoir remonter physiquement l'alim ATX dans le carton du serveur, c'est un système 100% mac gyver, j'ai fait 2 tranché au cutter dans le carton et refermer le capot de l'alim. en l'enfermant dans ces tranché (j'ai donc du carton à l'intérieur même de l'alim  :lol: ) c'est la seule soluce que j'avais trouvé pour fixer correctement l'alim. qui est un élément un peu lourd, au carton...
 
Edit: quelques messages inquietants dans mon /var/log/message :o

Citation :


Oct 20 22:33:32 Server-Pentium-mmx hdb: task_pio_intr: status=0x51 { DriveReady SeekComplete Error }                                                                                
Oct 20 22:33:32 Server-Pentium-mmx hdb: task_pio_intr: error=0x04 { DriveStatusError }                                                                                              
Oct 20 22:33:32 Server-Pentium-mmx hdb: possibly failed opcode: 0xb0                                                                                                                
Oct 20 22:33:32 Server-Pentium-mmx hdb: task_pio_intr: status=0x51 { DriveReady SeekComplete Error }                                                                                
Oct 20 22:33:32 Server-Pentium-mmx hdb: task_pio_intr: error=0x04 { DriveStatusError }                                                                                              
Oct 20 22:33:32 Server-Pentium-mmx hdb: possibly failed opcode: 0xb0  


Message édité par Mac Gyver 974 le 21-10-2009 à 20:13:48
Reply

Marsh Posté le 22-10-2009 à 00:16:41    

bon, j'ai regardé ton HB de près, tu va rire : c'est exactement rigoureusement la même mobo et la même alim que j'avais dans ma tour routeur (un vieux zenith z-station el)
Sauf que j'ai encore le boîtier, il est gros comme un rack 19" 3U et fait environ 45cm de profondeur.
 
mieux : on tombe en rade au même moment à quelques jours près, pas mal pour des machines de 1996.
 
Le tout premier problème est apparu chez moi, fin juillet : exactement la même chose que ce que tu décris là, j'avais d'autres choses à faire, donc j'ai dégagé le routeur, j'ai mis un FVS114 que j'avais sous le coude à la place, et j'ai tourné avec près d'un mois.
Seullement, entre-temps, j'ai changé le lecteur CD, et tout était reparti comme sur des roulettes, début septembre, très très insatisfais du FVS114, je décide de remettre mon routeur linux à sa place d'origine et je dégage le FVS114 qui retourne à sa fonction initiale de presse papier :lol:.
 
la semaine dernière, même symptomes que ce que tu as donné au début: linux reboot tout seul sans raisons apparentes (ça c'était au début), après, les choses ont même empiré : crash, pas de reboot
 
donc dans la nuit de vendredi à samedi (ouais j'avais que ça à faire :D), je vire le vieux routeur, je mets un ancien server PIII à la place, gros et bruyant comme pas possible (Rack 19" 5U), mais un vrai bonheur à l'usage en comparaison du PI \o/
donc, depuis samedi ap midi 15H, j'avais remis mon routeur Pentium I mmx en test, tout seul dans son coin, branché à cheval sur 2 switch à part (pas sur mon réseau), j'ai modif un poil le démarrage (wait infini pour charger le cpu à 100% en permanence dès la fin du démarrage)
 
il a tourné jusqu'à ce mercredi après midi 17H avant de planter, quand ce soir je l'ai vu, je l'ai rebooter (il était freezé totalement), il a rebooter à nouveau avant même de finir le démarrage.
 
Donc là, tout comme toi, j'aimerais bien à nouveau faire tourner cette bécanne, j'ai des alim en stock, j'aimerais bien moi aussi faire un HB pour le faire repartir, je suis à peu prêt sûr que l'alim astec d'origine et ses 13 ans d'age n'est plus en assez bonne santé pour faire tourner tout ce bazard.
Le truc, comme tu l'as constaté, c'est le connecteur avec les fils noir vert et violets
le fil vert est indiqué PS_ON dans l'alim (j'ai regardé le PCB), c'est trop spécifique, à priori pas utile pour un HB
le fil violet est un 5VSB, donc il faudra surement amener un 5VSB d'une alim ATX dessus pour celui là
 
le vrai pb, c'est le fil 1 du connecteur P1, le fil orange : à quoi le relier sur une alim ATX ? \o/
 
bref, j'ajoute sur la liste de courses : "dominos" :lol:

Message cité 1 fois
Message édité par T3K le 22-10-2009 à 00:22:11
Reply

Marsh Posté le 22-10-2009 à 19:09:37    

T3K a écrit :

bon, j'ai regardé ton HB de près, tu va rire : c'est exactement rigoureusement la même mobo et la même alim que j'avais dans ma tour routeur (un vieux zenith z-station el)
Sauf que j'ai encore le boîtier, il est gros comme un rack 19" 3U et fait environ 45cm de profondeur.
 
mieux : on tombe en rade au même moment à quelques jours près, pas mal pour des machines de 1996.
 
Le tout premier problème est apparu chez moi, fin juillet : exactement la même chose que ce que tu décris là, j'avais d'autres choses à faire, donc j'ai dégagé le routeur, j'ai mis un FVS114 que j'avais sous le coude à la place, et j'ai tourné avec près d'un mois.
Seullement, entre-temps, j'ai changé le lecteur CD, et tout était reparti comme sur des roulettes, début septembre, très très insatisfais du FVS114, je décide de remettre mon routeur linux à sa place d'origine et je dégage le FVS114 qui retourne à sa fonction initiale de presse papier :lol:.
 
la semaine dernière, même symptomes que ce que tu as donné au début: linux reboot tout seul sans raisons apparentes (ça c'était au début), après, les choses ont même empiré : crash, pas de reboot
 
donc dans la nuit de vendredi à samedi (ouais j'avais que ça à faire :D), je vire le vieux routeur, je mets un ancien server PIII à la place, gros et bruyant comme pas possible (Rack 19" 5U), mais un vrai bonheur à l'usage en comparaison du PI \o/
donc, depuis samedi ap midi 15H, j'avais remis mon routeur Pentium I mmx en test, tout seul dans son coin, branché à cheval sur 2 switch à part (pas sur mon réseau), j'ai modif un poil le démarrage (wait infini pour charger le cpu à 100% en permanence dès la fin du démarrage)
 
il a tourné jusqu'à ce mercredi après midi 17H avant de planter, quand ce soir je l'ai vu, je l'ai rebooter (il était freezé totalement), il a rebooter à nouveau avant même de finir le démarrage.
 
Donc là, tout comme toi, j'aimerais bien à nouveau faire tourner cette bécanne, j'ai des alim en stock, j'aimerais bien moi aussi faire un HB pour le faire repartir, je suis à peu prêt sûr que l'alim astec d'origine et ses 13 ans d'age n'est plus en assez bonne santé pour faire tourner tout ce bazard.
Le truc, comme tu l'as constaté, c'est le connecteur avec les fils noir vert et violets
le fil vert est indiqué PS_ON dans l'alim (j'ai regardé le PCB), c'est trop spécifique, à priori pas utile pour un HB
le fil violet est un 5VSB, donc il faudra surement amener un 5VSB d'une alim ATX dessus pour celui là
 
le vrai pb, c'est le fil 1 du connecteur P1, le fil orange : à quoi le relier sur une alim ATX ? \o/
 
bref, j'ajoute sur la liste de courses : "dominos" :lol:


 
D'après Wikipedia, ce fil n'est que la masse, comme le fil 2 de P1 d'ailleurs :D
 
J'aurais voulu répondre plus point par point à ton post par ailleurs très interessant, mais je viens de me taper du boulot de 8H00 à 20H00 aujourd'hui, je suis nase :(
 
 EDit: merde c'est P8 et P9 les dénominations Wikipedia :/ (et pas dans cet ordre dan,s le tableau)


Message édité par Mac Gyver 974 le 22-10-2009 à 19:12:47
Reply

Marsh Posté le 22-10-2009 à 20:50:44    

Bon, je viens de faire une alim HB, et, et.... ça marche \o/
 
 
donc, le fil orange de l'AT correspond au fil gris de l'ATX (le power_good) qui passe à 5V quand les tensions sont stables
inutile de dire que certaines mauvaises alim prennent direct le signal power_good sur le rail 5V :D
 
Donc, -5 (blanc)/-12 (bleu)/+5 (rouge)/+12 (jaune) et toutes les masses (noir), facile
 
le power good : orange en AT, gris en ATX (en fait c'est le seul piège)
le PS_ON : vert (sur ton alim et la mienne, c'est le fil vert du petit connecteur spécifique P10), correspond au fil vert de l'ATX
Le +5VSB : fil violet (idem, c'est celui du connecteur P10), correspond au fil violet de l'ATX
 
l'alim est capable de fonctionner parfaitement sans interrupteur (pas comme avec les alim AT standard) si tu relie le fil vert de l'alim ATX sur le connecteur spécifique de la mobo
 
Bref, maintenant il reste à tester si c'est bien stable :lol:


Message édité par T3K le 22-10-2009 à 20:53:25
Reply

Marsh Posté le 24-10-2009 à 09:47:11    

Impeccable, je vais pouvoir faire la même chose et mettre ça de façon HB dans mon serveur HB :D

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed