# [résolu] [rtorrent] Bus error

## Legoboy

Bonjour,

J'ai quelques soucis avec rtorrent.

Et le comble c'est que je m'en suis appercu quand, dans un moment de désespoir, j'avais lancé le téléchargement du LiveDVD de Fedora.

Au bout de quelques minutes, il m'affiche un message « Bus error » et c'est le Kernel Panic.

D'où est-ce que cela peut venir ??

Merci d'avance !Last edited by Legoboy on Sun Oct 04, 2009 9:55 pm; edited 1 time in total

----------

## truc

 *Legoboy wrote:*   

> D'où est-ce que cela peut venir ??

 

Hum... Je dirais d'autre chose... Pas de rtorrent en tout cas.

T'as vérifier les logs usuels pour des informations croustillantes?

----------

## Legoboy

Bah justement je ne trouve aucun log avec la moindre information.

Je pourrais peut être avoir une petite information ?

La seule chose que je sais c'est que cela ne se produit que lorsque l'ordinateur est connecté au réseau.

Edit: Maintenant j'ai des problèmes avec des « cp » de grande taille.

----------

## Legoboy

En fait le problème est systèmatique lorsqu'il y a des écritures importantes sur le disque.

Il doit me manquer une option lors de la compilation du noyau.

Après j'ai des messages « input / output error » plus ou moins systématique.

----------

## El_Goretto

Ou alors tu as un problème matériel...

Serre les fesses et backup, fils  :Smile: 

----------

## guilc

Comme je viens d'en parler là : https://forums.gentoo.org/viewtopic-t-793909.html

smartmontools est ton ami pour diagnostiquer des problèmes de santé de ton disque  :Wink: 

Pourquoi pas envisager aussi un souci de RAM ? (memtest dans ce cas)

----------

## Legoboy

Mon PC revient tout juste du SAV (problème sur la carte mère), j'ai pas spécialement envie d'avoir encore des problèmes hardware.

Je ne pense pas que la RAM pose problème : les problème n'arrivent qu'en cas d'écriture intensive sur le disque dur (compiler, jouer et utiliser de la RAM comme un porc ne pose aucun problème, je vais quand même faire tourner un bon memtest cette nuit).

 *konsole wrote:*   

> localhost ~ # smartctl -a /dev/sda | grep Current_Pending_Sector | awk '{print $NF}'
> 
> 0
> 
> localhost ~ # smartctl -a /dev/sda | grep Reallocated_Sector_Ct | awk '{print $NF}'
> ...

 

Je pense que le problème est logiciel et non matériel.

D'abord parce que j'ai ce problème depuis plus d'une semaine, ensuite parce que c'est ma première fois sur Gentoo, la première fois que je fais l'expérience de la compilation du noyau et que donc il risque d'y avoir des problèmes de ce côté là.

J'ai maintenant un message récurant dans les log :

 *Quote:*   

> Sep 24 09:26:29 localhost dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.16" (uid=1000 pid=3304 comm="/usr/bin/python2.6) interface="org.freedesktop.Hal.Manager" member="FindDeviceByCapability" error name="(unset)" requested_reply=0 destination=":1.0" (uid=0 pid=2954 comm="/usr/sbin/hald))

 

Edit...

J'ai fais un tour un peu plus détaillé sur smartctl

 *Quote:*   

> ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
> 
>   1 Raw_Read_Error_Rate     0x000f   200   200   051    Pre-fail  Always       -       147      
> 
>   3 Spin_Up_Time            0x0003   188   186   021    Pre-fail  Always       -       1591     
> ...

 

----------

## Leander256

 *Legoboy wrote:*   

> Mon PC revient tout juste du SAV (problème sur la carte mère), j'ai pas spécialement envie d'avoir encore des problèmes hardware.

 

Justement ça me rappelle un problème que j'avais eu il y a quelques années avec un chipset VIA (en fait j'ai ai eu plein, c'était les moins chers et ce n'était pas un hasard), lorsque je copiais des gros fichiers ils étaient corrompus. Ce problème n'apparaissait que sur les noyaux -ck donc j'avais envoyé un rapport de bug mais il s'est avéré que c'était parce que cette variante stressait beaucoup plus le matériel que le vanilla. Réponse du mainteneur: "j'ai le même problème sur une machine, j'ai underclocké le bus." Donc n'exclus pas la thèse du [strike]suicide[/strike] problème matériel.

 *Legoboy wrote:*   

