Bonjour,

j'ai des erreurs qui me surprennent sur ma machine, et je n'arrive pas
a savoir s'il s'agit d'un probleme logiciel ou materiel.

-slackware11, noyau 2.6.21 custom.
-PIII 1GHz, 512Mo RAM

symptomes:
-de temps en temps des erreurs CRC. Par exemple, tar zxvf
<paquet>.tgz
qui échoue sur une erreur CRC.
-Une fois processus shutdown en état "D" ???
-impossibilité de dézipper un gros fichier avec 7z. Cela échoue
systématiquement sur une erreur. (fichier téléchargé deux fois,
vérif md5sum OK)

Par contre:
-memtest a fait une passe complete sans erreur.
-Aucun problème pour recompiler quoi que ce soit.
-rien dans dmesg
-aucun oops ou crash

Que connaissez vous comme tests à réaliser pour écarter la
piste matérielle? memtest? Et pour stresser le CPU? le disque?

Je suis preneur de toute piste qui me permettrait de vérifier toute
partie de mon hardware ou systeme.

Merci

--
Pour contacter l'équipe de modération : moderateurs-fcolm***efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.

Le 04-07-2007, à propos de
erreurs CRC,
octane***alinto.com écrivait dans fr.comp.os.linux.moderated :
> Bonjour,

Bonjour,

> j'ai des erreurs qui me surprennent sur ma machine, et je n'arrive pas
> a savoir s'il s'agit d'un probleme logiciel ou materiel.
>
> -slackware11, noyau 2.6.21 custom.
> -PIII 1GHz, 512Mo RAM
>
> symptomes:
> -de temps en temps des erreurs CRC. Par exemple, tar zxvf
><paquet>.tgz
> qui échoue sur une erreur CRC.
> -Une fois processus shutdown en état "D" ???
> -impossibilité de dézipper un gros fichier avec 7z. Cela échoue
> systématiquement sur une erreur. (fichier téléchargé deux fois,
> vérif md5sum OK)

En décomposant le truc en deux, est-ce que gunzip plante ou le
processus tar ? Si ça passe, c'est certainement relié à un bug
sournois visible très souvent sur sparc32/SMP (certainement en
raison de la lenteur du CPU) et qui concerne la gestion des pipes
dans le noyau. On cherche depuis très longtemps la solution :-(
Mais ça vaudrait le coup de faire un bug report sur kernel.org pour
signaler ce bug sur i386, qu'on ne soit pas les seuls à chercher un
bug "architecture specific" alors qu'il est plus général ;-)

> Par contre:
> -memtest a fait une passe complete sans erreur.
> -Aucun problème pour recompiler quoi que ce soit.
> -rien dans dmesg
> -aucun oops ou crash
>
> Que connaissez vous comme tests à réaliser pour écarter la
> piste matérielle? memtest? Et pour stresser le CPU? le disque?

En dehors de faire tourner memtest durant plusieurs heures, il y a
la technique dite de force brute ;-) Recompiler une libc6 en boucle
doit stresser le CPU. Pour les disques, on peut envisager des choses
à grands coups de dd, mais s'il s'agit d'un problème physique, on
risque de passer à côté (de toute façon, un coup de smartmontools
devrait résoudre ce dernier point, d'autant plus qu'il devrait y
avoir des choses dans les logs).

On peut aussi compiler un gcc avec un make -j8 bootstrap, c'est
assez efficace comme stress ;-)

> Je suis preneur de toute piste qui me permettrait de vérifier toute
> partie de mon hardware ou systeme.

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

--
Pour contacter l'équipe de modération : moderateurs-fcolm***efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.

