Matériel Panik
From Bubble
Contents |
Coté émission (Panik)
PC
Un RC:CitizenBac est utilisé:
- Pentium 150 Mhz
- 64 MB RAM (vérifiée avec MemTest86)
- 1.6 GB Hard Disk (vérifié avec badblocks)
- Carte réseau SMC Ultra
- Bridge PCMCIA ISA
Wifi
- Carte: PCMCIA Cisco 350 ou RC:EnGenius
- Antenne: RC:RubberDuck via un pigtail RP-TNC
Coté réception (Josaphat)
PC
Un PC tour:
- Pentium 200 Mhz MMX
- 160 MB RAM (vérifiée avec MemTest86)
- 1282 MB Hard Disk (vérifié avec badblocks)
- Carte son: Creative SB16 PnP
Wifi
- Carte: PCMCIA RC:EnGenius
- Antenne: Omni 8 dBi via un pigtail N et un cable Ecoflex N/N
Problèmes résolus
- La carte perd son setup lorsqu'elle est débranchée.
Pile remplacée {OK} - 165 badblocks sur ke disque.
Disque changé {OK}
Problème hardware (pour référence)
Historique du problème hardware sur le RC:CitizenBac.
La machine a été remplacée
J'ai détecté plusieurs comportements bizarres du système:
- Un core dump lors de l'install
- Une erreur de pagination au shutdown
- Une corruption disque
Si le hardware ne peux pas formellement être mis en cause dans les 2 premiers cas, le troisème est formellement identifié:
cmp -bl /lib/modules/2.4.27-rc-1-386/kernel/drivers/ide/ide-core.o kernel/drivers/ide/ide-core.o 105379 0 @ 3 C 106403 1 A 3 C
Cette corruption c'est produite à l'installation d'un nouveau noyeau pendant la création du initrd.
Plusieurs causes sont probables:
- Problème disque
- Problème mémoire / cache (seuls 2 bytes du fichier sont affectés)
- Problème de la carte mère en général (ben il a marche pendant plus d un an --eg)
Aucun message d'erreur dans les logs....
/!\ plan d'action:
- Test intensif de la mémoire (avec MemTest86)
{OK} Quatre passes complètes sans erreur (16 heures de test!) - Test intensif du disque (avec badblocks -- le disque est ATA-1 et n'a pas d'infos SMART)
X-( le disque a l'air d'avoir des problèmes intermitants: badblocks me renvoie une dizaine de blocs, je relance la commande en redirigeant la liste des blocks dans un fichier: plus d'erreur... - Autres tests
{OK} Le processeur reste tiède avec cpuburn -- pas de problème de ce coté
<!> Suite au résultats des tests précédents, je décide d'utiliser un autre disque...
- Test pour badblocks dans une autre machine: pas de problème
- Première partie de l'install de Sarge dans une autre machine: pas de problème
- Install du HD dans la machine cible, continuation de l'install: corruption d'une librairie, impossible de finir l'install X-(
<!> Pour préciser le problème, je reprend au début:
- Install complet de Sarge a partir d'une autre machine: tout bon
- Install du HD dans la machine cible: pas de problème au boot
- Je décide alors de charger la machine en copiant le répertoire /usr et en vérifiant la consistance des données.
La procédure tourne toute la nuit sans corruptions... - Comme la plupart des problèmes on été rencontrés lors/suite à l'install de paquets Debian, je change mon script de test et fais la copie via
`tar -czf - | tar -xzf -`
et oh surprise après quelques minutes la machine se meurt avec des
`kernel: Unable to handle kernel paging request at virtual address ...`
De plus le problème est maintenant reproductible!
Ce type de problème est généralement logiciel, mais il se produit ici avec avec une installation Sarge de base, ce qui est vraiment bizarre...
L'analyse du stack trace des Oopses ne révèle pas grand chose:
- Aucun module exotique dans le stack
- Se produit a des endroits différents
- Est lié à la gestion disque/mémoire (allocation d'inode, swap, ...)
A ce stade il est difficile d'apporter un conclusion formelle sur l'origine du problème. Bien qu'on puisse pousser les tests plus loin (étude du comportement sous Debian Woody par exemple), nous sommes de toutes façons en présence d'un système instable.
Je pense qu'il vaut mieux éviter d'installer un noeud sur des bases malsaines et suggère l'utilisation d'une autre machine.