> D'abord parce que j'ai ce problème depuis plus d'une semaine, ensuite parce que c'est ma première fois sur Gentoo, la première fois que je fais l'expérience de la compilation du noyau et que donc il risque d'y avoir des problèmes de ce côté là.

 

Est-ce que tu as la possibilité de remettre ce noyau fait avec genkernel et de voir si ça fonctionne à nouveau? Sinon est-ce que tu peux en refaire un neuf et tester?

 *Legoboy wrote:*   

> J'ai maintenant un message récurant dans les log :
> 
>  *Quote:*   Sep 24 09:26:29 localhost dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.16" (uid=1000 pid=3304 comm="/usr/bin/python2.6) interface="org.freedesktop.Hal.Manager" member="FindDeviceByCapability" error name="(unset)" requested_reply=0 destination=":1.0" (uid=0 pid=2954 comm="/usr/sbin/hald)) 

 

Tu as un programme écrit en python que tu lances en tant qu'utilisateur (uid=1000) qui a l'air d'appeler une méthode incorrecte de HAL. Est-ce que tu as une idée de ce que ça peut être?

----------

## guilc

non c'est pas logiciel, c'est matériel ! Le disque est en train de mourir.

655 secteurs réalloués, c'est énorme.

D'ailleurs le rapport smart te préviens : FAILING_NOW !!

Si le SAV n'a pas vérifié ça, _ça veut dire qu'ils n'ont même pas fait un petit diagnostic complet pour vérifier que tout va bien (ça me semble une vérification élémentaire

Le disque a aussi beaucoup de spin up : 71349 ça commence à faire. 17 spin-up par heure en moyenne, c'est relativement élevé. Ca contribue à réduire la durée de vie des disques ça.

[Edit]

Et j'insiste hein : le rapport smart est totalement indépendant de l'OS utilisé. C'est des diagnostics faits par le firmware du disque lui même. C'est beaucoup plus bas niveau que ne le serait un test du disque avec "badblocks"

[Edit2]

Un détail supplémentaire là :

```
5 Reallocated_Sector_Ct 0x0033 118 118 140 Pre-fail Always FAILING_NOW 655 
```

sur les 3 valeurs "118 118 140".

Là, le disque te dit que le seuil de deffectuosité c'est 140. La valeur initiale est 200 (valeur standardisée). Elle est descendue à 118, et 118 est la pire valeur que le disque à rencontré (pour le cas particulier de  Reallocated_Sector_Ct cela ne remonte JAMAIS).

Comme la valeur est passée sous le seuil, le disque te prévient qu'il est en train de mourir.

La, la situation du disque est passé au seuil critique. La seule chose à faire, c'est backup et envoi du disque au SAV pour remplacement...

----------

## Legoboy

Le SAV ne peut rien pour moi.

Ils m'ont remplacé la carte mère à cause d'un problème de chipset Nvidia considéré comme un vice caché.

Merci dans tous les cas.

----------

## guilc

 *Legoboy wrote:*   

> Le SAV ne peut rien pour moi.
> 
> Ils m'ont remplacé la carte mère à cause d'un problème de chipset Nvidia considéré comme un vice caché.
> 
> Merci dans tous les cas.

 

Bien sûr que si le SAV peut !

un disque défectueux au bout de 4127h (171 jours donc) de fonctionnement, c'est un défaut. Il doivent le remplacer !

Et le SAV de ton ordinateur ne veut rien faire, tu peux toujours passer directement par le constructeur du disque (ça pourra d'ailleurs aller plus vite) !

----------

## Legoboy

Ok.

Je vais contacter WD.

Merci infiniment dans tous les cas !

----------

## guilc

Chez western faut aller voir là :

http://support.wdc.com/warranty/index_end.asp?lang=fr

Tu colles le numéro de série du disque, ils te disent à quoi tu as droit. En général, les disques en OEM ne sont pas repris directement, il faut passer par le monteur... Dans tous les cas, c'est indiqué, leur truc de suivi est super bien foutu. Si tu es dans les clous pour la garantie, il suffit d'ouvrir une RMA et de suivre la procédure qui est bien détaillée...

----------

## Legoboy

J'ai réinstallé mon système sur un nouveau disque dur...

C'est fou comme ça marche mieux.

Merci beaucoup à tous !

----------

