Non, c'est une caractéristique voulue ;-)
Plus sérieusement, un logiciel fiable ne doit pas se planter. C'est particulièrement vrai pour le noyau qui ne peut pas ou plutôt ne devrait pas planter. Si le noyau se plante lorsque vous utilisez ftape, et que vous pouvez montrer que c'est le pilote ftape qui en est responsable, alors considérez cela comme une erreur importante qui Doit Etre Corrigée. Ecrivez les détails de votre situation aux responsables du développement (voir section email-addrs ci-dessous).
[Note : cette méthode ne marche plus; l'auteur ne sait pas pour l'instant remédier à cette situation]
Pour arrêter cela, faîtes (de mémoire) : loggez vous en tant que root
et faites `rmmod ftape
'. ftape doit faire quelques `ratés',
donner a peu près trois `segmentations fault', et expirer
définitivement.
Observez le témoin (LED) de votre lecteur de disquettes (vous en avez bien un, n'est ce pas?). Si il reste allumé de manière permanente, vous avez mis dans le mauvais sens le câble du lecteur de disquettes. Vérifiez le câble entre le contrôleur, le lecteur de bande et le lecteur de disquettes. En général, l'un (ou plusieurs) d'un des connecteurs a été mis dans le mauvais sens (dessus dessous), de sorte que l'emplacement 1 (broche 1) d'une extrémité se connecte à l'emplacement 34 (broche 34) de l'autre côté de la connexion. (Tous les emplacements pairs sont mis à la terre, donc votre lecteur de disquettes devrait aussi être inutilisable). Ne vous inquiétez pas; cela ne peut pas abîmer votre matériel.
Premièrement, assurez-vous que le problème est reproductible. Les erreurs aléatoires sont très embêtantes, du fait qu'elles sont impossibles à isoler :-/ Voilà une liste rapide à vérifier/reporter :
ftape.o
. Nous
voudrons peut-être essayer quelques modifications ou exécuter des
tests différents sur votre système.Augmenter le niveau de traçage jusqu'à 7 (juste en-dessous du niveau
maximum) et exécuter la commande fautive de nouveau. Récupérer les
données de traçage à partir du `journal' du noyau ou de
/proc/kmsg
, cela dépendant d'où vous abritez vos messages
d'erreur. N'essayez pas de `filtrer' les traces obtenues. Vous
pourriez considérer certaines choses superflues alors qu'elles sont
essentielles pour retrouver le bogue. Décrivez exactement ce que vous
avez fait, et ce qui s'est passé sur votre système. En effet, il est
possible que nous ne puissions pas reproduire l'erreur parce que nous
utilisons un lecteur différent ou une autre version du noyau.
Il y a deux manières de le faire : soit vous pouvez changer le niveau
de traçage par défaut (la variable `tracing
' dans le fichier
`ftape-rw.c
') et recompiler, soit tapez
mt /dev/ftape fsr <tracing-level>
L'utilisation de la commande `fsr' avec mt est une sorte de bidouille, et est destinée à disparaître.
/dev/nftape
, il y a beaucoup
de message superflus ... pourquoi ?Cela vient d'un problème `historique', avant la version 0.9.10. De nos jours, les périphériques `non-rembobinants' fonctionnent correctement. Si votre version est ancienne, il est vivement recommandé de se mettre à jour avec la version 1.13b.