Bonjour,
J'ai, deux nuit de suite eut des coupures de courant et depuis mon vdr se crash et je vois des messages d'erreur inquétants que ma connaissance limitée de linux me permet pas de juger ou résoudre.
Est-ce que quelqu'un pourrait me donner son avis sur les erreurs ci-dessous (hda :dma ...., getpeername....)
merci,
splinux
ar 29 10:00:16 pc-cave vdr: [5128] starting plugin: rotor
Mar 29 10:00:16 pc-cave vdr: [5128] loading /VDRConf/plugins/rotor.conf
Mar 29 10:00:16 pc-cave vdr: [5128] starting plugin: channelscan
Mar 29 10:00:16 pc-cave vdr: [5128] loading /VDRConf/themes/sttng-default.theme
Mar 29 10:00:16 pc-cave lircd-0.7.2[2035]: accepted new client on /dev/lircd
Mar 29 10:00:16 pc-cave vdr: [5128] switching to channel 180
Mar 29 10:00:17 pc-cave vdr: [5139] frontend 0 lost lock on channel 180, tp 212207
Mar 29 10:00:19 pc-cave vdr: [5139] frontend 0 timed out while tuning to channel 180, tp 212207
Mar 29 10:00:19 pc-cave vdr: [5139] frontend 0 regained lock on channel 180, tp 212207
Mar 29 10:08:51 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:08:51 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:08:51 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:10:17 pc-cave smbd[2271]: [2006/03/29 10:10:17, 0] lib/util_sock.c:get_peer_addr(1225)
Mar 29 10:10:17 pc-cave smbd[2271]: getpeername failed. Error was Noeud final de transport n'est pas connecté
Mar 29 10:10:17 pc-cave smbd[5210]: [2006/03/29 10:10:17, 0] lib/util_sock.c:get_peer_addr(1225)
Mar 29 10:10:17 pc-cave smbd[5210]: getpeername failed. Error was Noeud final de transport n'est pas connecté
Mar 29 10:10:17 pc-cave smbd[5210]: [2006/03/29 10:10:17, 0] lib/util_sock.c:write_data(557)
Mar 29 10:10:17 pc-cave smbd[5210]: write_data: write failure in writing to client 0.0.0.0. Error Connexion ré-initialisée par le correspondant
Mar 29 10:10:17 pc-cave smbd[5210]: [2006/03/29 10:10:17, 0] lib/util_sock.c:send_smb(765)
Mar 29 10:10:17 pc-cave smbd[5210]: Error writing 4 bytes to client. -1. (Connexion ré-initialisée par le correspondant)
Mar 29 10:15:51 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:15:51 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:15:51 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:17:48 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:17:48 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:17:48 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:23:18 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:23:18 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:23:18 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:27:11 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:27:11 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:27:11 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:29:06 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:29:06 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:29:06 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:29:11 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:29:11 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:29:11 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:29:11 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:29:11 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:29:11 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:29:16 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:29:16 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:29:16 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:29:16 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:29:16 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:29:16 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:29:22 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:29:22 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:29:22 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:29:42 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:29:42 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:29:42 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:29:48 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:29:48 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:29:48 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:30:46 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:30:46 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:30:46 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:30:56 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:30:56 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:30:56 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:31:44 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:31:44 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:31:44 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:31:44 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:31:44 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:31:44 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:31:44 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:31:44 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:31:44 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:31:44 pc-cave kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Mar 29 10:31:44 pc-cave kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Mar 29 10:31:44 pc-cave kernel: ide: failed opcode was: unknown
Mar 29 10:31:44 pc-cave kernel: hdb: DMA disabled
Mar 29 10:31:44 pc-cave kernel: ide0: reset: success
Mar 29 10:42:17 pc-cave smbd[2271]: [2006/03/29 10:42:17, 0] lib/util_sock.c:get_peer_addr(1225)
Mar 29 10:42:17 pc-cave smbd[2271]: getpeername failed. Error was Noeud final de transport n'est pas connecté
Mar 29 10:42:17 pc-cave smbd[5430]: [2006/03/29 10:42:17, 0] lib/util_sock.c:get_peer_addr(1225)
Mar 29 10:42:17 pc-cave smbd[5430]: getpeername failed. Error was Noeud final de transport n'est pas connecté
Mar 29 10:42:17 pc-cave smbd[5430]: [2006/03/29 10:42:17, 0] lib/util_sock.c:write_data(557)
Mar 29 10:42:17 pc-cave smbd[5430]: write_data: write failure in writing to client 0.0.0.0. Error Connexion ré-initialisée par le correspondant
Mar 29 10:42:17 pc-cave smbd[5430]: [2006/03/29 10:42:17, 0] lib/util_sock.c:send_smb(765)
Mar 29 10:42:17 pc-cave smbd[5430]: Error writing 4 bytes to client. -1. (Connexion ré-initialisée par le correspondant)
Mar 29 11:00:14 pc-cave vdr: [5128] cleaning up schedules data
Mar 29 11:41:41 pc-cave su(pam_unix)[5848]: session opened for user root by (uid=500)
Mar 29 12:00:15 pc-cave vdr: [5128] cleaning up schedules data
Mar 29 12:00:47 pc-cave su(pam_unix)[3271]: session closed for user root
Mar 29 12:00:54 pc-cave su(pam_unix)[5997]: session opened for user root by (uid=500)
Mar 29 12:01:13 pc-cave su(pam_unix)[6030]: session opened for user sp by (uid=0)
Mar 29 12:01:14 pc-cave vdr: [6031] VDR version 1.3.45 started
Mar 29
# Peut-être un espoir
Posté par Obsidian . Évalué à 4.
Ces messages indiquent des secteurs défectueux au bas niveau sur le disque, si bien que même le contrôleur DMA, l'électronique du disque qui se charge d'aller chercher les secteurs tout seul, comme un grand et sans directive de la part du CPU, ne peut plus les lire. Cela est dû au fait que les informations inter-secteurs qui permettent au contrôleur disque de savoir où il se trouve sur une piste sont devenues incorrectes.
Évidement, on comprend que le meilleur cas de figure pour que cela arrive, c'est une coupure de courant au moment où l'électronique du disque est en train de les mettre à jour.
Vu de l'extérieur, l'IDE ou le SCSI faisant abstraction de ces informations et ne présentant que les secteurs eux-mêmes, les formattages traditionnels s'y cassent les dents puisque ceux-ci ne s'occupent que de remplir les secteurs et pas de les construire. La plupart des gens pensent donc que le disque est physiquement endommagé alors qu'un formattage de bas niveau suffit à leur redonner leur jeunesse d'antan.
Malheureusement, depuis que les disquettes sont tombées en désuétude, beaucoup de gens confondent formattages de bas niveau et de haut niveau avec formattage de haut niveau (remplir les secteurs existants avec des zéros) et reconstruction du système de fichiers (qui suffit à présenter un disque comme vide même s'il reste des infos dans les secteurs).
Donc, pour réparer ton disque, il faut trouver l'utilitaire de formattage de bas niveau de ton disque, qui est propre à chaque constructeur (c'est à ça que sert une couche d'abstraction), et si possible isoler et ne formatter que les pistes défectueuses.
Sinon, il faut trouver de la place quelque part, backuper le contenu du disque avec dd en ignorant les erreurs (enfin il faut vérifier que dd remplace les secteurs défectueux par des 00 00), puis procéder là aussi à un formattage de bas-niveau sur la totalité du disque, puis reconstruire.
Bref, c'est pas forcément TRÈS compliqué en soi, mais c'est assez contraignant et il faut avoir un peu de connaissances. Mais au moins, tu devrais pouvoir conserver ton hardware.
[^] # Re: Peut-être un espoir
Posté par serge pecher . Évalué à 2.
N'y-a-t-il pas moyen de "sacrifier" les pistes défectueuses et de conserver le reste sans devoir reformater le disque. C'est un disque de 160 GB, si j'en perd qq un ces pas un cata.
est-ce qu'un outil du style de fsck peut m'aider ?
tu parle de dd -> c'est quoi ?
J'ai un deuxieme disque identique dans cette machine que est utiliser pour des copies de sauvegarde de certains fichiers.
Y-a-t-il moyen de faire un transfert de l'ensemble, y compris du système ?
merci
sp
[^] # Re: Peut-être un espoir
Posté par Bastien Mourgues . Évalué à 1.
fsck -c -c device
extrait du manuel de fsck.ext3 :
Par contre, ça peut prendre du temps, et je ne sais pas si le résultat est garanti .... ^_^;
[^] # Re: Peut-être un espoir
Posté par serge pecher . Évalué à 1.
J'utilise fedora 4, qui visiblement travail avec un système de volume logique.
La commande "mount" m'indique /dev/hda1 monté en /boot, puis d'autres devices spéciaux (???) puis un /dev/mapper.
Visiblement mes disques se trouvent sous ce dernier device.
Par contre j'ai lu qu'on ne pouvait absolument pas faire un fsck sur un "raw device" (qu'est ce que cela veut dire ?). Je ne sais donc pas exactement à quoi je peux appliquer le fsck.
Dans KDE avec l'application volume manager je vois chose du style de VOL00 ou VOL01 et deux disques hda2 et hdb.
Depuis hier ma machine continue à tourner, et je n'ai plus de message d'erreur.
merci,
sp
[^] # Re: Peut-être un espoir
Posté par serge pecher . Évalué à 1.
Sur hda il y a hda1 avec /boot et hda2 avec /
hdb est une partition.
J'ai un systeme LVM2 qui comprend hda2 et hdb.
Dans le volume groupe il y a deux volumes logiques l'un étant constitué par hda2 et l'autre par hdb. J'ai monté le deuxième volume logique dans un directory appelé /data
Depuis les messages d'erreur du milieu de semaine, j'ai d'abord copié par erreur mes data (+/- 80 gb) dans un autre directory de hda2 (mon disque hda était presque plein) et maintenant dans data. Je n'ai eu aucune erreur. La machine semble très bien fonctionner.
Y-a-t-il des routines de "autocorrection" en linux ?
J'aimerai malgrès tout faire un fsck, mais j'ai lu des commentaires qu'il fallait être prudent avec le LVM. Qu'en est-il?
Y-a-t-il des outils spécifique pour contrôler des partitions gérée par LVM2 ?
Vu que la partition principale est comprend root, comment faire pour la controler ?
J'avais lu de passer l'option -y? à LILO, mais j'ai GRUB.
J'ai également lu d'utiliser l'option -F dans shutdown pour forcer un fsck au prochain démarrage ?
Avant de faire des betisses, j'aimerai bien avoir l'avis d'un spécialiste.
Merci,
sp
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.