On 5 juil, 16:03, JKB <knatsc...***koenigsberg.fr> wrote:
>
> En décomposant le truc en deux, est-ce que gunzip plante ou le
> processus tar ? Si ça passe, c'est certainement relié à un bug
> sournois visible très souvent sur sparc32/SMP (certainement en
> raison de la lenteur du CPU) et qui concerne la gestion des pipes
> dans le noyau. On cherche depuis très longtemps la solution :-(
> Mais ça vaudrait le coup de faire un bug report sur kernel.org pour
> signaler ce bug sur i386, qu'on ne soit pas les seuls à chercher un
> bug "architecture specific" alors qu'il est plus général ;-)
>
Quand je serais grand, je ferais des bug reports sur la LKML,
mais la, je crois que la solution sera plus simple (voir plus bas)

> En dehors de faire tourner memtest durant plusieurs heures, il y a
> la technique dite de force brute ;-) Recompiler une libc6 en boucle
> doit stresser le CPU.

c'est finalement ce que j'ai fait.
Quelques scripts qui calculent en boucle des md5sum et des sha1sum
sur des images iso, des compilations en -j, -j4, et -j8 de mplayer
avec
un md5sum derriere, quelques firefox en boucle sur un site web qui a
un monstre tas d'images et d'animations a deux balles, des qemu
et des hdparm -tT sur les deux disques en parallele.

