[RESOLU, je pense] Problème IDE / HD : messages d'erreurs kernel
2 réponses
Minux
Bonjour,
je me permets de poster sur cette liste, une fois n'est pas coutume,
pour vous soumettre un problème lié à un disque dur (enfin, rien n'est
moins sûr) sous mon petit serveur (Athlon 700Mhz et Asus K7V). J'ai
googlehisé mais il n'y a pas grand'chose que je puisse exploiter... A
part peut-être ceci
http://lists.debian.org/debian-user-french/2002/06/msg00959.html
(message du 16 juin 2002 de François Boisson). J'aimerais bien connaître
la suite et les circonstances, pour comparer si possible.
Voilà l'histoire :
Depuis une semaine en gros j'ai ce genre d'erreurs qui s'affichent :
Jun 11 23:41:58 gryffondor kernel: hdc: dma_timer_expiry: dma status == 0x61
Jun 11 23:42:08 gryffondor kernel: hdc: DMA timeout error
Jun 11 23:42:08 gryffondor kernel: hdc: dma timeout error: status=0xd0 {
Busy }
Jun 11 23:42:08 gryffondor kernel:
Jun 11 23:42:08 gryffondor kernel: hdc: DMA disabled
Jun 11 23:42:08 gryffondor kernel: hdd: DMA disabled
Jun 11 23:42:23 gryffondor kernel: ide1: reset: success
Jun 12 01:03:59 gryffondor kernel: hdc: dma_timer_expiry: dma status == 0x21
sector 57221735
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 57221743
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 57221751
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 57221759
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 57221767
(...)
Jun 13 00:18:38 gryffondor kernel: Buffer I/O error on device hdc6,
logical block 5619
Jun 13 00:18:38 gryffondor kernel: lost page write due to I/O error on hdc6
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 559103
Jun 13 00:18:38 gryffondor kernel: Buffer I/O error on device hdc6,
logical block 5620
Jun 13 00:18:38 gryffondor kernel: lost page write due to I/O error on hdc6
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 52050423
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 52050431
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 559111
Jun 13 00:18:38 gryffondor kernel: Buffer I/O error on device hdc6,
logical block 5621
Jun 13 00:18:38 gryffondor kernel: lost page write due to I/O error on hdc6
Jun 13 00:18:38 gryffondor kernel: REISERFS: abort (device hdc6):
Journal write error in flush_commit_list
Jun 13 00:18:38 gryffondor kernel: REISERFS: Aborting journal for
filesystem on hdc6
(...)
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 52050447
J'ai testé ce disque sur un autre PC (Carte mère Chaintech et PIII
800Mhz) avec drive fitness d'Hitachi (oui, au fait, ce HD est un Hitachi
desktar 60GXP installé en tant que hdc, accompagné d'un disque esclave
Seagate de 120Go, hdd). Et tout va très bien. Aucune erreur de détectée.
D'autre part, au boot, il n'est parfois pas détecté dans le BIOS ou
alors j'ai le message suivant : secondary master drive fails.
Une fois arrêté et redémarré, ça repart parfois.
Par défaut, le mode I/O 32 bits est activé ainsi que le mode UDMA 4 (66Mhz).
J'ai changé la nappe IDE, l'ai enlevé du rack où il était pour le
brancher directement sur cette nappe, et tout seul, sans l'esclave.
Toujours pareil. Je l'ai même reformaté en ext3 (suite à une mauvaise
manip' de ma part croyant une erreur de système de fichier) après avoir
été en reiserfs. Idem. Badblocks génère une série d'erreurs en I/O ainsi
que la commande mkfs.ext3 -c (ou -c -c) /dev/hdc.
Serait-il possible que le contrôleur IDE soit "cassé" selon mon
diagnostique ? Comment cela serait possible ? D'autre part, le disque
hdd en esclave perd lui aussi la configuration DMA mais sans tous ses
messages d'erreur. En fait seul hdc pose (gros) problème.
Merci de m'éclairer de vos connaissances / expériences.
Cordialement à tous.
Complément :
en fait, et a priori, ça vient du disque dur malgré tout. J'ai testé
avec un autre et j'ai laissé tourné toute la nuit : rien. Pas le moindre
signe de faiblesse ! Houra ! Alors que l'ancien, au bout d'une heure ou
2 de fonctionnement, m'injuriait copieusement tel que mentionné ci-dessus.
Moralité : ne pas toujours faire confiance aux outils des fabricants de
D.D. (en l'occurence IBM - Hitachi) qui m'a indiqué que tout était en
parfait état de fonctionnement sur ce disque. Seul un smartctl -a m'a
indiqué des erreurs alors que smartctl -t short et long ont tous 2
indiqués un statut "PASSED". J'ai pourtant regardé la doc et aucune
valeur n'était alarmante (pre-failed par exemple). Curieux.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Frédéric BOITEUX
Le jeu 22 jun 2006 12:53:46 CEST, Minux a écrit :
... Moralité : ne pas toujours faire confiance aux outils des fabricants de D.D. (en l'occurence IBM - Hitachi) qui m'a indiqué que tout était en parfait état de fonctionnement sur ce disque. Seul un smartctl -a m'a
Note 1 : ce n'est pas parce-que Smart ne détecte rien que tout va bien ! En revanche, s'il trouve des soucis, il faut s'en inquiéter...
indiqué des erreurs alors que smartctl -t short et long ont tous 2 indiqués un statut "PASSED". J'ai pourtant regardé la doc et aucune valeur n'était alarmante (pre-failed par exemple). Curieux.
Note 2 : le statut "PASSED" se réfère aux résultats des tests 'offline' ; pour les tests short /long, il faut regarder le résultat par un : smartctl -l selftest <disque>
Fred.
Le jeu 22 jun 2006 12:53:46 CEST, Minux <minux@tele2.fr> a écrit :
...
Moralité : ne pas toujours faire confiance aux outils des fabricants de
D.D. (en l'occurence IBM - Hitachi) qui m'a indiqué que tout était en
parfait état de fonctionnement sur ce disque. Seul un smartctl -a m'a
Note 1 : ce n'est pas parce-que Smart ne détecte rien que tout va
bien ! En revanche, s'il trouve des soucis, il faut s'en inquiéter...
indiqué des erreurs alors que smartctl -t short et long ont tous 2
indiqués un statut "PASSED". J'ai pourtant regardé la doc et aucune
valeur n'était alarmante (pre-failed par exemple). Curieux.
Note 2 : le statut "PASSED" se réfère aux résultats des tests
'offline' ; pour les tests short /long, il faut regarder le résultat
par un : smartctl -l selftest <disque>
... Moralité : ne pas toujours faire confiance aux outils des fabricants de D.D. (en l'occurence IBM - Hitachi) qui m'a indiqué que tout était en parfait état de fonctionnement sur ce disque. Seul un smartctl -a m'a
Note 1 : ce n'est pas parce-que Smart ne détecte rien que tout va bien ! En revanche, s'il trouve des soucis, il faut s'en inquiéter...
indiqué des erreurs alors que smartctl -t short et long ont tous 2 indiqués un statut "PASSED". J'ai pourtant regardé la doc et aucune valeur n'était alarmante (pre-failed par exemple). Curieux.
Note 2 : le statut "PASSED" se réfère aux résultats des tests 'offline' ; pour les tests short /long, il faut regarder le résultat par un : smartctl -l selftest <disque>
Fred.
Hugues LARRIVE
Bonjour,
J'ai eu ce genre de problème une fois avec 2 disques identiques en raid logiciel sur une carte mère neuve... un troisième disque différent ne pausait pas de problème, j'ai essayé un peu toutes les combinaisons possibles disques, nappes, contrôleur... chaque fois que je testait un des disques ça fonctionnait normalement mais quand le système fonctionnait j'avais les mêmes messages d'erreur, de plus en plus rapidement.
En fin de comte ce n'était ni un problème de disque, ni de logiciel, ni de contrôleur... seulement l'alimentation était fatiguée et le fonctionnement simultané des 2 disques en miroir provoquait des chutes de tension qui entraînaient l'arrêt d'un des disque ! donc changement d'alimentation -> plus de problème ! Il m'a fallut 2 semaines pour trouver d'où venait la panne, j'ai même échangé la carte mère neuve pensant qu'elle avait un défaut...
Je m'était bien posé la question de la puissance quand j'avais upgradé la machine ( celeron 600 -> sempron 2500 ) mais le vendeur m'avait assuré que si elle n'était pas suffisamment puissante, le PC ne s'allumerait pas... ben elle était suffisamment puissant pour qu'il s'allume mais pas lorsqu'il fonctionnait à plein régime.
Donc fais un essai avec une autre alime si tu peux.
@+
Minux a écrit :
Bonjour,
je me permets de poster sur cette liste, une fois n'est pas coutume, pour vous soumettre un problème lié à un disque dur (enfin, rien n'est moins sûr) sous mon petit serveur (Athlon 700Mhz et Asus K7V). J'ai googlehisé mais il n'y a pas grand'chose que je puisse exploiter... A part peut-être ceci http://lists.debian.org/debian-user-french/2002/06/msg00959.html (message du 16 juin 2002 de François Boisson). J'aimerais bien connaître la suite et les circonstances, pour comparer si possible.
Voilà l'histoire : Depuis une semaine en gros j'ai ce genre d'erreurs qui s'affichent :
Jun 11 23:41:58 gryffondor kernel: hdc: dma_timer_expiry: dma status == 0x61 Jun 11 23:42:08 gryffondor kernel: hdc: DMA timeout error Jun 11 23:42:08 gryffondor kernel: hdc: dma timeout error: status=0xd0 { Busy } Jun 11 23:42:08 gryffondor kernel: Jun 11 23:42:08 gryffondor kernel: hdc: DMA disabled Jun 11 23:42:08 gryffondor kernel: hdd: DMA disabled Jun 11 23:42:23 gryffondor kernel: ide1: reset: success Jun 12 01:03:59 gryffondor kernel: hdc: dma_timer_expiry: dma status == 0x21
sector 57221735 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 57221743 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 57221751 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 57221759 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 57221767
(...)
Jun 13 00:18:38 gryffondor kernel: Buffer I/O error on device hdc6, logical block 5619 Jun 13 00:18:38 gryffondor kernel: lost page write due to I/O error on hdc6 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 559103 Jun 13 00:18:38 gryffondor kernel: Buffer I/O error on device hdc6, logical block 5620 Jun 13 00:18:38 gryffondor kernel: lost page write due to I/O error on hdc6 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 52050423 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 52050431 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 559111 Jun 13 00:18:38 gryffondor kernel: Buffer I/O error on device hdc6, logical block 5621 Jun 13 00:18:38 gryffondor kernel: lost page write due to I/O error on hdc6 Jun 13 00:18:38 gryffondor kernel: REISERFS: abort (device hdc6): Journal write error in flush_commit_list Jun 13 00:18:38 gryffondor kernel: REISERFS: Aborting journal for filesystem on hdc6 (...) Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 52050447
J'ai testé ce disque sur un autre PC (Carte mère Chaintech et PIII 800Mhz) avec drive fitness d'Hitachi (oui, au fait, ce HD est un Hitachi desktar 60GXP installé en tant que hdc, accompagné d'un disque esclave Seagate de 120Go, hdd). Et tout va très bien. Aucune erreur de détectée. D'autre part, au boot, il n'est parfois pas détecté dans le BIOS ou alors j'ai le message suivant : secondary master drive fails. Une fois arrêté et redémarré, ça repart parfois. Par défaut, le mode I/O 32 bits est activé ainsi que le mode UDMA 4 (66Mhz). J'ai changé la nappe IDE, l'ai enlevé du rack où il était pour le brancher directement sur cette nappe, et tout seul, sans l'esclave. Toujours pareil. Je l'ai même reformaté en ext3 (suite à une mauvaise manip' de ma part croyant une erreur de système de fichier) après avoir été en reiserfs. Idem. Badblocks génère une série d'erreurs en I/O ainsi que la commande mkfs.ext3 -c (ou -c -c) /dev/hdc.
Serait-il possible que le contrôleur IDE soit "cassé" selon mon diagnostique ? Comment cela serait possible ? D'autre part, le disque hdd en esclave perd lui aussi la configuration DMA mais sans tous ses messages d'erreur. En fait seul hdc pose (gros) problème. Merci de m'éclairer de vos connaissances / expériences. Cordialement à tous.
Complément : en fait, et a priori, ça vient du disque dur malgré tout. J'ai testé avec un autre et j'ai laissé tourné toute la nuit : rien. Pas le moindre signe de faiblesse ! Houra ! Alors que l'ancien, au bout d'une heure ou 2 de fonctionnement, m'injuriait copieusement tel que mentionné ci-dessus. Moralité : ne pas toujours faire confiance aux outils des fabricants de D.D. (en l'occurence IBM - Hitachi) qui m'a indiqué que tout était en parfait état de fonctionnement sur ce disque. Seul un smartctl -a m'a indiqué des erreurs alors que smartctl -t short et long ont tous 2 indiqués un statut "PASSED". J'ai pourtant regardé la doc et aucune valeur n'était alarmante (pre-failed par exemple). Curieux.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Bonjour,
J'ai eu ce genre de problème une fois avec 2 disques identiques en raid
logiciel sur une carte mère neuve... un troisième disque différent ne
pausait pas de problème, j'ai essayé un peu toutes les combinaisons
possibles disques, nappes, contrôleur... chaque fois que je testait un
des disques ça fonctionnait normalement mais quand le système
fonctionnait j'avais les mêmes messages d'erreur, de plus en plus
rapidement.
En fin de comte ce n'était ni un problème de disque, ni de logiciel, ni
de contrôleur... seulement l'alimentation était fatiguée et le
fonctionnement simultané des 2 disques en miroir provoquait des chutes
de tension qui entraînaient l'arrêt d'un des disque ! donc changement
d'alimentation -> plus de problème ! Il m'a fallut 2 semaines pour
trouver d'où venait la panne, j'ai même échangé la carte mère neuve
pensant qu'elle avait un défaut...
Je m'était bien posé la question de la puissance quand j'avais upgradé
la machine ( celeron 600 -> sempron 2500 ) mais le vendeur m'avait
assuré que si elle n'était pas suffisamment puissante, le PC ne
s'allumerait pas... ben elle était suffisamment puissant pour qu'il
s'allume mais pas lorsqu'il fonctionnait à plein régime.
Donc fais un essai avec une autre alime si tu peux.
@+
Minux a écrit :
Bonjour,
je me permets de poster sur cette liste, une fois n'est pas coutume,
pour vous soumettre un problème lié à un disque dur (enfin, rien n'est
moins sûr) sous mon petit serveur (Athlon 700Mhz et Asus K7V). J'ai
googlehisé mais il n'y a pas grand'chose que je puisse exploiter... A
part peut-être ceci
http://lists.debian.org/debian-user-french/2002/06/msg00959.html
(message du 16 juin 2002 de François Boisson). J'aimerais bien connaître
la suite et les circonstances, pour comparer si possible.
Voilà l'histoire :
Depuis une semaine en gros j'ai ce genre d'erreurs qui s'affichent :
Jun 11 23:41:58 gryffondor kernel: hdc: dma_timer_expiry: dma status
== 0x61
Jun 11 23:42:08 gryffondor kernel: hdc: DMA timeout error
Jun 11 23:42:08 gryffondor kernel: hdc: dma timeout error: status=0xd0 {
Busy }
Jun 11 23:42:08 gryffondor kernel:
Jun 11 23:42:08 gryffondor kernel: hdc: DMA disabled
Jun 11 23:42:08 gryffondor kernel: hdd: DMA disabled
Jun 11 23:42:23 gryffondor kernel: ide1: reset: success
Jun 12 01:03:59 gryffondor kernel: hdc: dma_timer_expiry: dma status
== 0x21
sector 57221735
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 57221743
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 57221751
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 57221759
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 57221767
(...)
Jun 13 00:18:38 gryffondor kernel: Buffer I/O error on device hdc6,
logical block 5619
Jun 13 00:18:38 gryffondor kernel: lost page write due to I/O error on
hdc6
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 559103
Jun 13 00:18:38 gryffondor kernel: Buffer I/O error on device hdc6,
logical block 5620
Jun 13 00:18:38 gryffondor kernel: lost page write due to I/O error on
hdc6
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 52050423
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 52050431
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 559111
Jun 13 00:18:38 gryffondor kernel: Buffer I/O error on device hdc6,
logical block 5621
Jun 13 00:18:38 gryffondor kernel: lost page write due to I/O error on
hdc6
Jun 13 00:18:38 gryffondor kernel: REISERFS: abort (device hdc6):
Journal write error in flush_commit_list
Jun 13 00:18:38 gryffondor kernel: REISERFS: Aborting journal for
filesystem on hdc6
(...)
Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc,
sector 52050447
J'ai testé ce disque sur un autre PC (Carte mère Chaintech et PIII
800Mhz) avec drive fitness d'Hitachi (oui, au fait, ce HD est un Hitachi
desktar 60GXP installé en tant que hdc, accompagné d'un disque esclave
Seagate de 120Go, hdd). Et tout va très bien. Aucune erreur de détectée.
D'autre part, au boot, il n'est parfois pas détecté dans le BIOS ou
alors j'ai le message suivant : secondary master drive fails.
Une fois arrêté et redémarré, ça repart parfois.
Par défaut, le mode I/O 32 bits est activé ainsi que le mode UDMA 4
(66Mhz).
J'ai changé la nappe IDE, l'ai enlevé du rack où il était pour le
brancher directement sur cette nappe, et tout seul, sans l'esclave.
Toujours pareil. Je l'ai même reformaté en ext3 (suite à une mauvaise
manip' de ma part croyant une erreur de système de fichier) après avoir
été en reiserfs. Idem. Badblocks génère une série d'erreurs en I/O ainsi
que la commande mkfs.ext3 -c (ou -c -c) /dev/hdc.
Serait-il possible que le contrôleur IDE soit "cassé" selon mon
diagnostique ? Comment cela serait possible ? D'autre part, le disque
hdd en esclave perd lui aussi la configuration DMA mais sans tous ses
messages d'erreur. En fait seul hdc pose (gros) problème.
Merci de m'éclairer de vos connaissances / expériences.
Cordialement à tous.
Complément :
en fait, et a priori, ça vient du disque dur malgré tout. J'ai testé
avec un autre et j'ai laissé tourné toute la nuit : rien. Pas le
moindre signe de faiblesse ! Houra ! Alors que l'ancien, au bout d'une
heure ou 2 de fonctionnement, m'injuriait copieusement tel que
mentionné ci-dessus.
Moralité : ne pas toujours faire confiance aux outils des fabricants
de D.D. (en l'occurence IBM - Hitachi) qui m'a indiqué que tout était
en parfait état de fonctionnement sur ce disque. Seul un smartctl -a
m'a indiqué des erreurs alors que smartctl -t short et long ont tous 2
indiqués un statut "PASSED". J'ai pourtant regardé la doc et aucune
valeur n'était alarmante (pre-failed par exemple). Curieux.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
J'ai eu ce genre de problème une fois avec 2 disques identiques en raid logiciel sur une carte mère neuve... un troisième disque différent ne pausait pas de problème, j'ai essayé un peu toutes les combinaisons possibles disques, nappes, contrôleur... chaque fois que je testait un des disques ça fonctionnait normalement mais quand le système fonctionnait j'avais les mêmes messages d'erreur, de plus en plus rapidement.
En fin de comte ce n'était ni un problème de disque, ni de logiciel, ni de contrôleur... seulement l'alimentation était fatiguée et le fonctionnement simultané des 2 disques en miroir provoquait des chutes de tension qui entraînaient l'arrêt d'un des disque ! donc changement d'alimentation -> plus de problème ! Il m'a fallut 2 semaines pour trouver d'où venait la panne, j'ai même échangé la carte mère neuve pensant qu'elle avait un défaut...
Je m'était bien posé la question de la puissance quand j'avais upgradé la machine ( celeron 600 -> sempron 2500 ) mais le vendeur m'avait assuré que si elle n'était pas suffisamment puissante, le PC ne s'allumerait pas... ben elle était suffisamment puissant pour qu'il s'allume mais pas lorsqu'il fonctionnait à plein régime.
Donc fais un essai avec une autre alime si tu peux.
@+
Minux a écrit :
Bonjour,
je me permets de poster sur cette liste, une fois n'est pas coutume, pour vous soumettre un problème lié à un disque dur (enfin, rien n'est moins sûr) sous mon petit serveur (Athlon 700Mhz et Asus K7V). J'ai googlehisé mais il n'y a pas grand'chose que je puisse exploiter... A part peut-être ceci http://lists.debian.org/debian-user-french/2002/06/msg00959.html (message du 16 juin 2002 de François Boisson). J'aimerais bien connaître la suite et les circonstances, pour comparer si possible.
Voilà l'histoire : Depuis une semaine en gros j'ai ce genre d'erreurs qui s'affichent :
Jun 11 23:41:58 gryffondor kernel: hdc: dma_timer_expiry: dma status == 0x61 Jun 11 23:42:08 gryffondor kernel: hdc: DMA timeout error Jun 11 23:42:08 gryffondor kernel: hdc: dma timeout error: status=0xd0 { Busy } Jun 11 23:42:08 gryffondor kernel: Jun 11 23:42:08 gryffondor kernel: hdc: DMA disabled Jun 11 23:42:08 gryffondor kernel: hdd: DMA disabled Jun 11 23:42:23 gryffondor kernel: ide1: reset: success Jun 12 01:03:59 gryffondor kernel: hdc: dma_timer_expiry: dma status == 0x21
sector 57221735 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 57221743 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 57221751 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 57221759 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 57221767
(...)
Jun 13 00:18:38 gryffondor kernel: Buffer I/O error on device hdc6, logical block 5619 Jun 13 00:18:38 gryffondor kernel: lost page write due to I/O error on hdc6 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 559103 Jun 13 00:18:38 gryffondor kernel: Buffer I/O error on device hdc6, logical block 5620 Jun 13 00:18:38 gryffondor kernel: lost page write due to I/O error on hdc6 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 52050423 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 52050431 Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 559111 Jun 13 00:18:38 gryffondor kernel: Buffer I/O error on device hdc6, logical block 5621 Jun 13 00:18:38 gryffondor kernel: lost page write due to I/O error on hdc6 Jun 13 00:18:38 gryffondor kernel: REISERFS: abort (device hdc6): Journal write error in flush_commit_list Jun 13 00:18:38 gryffondor kernel: REISERFS: Aborting journal for filesystem on hdc6 (...) Jun 13 00:18:38 gryffondor kernel: end_request: I/O error, dev hdc, sector 52050447
J'ai testé ce disque sur un autre PC (Carte mère Chaintech et PIII 800Mhz) avec drive fitness d'Hitachi (oui, au fait, ce HD est un Hitachi desktar 60GXP installé en tant que hdc, accompagné d'un disque esclave Seagate de 120Go, hdd). Et tout va très bien. Aucune erreur de détectée. D'autre part, au boot, il n'est parfois pas détecté dans le BIOS ou alors j'ai le message suivant : secondary master drive fails. Une fois arrêté et redémarré, ça repart parfois. Par défaut, le mode I/O 32 bits est activé ainsi que le mode UDMA 4 (66Mhz). J'ai changé la nappe IDE, l'ai enlevé du rack où il était pour le brancher directement sur cette nappe, et tout seul, sans l'esclave. Toujours pareil. Je l'ai même reformaté en ext3 (suite à une mauvaise manip' de ma part croyant une erreur de système de fichier) après avoir été en reiserfs. Idem. Badblocks génère une série d'erreurs en I/O ainsi que la commande mkfs.ext3 -c (ou -c -c) /dev/hdc.
Serait-il possible que le contrôleur IDE soit "cassé" selon mon diagnostique ? Comment cela serait possible ? D'autre part, le disque hdd en esclave perd lui aussi la configuration DMA mais sans tous ses messages d'erreur. En fait seul hdc pose (gros) problème. Merci de m'éclairer de vos connaissances / expériences. Cordialement à tous.
Complément : en fait, et a priori, ça vient du disque dur malgré tout. J'ai testé avec un autre et j'ai laissé tourné toute la nuit : rien. Pas le moindre signe de faiblesse ! Houra ! Alors que l'ancien, au bout d'une heure ou 2 de fonctionnement, m'injuriait copieusement tel que mentionné ci-dessus. Moralité : ne pas toujours faire confiance aux outils des fabricants de D.D. (en l'occurence IBM - Hitachi) qui m'a indiqué que tout était en parfait état de fonctionnement sur ce disque. Seul un smartctl -a m'a indiqué des erreurs alors que smartctl -t short et long ont tous 2 indiqués un statut "PASSED". J'ai pourtant regardé la doc et aucune valeur n'était alarmante (pre-failed par exemple). Curieux.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