Ca n'a marche qu'un temps, et j'ai eu:
BUG: unable to handle kernel paging request at virtual address
0457adb1
printing eip:
0457adb1
*pde = 00000000
Oops: 0000 [#1]
Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event
snd_seq snd_pcm_oss snd_mixer_oss nfsd exportfs lockd sunrpc
ipt_MASQUERADE xt_state xt_tcpudp nf_nat_ftp nf_conntrack_ftp
iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nfnetlink
iptable_filter ip_tables x_tables nls_iso8859_1 nls_cp437 vfat fat
shpchp snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm snd_timer
snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device evdev snd
tulip rtc_cmos cyblafb via_agp 8139too mii rtc_core rtc_lib soundcore
agpgart uhci_hcd via686a hwmon i2c_isa i2c_viapro i2c_core parport_pc
pcspkr parport
CPU: 0
EIP: 0060:[<0457adb1>] Not tainted VLI
EFLAGS: 00210246 (2.6.21 #4)
EIP is at 0x457adb1
eax: 00000000 ebx: 00000000 ecx: 00001000 edx: 00000000
esi: c014aca0 edi: 00001000 ebp: 00000000 esp: d41bbf20
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process cc1 (pid: 16413, ti=d41ba000 task=d522f590 task.ti=d41ba000)
Stack: c014aca5 c014a78f 00000000 00000022 00000003 00001000 00000000
c0149d99
00000000 00000022 bfbfb71c d79e2614 00000004 400eb9d0 d522f590
00000003
00000000 00000000 00000000 b7de0dc8 db9f5900 00000000 400eb9d0
db9f5900
Call Trace:
[<c014aca5>] split_vma+0x65/0xe0
[<c014a78f>] get_unmapped_area+0x4f/0x90
[<c0149d99>] do_mmap_pgoff+0xc9/0x7d0
[<c0107b03>] sys_mmap2+0x73/0xa0
[<c0103f6c>] syscall_call+0x7/0xb
[<c0320000>] copy_sec_ctx+0x80/0x110
=====================Code: Bad EIP value.
EIP: [<0457adb1>] 0x457adb1 SS:ESP 0068:d41bbf20

Je ne suis pas un expert, mais a lire
"unable to handle kernel paging request"
et get_unmapped_area, do_mmap_pgoff, sys_mmap, qui font penser à
mmap, j'ai tendance a incriminer la memoire.

Le rack a deux banques memoires, j'ai boote avec mem=256M,
relance les scripts, et mis a part la charge de 4-5 (ca me
surprend qu'elle ne monte pas plus d'ailleurs), tout a tres bien
fonctionne une nuit entiere.

Quand j'aurais le temps, je retesterai avec memtest sur plusieurs
passes pour savoir si c'est vraiment la memoire.

> Pour les disques, on peut envisager des choses
> à grands coups de dd, mais s'il s'agit d'un problème physique, on
> risque de passer à côté (de toute façon, un coup de smartmontools
> devrait résoudre ce dernier point, d'autant plus qu'il devrait y
> avoir des choses dans les logs).
>
logs vides. (enfin, a part le kernel oops)

> On peut aussi compiler un gcc avec un make -j8 bootstrap, c'est
> assez efficace comme stress ;-)
>
finalement oui. J'espere juste que ce n'est pas le CPU qui est touche,
et que la piste de la memoire HS ne soit qu'une coincidence.
Enfin, so far, so good, esperons que ca continue.

--
Pour contacter l'équipe de modération : moderateurs-fcolm***efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.

Le 06-07-2007, à propos de
Re: erreurs CRC,
octane***alinto.com écrivait dans fr.comp.os.linux.moderated :
> On 5 juil, 16:03, JKB <knatsc...***koenigsberg.fr> wrote:
>>
>> En décomposant le truc en deux, est-ce que gunzip plante ou le
>> processus tar ? Si ça passe, c'est certainement relié à un bug
>> sournois visible très souvent sur sparc32/SMP (certainement en
>> raison de la lenteur du CPU) et qui concerne la gestion des pipes
>> dans le noyau. On cherche depuis très longtemps la solution :-(
>> Mais ça vaudrait le coup de faire un bug report sur kernel.org pour
>> signaler ce bug sur i386, qu'on ne soit pas les seuls à chercher un
>> bug "architecture specific" alors qu'il est plus général ;-)
>>
> Quand je serais grand, je ferais des bug reports sur la LKML,

Ce n'est pas réservé qu'à des gourou ;-)

> mais la, je crois que la solution sera plus simple (voir plus bas)
>
>> En dehors de faire tourner memtest durant plusieurs heures, il y a
>> la technique dite de force brute ;-) Recompiler une libc6 en boucle
>> doit stresser le CPU.
>
> c'est finalement ce que j'ai fait.
> Quelques scripts qui calculent en boucle des md5sum et des sha1sum
> sur des images iso, des compilations en -j, -j4, et -j8 de mplayer
> avec
> un md5sum derriere, quelques firefox en boucle sur un site web qui a
> un monstre tas d'images et d'animations a deux balles, des qemu
> et des hdparm -tT sur les deux disques en parallele.
>
> Ca n'a marche qu'un temps, et j'ai eu:
> BUG: unable to handle kernel paging request at virtual address
> 0457adb1
> printing eip:
> 0457adb1
> *pde = 00000000
> Oops: 0000 [#1]
> Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event
> snd_seq snd_pcm_oss snd_mixer_oss nfsd exportfs lockd sunrpc
> ipt_MASQUERADE xt_state xt_tcpudp nf_nat_ftp nf_conntrack_ftp
> iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nfnetlink
> iptable_filter ip_tables x_tables nls_iso8859_1 nls_cp437 vfat fat
> shpchp snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm snd_timer
> snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device evdev snd
> tulip rtc_cmos cyblafb via_agp 8139too mii rtc_core rtc_lib soundcore
> agpgart uhci_hcd via686a hwmon i2c_isa i2c_viapro i2c_core parport_pc
> pcspkr parport
> CPU: 0
> EIP: 0060:[<0457adb1>] Not tainted VLI
> EFLAGS: 00210246 (2.6.21 #4)
> EIP is at 0x457adb1
> eax: 00000000 ebx: 00000000 ecx: 00001000 edx: 00000000
> esi: c014aca0 edi: 00001000 ebp: 00000000 esp: d41bbf20
> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
> Process cc1 (pid: 16413, ti=d41ba000 task=d522f590 task.ti=d41ba000)
> Stack: c014aca5 c014a78f 00000000 00000022 00000003 00001000 00000000
> c0149d99
> 00000000 00000022 bfbfb71c d79e2614 00000004 400eb9d0 d522f590
> 00000003
> 00000000 00000000 00000000 b7de0dc8 db9f5900 00000000 400eb9d0
> db9f5900
> Call Trace:
> [<c014aca5>] split_vma+0x65/0xe0
> [<c014a78f>] get_unmapped_area+0x4f/0x90
> [<c0149d99>] do_mmap_pgoff+0xc9/0x7d0
> [<c0107b03>] sys_mmap2+0x73/0xa0
> [<c0103f6c>] syscall_call+0x7/0xb
> [<c0320000>] copy_sec_ctx+0x80/0x110
> =====================Code: Bad EIP value.
> EIP: [<0457adb1>] 0x457adb1 SS:ESP 0068:d41bbf20
>
> Je ne suis pas un expert, mais a lire
> "unable to handle kernel paging request"
> et get_unmapped_area, do_mmap_pgoff, sys_mmap, qui font penser à
> mmap, j'ai tendance a incriminer la memoire.
>
> Le rack a deux banques memoires, j'ai boote avec mem=256M,
> relance les scripts, et mis a part la charge de 4-5 (ca me
> surprend qu'elle ne monte pas plus d'ailleurs), tout a tres bien
> fonctionne une nuit entiere.
>
> Quand j'aurais le temps, je retesterai avec memtest sur plusieurs
> passes pour savoir si c'est vraiment la memoire.

Commence par refaire le test avec un 2.6.20.x, x étant grand.
Il peut très bien s'agir d'un bug dans la gestion de la mémoire
(c'est du vécu sur Sparc), et le 2.6.21, au risque de me répéter,
est tout sauf stable.

>> Pour les disques, on peut envisager des choses
>> à grands coups de dd, mais s'il s'agit d'un problème physique, on
>> risque de passer à côté (de toute façon, un coup de smartmontools
>> devrait résoudre ce dernier point, d'autant plus qu'il devrait y
>> avoir des choses dans les logs).
>>
> logs vides. (enfin, a part le kernel oops)
>
>> On peut aussi compiler un gcc avec un make -j8 bootstrap, c'est
>> assez efficace comme stress ;-)
>>
> finalement oui. J'espere juste que ce n'est pas le CPU qui est touche,
> et que la piste de la memoire HS ne soit qu'une coincidence.
> Enfin, so far, so good, esperons que ca continue.

Un CPU touché impliquerait un plantage quel que soit la taille
mémoire.

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

--
Pour contacter l'équipe de modération : moderateurs-fcolm***efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.

On 6 juil, 13:32, JKB <knatsc...***koenigsberg.fr> wrote:
> >> En décomposant le truc en deux, est-ce que gunzip

c'est gunzip, encore un exemple:
vlvc-scm-2007-05-18/aclocal.m4

gzip: stdin: invalid compressed data--crc error
vlvc-scm-2007-05-18/vlc.spec
tar: Child returned status 1
tar: Statut d'erreur reporté d'erreurs précédentes.


> >> plante ou le
> >> processus tar ? Si ça passe, c'est certainement relié à un bug
> >> sournois visible très souvent sur sparc32/SMP (certainement en
> >> raison de la lenteur du CPU) et qui concerne la gestion des pipes
> >> dans le noyau. On cherche depuis très longtemps la solution :-(
> Commence par refaire le test avec un 2.6.20.x, x étant grand.
> Il peut très bien s'agir d'un bug dans la gestion de la mémoire
> (c'est du vécu sur Sparc), et le 2.6.21, au risque de me répéter,
> est tout sauf stable.
>
bon, je vais passer au 2.6.22, c'est agacant ce probleme.

Sinon, je peux peut etre tester des trucs sur cette machine?
Si tu as quelque chose a verifier avant que je bazarde ce 2.6.21?

> > finalement oui. J'espere juste que ce n'est pas le CPU qui est touche,
> > et que la piste de la memoire HS ne soit qu'une coincidence.
> > Enfin, so far, so good, esperons que ca continue.
>
et ca ne continue pas. Je vais remettre la deuxieme barrette de RAM.


> Un CPU touché impliquerait un plantage quel que soit la taille
> mémoire.
>
oui, mais pour moi le CPU HS signifierait la mise au rebut de ma
machine..

--
Pour contacter l'équipe de modération : moderateurs-fcolm***efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.