Utilisation stable de l'intégralité de la ram disponible

Le
Thibaut Chèze
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--enig14BB7305150EDBCA6BF1B888
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bonsoir à tous,

Je viens vers vous car ma configuration plante (kernel oops), au bout
d'un certain temps, lorsque je sollicite l'intégralité de ma ra=
m (soft +
cache).
Je pense que le problème viens de l'adressage, bien que j'ai joué=
de
malchance par le passé (j'ai du changer à deux reprise un jeu d=
e
barrettes), celles-ci passent sans problème le memtest86+ v4.10. Mai=
s
celui-ci scan de 0 à 3G, puis passe de 4G à 9G (manifestement l=
es
adresses comprises entre 3G et ~4G sont remappée entre 8G et 9G) et =
je
pense que le problème doit y être lier.

Actuellement, j'ai réussi à obtenir un système "stable" en=
ajoutant
l'option "mem=8127M" lors du boot (j'ai également essayé l'op=
tion "",
sans succès) qui me permet d'avoir 6363M d'utilisables, soit une per=
te
d'un peu plus d'1G. Auriez-vous une solution pour y palier ?

Ma configuration:
- OS: Debian GNU/Linux Squeeze 64Bit, Kernel 2.6.32-5 amd64
- Carte Mère : Asus Formula 2 Crosshair (avec carte graphique
intégrée qui prend 64M de ram au système, les valeurs poss=
ibles dans le
BIOS sont 64M, 128M, 256M et 512M) avec l'option "Memory Hole Remapping"
active dans le Bios, car sinon, seulement 7G sont utilisables sans pour
autant que le système ne plante.
- DDR2 Corsair 4x2G


Infos en configuration fonctionnelle :

*************************************************************************=
**************************************
#cat /proc/meminfo ; echo ; free -m ; echo ; cat /proc/mtrr ; echo ;
cat /proc/pagetypeinfo
MemTotal: 7032884 kB
MemFree: 52852 kB
Buffers: 105520 kB
Cached: 5759084 kB
SwapCached: 0 kB
Active: 3662644 kB
Inactive: 3034516 kB
Active(anon): 688384 kB
Inactive(anon): 145028 kB
Active(file): 2974260 kB
Inactive(file): 2889488 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 16777208 kB
SwapFree: 16777208 kB
Dirty: 20340 kB
Writeback: 4 kB
AnonPages: 832564 kB
Mapped: 11576 kB
Shmem: 848 kB
Slab: 213196 kB
SReclaimable: 179104 kB
SUnreclaim: 34092 kB
KernelStack: 1672 kB
PageTables: 4872 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 20293648 kB
Committed_AS: 954036 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 150900 kB
VmallocChunk: 34359573492 kB
HardwareCorrupted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 8000 kB
DirectMap2M: 3004416 kB
DirectMap1G: 4194304 kB

total used free shared buffers cached=

Mem: 6868 6816 51 0 103 5624=

-/+ buffers/cache: 1089 5778
Swap: 16383 0 16383

reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-bac=
k
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-bac=
k
reg02: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-bac=
k
reg03: base=0x200000000 ( 8192MB), size= 1024MB, count=1: write-bac=
k
reg04: base=0x0d8000000 ( 3456MB), size= 128MB, count=1: write-com=
bining

Page block order: 9
Pages per block: 512

Free pages count per migrate type at order 0 1 2
3 4 5 6 7 8 9 10
Node 0, zone DMA, type Unmovable 2 2 3
3 3 1 0 0 1 0 0
Node 0, zone DMA, type Reclaimable 0 0 0
0 0 0 0 0 0 0 0
Node 0, zone DMA, type Movable 0 0 0
0 0 0 0 0 0 0 3
Node 0, zone DMA, type Reserve 0 0 0
0 0 0 0 0 0 1 0
Node 0, zone DMA, type Isolate 0 0 0
0 0 0 0 0 0 0 0
Node 0, zone DMA32, type Unmovable 2979 75 4
1 0 0 0 0 0 0 0
Node 0, zone DMA32, type Reclaimable 1212 7 3
0 0 0 0 0 0 0 0
Node 0, zone DMA32, type Movable 230 205 133
77 0 0 0 0 0 0 0
Node 0, zone DMA32, type Reserve 0 0 2
6 6 6 2 0 0 1 0
Node 0, zone DMA32, type Isolate 0 0 0
0 0 0 0 0 0 0 0
Node 0, zone Normal, type Unmovable 519 0 0
0 0 0 0 0 0 0 0
Node 0, zone Normal, type Reclaimable 1 0 0
0 0 0 0 0 0 0 0
Node 0, zone Normal, type Movable 209 168 50
0 0 0 0 0 0 0 0
Node 0, zone Normal, type Reserve 0 0 5
5 6 2 2 2 1 0 0
Node 0, zone Normal, type Isolate 0 0 0
0 0 0 0 0 0 0 0

Number of blocks type Unmovable Reclaimable Movable
Reserve Isolate
Node 0, zone DMA 1 0 6
1 0
Node 0, zone DMA32 18 49 1459
2 0
Node 0, zone Normal 113 33 1868
2 0

*************************************************************************=
**************************************

Infos en configuration automatique, non fonctionnelle:

cat /proc/meminfo ; echo ; free -m ; echo ; cat /proc/mtrr ; echo ; cat
/proc/pagetypeinfo
MemTotal: 8133692 kB
MemFree: 5061744 kB
Buffers: 18596 kB
Cached: 2708892 kB
SwapCached: 0 kB
Active: 277024 kB
Inactive: 2678288 kB
Active(anon): 227956 kB
Inactive(anon): 416 kB
Active(file): 49068 kB
Inactive(file): 2677872 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 16777208 kB
SwapFree: 16777208 kB
Dirty: 412 kB
Writeback: 0 kB
AnonPages: 227924 kB
Mapped: 13240 kB
Shmem: 504 kB
Slab: 51196 kB
SReclaimable: 18600 kB
SUnreclaim: 32596 kB
KernelStack: 1736 kB
PageTables: 2776 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 20844052 kB
Committed_AS: 417412 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 150900 kB
VmallocChunk: 34359572980 kB
HardwareCorrupted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 6976 kB
DirectMap2M: 3072000 kB
DirectMap1G: 5242880 kB

total used free shared buffers cached=

Mem: 7943 3000 4942 0 18 2646=

-/+ buffers/cache: 336 7606
Swap: 16383 0 16383

reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-bac=
k
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-bac=
k
reg02: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-bac=
k
reg03: base=0x200000000 ( 8192MB), size= 1024MB, count=1: write-bac=
k
reg04: base=0x0d8000000 ( 3456MB), size= 128MB, count=1: write-com=
bining

Page block order: 9
Pages per block: 512

Free pages count per migrate type at order 0 1 2
3 4 5 6 7 8 9 10
Node 0, zone DMA, type Unmovable 2 3 1
2 2 2 0 0 1 0 0
Node 0, zone DMA, type Reclaimable 0 0 0
0 0 0 0 0 0 0 0
Node 0, zone DMA, type Movable 0 0 0
0 0 0 0 0 0 0 3
Node 0, zone DMA, type Reserve 0 0 0
0 0 0 0 0 0 1 0
Node 0, zone DMA, type Isolate 0 0 0
0 0 0 0 0 0 0 0
Node 0, zone DMA32, type Unmovable 1 1 0
0 0 1 0 1 1 1 0
Node 0, zone DMA32, type Reclaimable 0 0 0
0 0 0 0 0 0 0 0
Node 0, zone DMA32, type Movable 3 10 4
5 6 13 4 4 5 4 695
Node 0, zone DMA32, type Reserve 0 0 0
0 0 0 0 0 0 0 1
Node 0, zone DMA32, type Isolate 0 0 0
0 0 0 0 0 0 0 0
Node 0, zone Normal, type Unmovable 48 70 16
18 11 8 7 5 1 1 0
Node 0, zone Normal, type Reclaimable 1 1 2
1 1 1 1 0 1 0 0
Node 0, zone Normal, type Movable 1 0 0
0 1 1 1 1 1 1 525
Node 0, zone Normal, type Reserve 0 0 0
0 0 0 0 0 0 0 1
Node 0, zone Normal, type Isolate 0 0 0
0 0 0 0 0 0 0 0

Number of blocks type Unmovable Reclaimable Movable
Reserve Isolate
Node 0, zone DMA 1 0 6
1 0
Node 0, zone DMA32 2 0 1524
2 0
Node 0, zone Normal 54 10 2494
2 0

*************************************************************************=
**************************************

Je n'ai pas de traces des kernel oops, c'est le plus souvent le device
mapper qui est en cours d'exécution à ce moment la ce qui empÃ=
ªche toute
sauvegarde de log (impossible de lancer de soft, impossible d'écrire=
un
fichier, )

Un dernier point, le système est parfaitement fonctionnel s'il n'y a=
que
deux barrettes, et à ce moment là le remapping se fait entre 4G=
et 5G
(si je me souvient bien).

Merci d'avance pour votre aide.

Thibaut


--enig14BB7305150EDBCA6BF1B888
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--BEGIN PGP SIGNATURE--
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx9QOkACgkQLQe0eoqzCa2XywCeI3THNp/UMBeLFDBc1l2p3FMW
UmsAoNMH/ws5hrrWNH8RQ95tkzp7vwRU
«iJ
--END PGP SIGNATURE--

--enig14BB7305150EDBCA6BF1B888--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C7D40E9.3040402@gmail.com
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Thibaut Chèze
Le #22526791
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4D9263C8831DFFB5E682D7E9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

J'ai oublier de mettre la seconde option au boot que j'ai testé :
"iommu=noagp,noaperture"
Désolé,

Bonne soirée,

Thibaut


Le 31/08/2010 19:50, Thibaut Chèze a écrit :
Bonsoir à tous,

Je viens vers vous car ma configuration plante (kernel oops), au bout
d'un certain temps, lorsque je sollicite l'intégralité de ma ram (soft +
cache).
Je pense que le problème viens de l'adressage, bien que j'ai jouà © de
malchance par le passé (j'ai du changer à deux reprise un jeu de
barrettes), celles-ci passent sans problème le memtest86+ v4.10. M ais
celui-ci scan de 0 à 3G, puis passe de 4G à 9G (manifestement les
adresses comprises entre 3G et ~4G sont remappée entre 8G et 9G) e t je
pense que le problème doit y être lier.

Actuellement, j'ai réussi à obtenir un système "stable" en ajoutant
l'option "mem27M" lors du boot (j'ai également essayé l' option "",
sans succès) qui me permet d'avoir 6363M d'utilisables, soit une p erte
d'un peu plus d'1G. Auriez-vous une solution pour y palier ?

Ma configuration:
- OS: Debian GNU/Linux Squeeze 64Bit, Kernel 2.6.32-5 amd64
- Carte Mère : Asus Formula 2 Crosshair (avec carte graphique
intégrée qui prend 64M de ram au système, les valeurs po ssibles dans le
BIOS sont 64M, 128M, 256M et 512M) avec l'option "Memory Hole Remapping "
active dans le Bios, car sinon, seulement 7G sont utilisables sans pour
autant que le système ne plante.
- DDR2 Corsair 4x2G


Infos en configuration fonctionnelle :

*********************************************************************** ****************************************
#cat /proc/meminfo ; echo ; free -m ; echo ; cat /proc/mtrr ; echo ;
cat /proc/pagetypeinfo
MemTotal: 7032884 kB
MemFree: 52852 kB
Buffers: 105520 kB
Cached: 5759084 kB
SwapCached: 0 kB
Active: 3662644 kB
Inactive: 3034516 kB
Active(anon): 688384 kB
Inactive(anon): 145028 kB
Active(file): 2974260 kB
Inactive(file): 2889488 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 16777208 kB
SwapFree: 16777208 kB
Dirty: 20340 kB
Writeback: 4 kB
AnonPages: 832564 kB
Mapped: 11576 kB
Shmem: 848 kB
Slab: 213196 kB
SReclaimable: 179104 kB
SUnreclaim: 34092 kB
KernelStack: 1672 kB
PageTables: 4872 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 20293648 kB
Committed_AS: 954036 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 150900 kB
VmallocChunk: 34359573492 kB
HardwareCorrupted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 8000 kB
DirectMap2M: 3004416 kB
DirectMap1G: 4194304 kB

total used free shared buffers cach ed
Mem: 6868 6816 51 0 103 56 24
-/+ buffers/cache: 1089 5778
Swap: 16383 0 16383

reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-b ack
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-b ack
reg02: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-b ack
reg03: base=0x200000000 ( 8192MB), size= 1024MB, count=1: write-b ack
reg04: base=0x0d8000000 ( 3456MB), size= 128MB, count=1: write-c ombining

Page block order: 9
Pages per block: 512

Free pages count per migrate type at order 0 1 2
3 4 5 6 7 8 9 10
Node 0, zone DMA, type Unmovable 2 2 3
3 3 1 0 0 1 0 0
Node 0, zone DMA, type Reclaimable 0 0 0
0 0 0 0 0 0 0 0
Node 0, zone DMA, type Movable 0 0 0
0 0 0 0 0 0 0 3
Node 0, zone DMA, type Reserve 0 0 0
0 0 0 0 0 0 1 0
Node 0, zone DMA, type Isolate 0 0 0
0 0 0 0 0 0 0 0
Node 0, zone DMA32, type Unmovable 2979 75 4
1 0 0 0 0 0 0 0
Node 0, zone DMA32, type Reclaimable 1212 7 3
0 0 0 0 0 0 0 0
Node 0, zone DMA32, type Movable 230 205 133
77 0 0 0 0 0 0 0
Node 0, zone DMA32, type Reserve 0 0 2
6 6 6 2 0 0 1 0
Node 0, zone DMA32, type Isolate 0 0 0
0 0 0 0 0 0 0 0
Node 0, zone Normal, type Unmovable 519 0 0
0 0 0 0 0 0 0 0
Node 0, zone Normal, type Reclaimable 1 0 0
0 0 0 0 0 0 0 0
Node 0, zone Normal, type Movable 209 168 50
0 0 0 0 0 0 0 0
Node 0, zone Normal, type Reserve 0 0 5
5 6 2 2 2 1 0 0
Node 0, zone Normal, type Isolate 0 0 0
0 0 0 0 0 0 0 0

Number of blocks type Unmovable Reclaimable Movable
Reserve Isolate
Node 0, zone DMA 1 0 6
1 0
Node 0, zone DMA32 18 49 1459
2 0
Node 0, zone Normal 113 33 1868
2 0

*********************************************************************** ****************************************

Infos en configuration automatique, non fonctionnelle:

cat /proc/meminfo ; echo ; free -m ; echo ; cat /proc/mtrr ; echo ; ca t
/proc/pagetypeinfo
MemTotal: 8133692 kB
MemFree: 5061744 kB
Buffers: 18596 kB
Cached: 2708892 kB
SwapCached: 0 kB
Active: 277024 kB
Inactive: 2678288 kB
Active(anon): 227956 kB
Inactive(anon): 416 kB
Active(file): 49068 kB
Inactive(file): 2677872 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 16777208 kB
SwapFree: 16777208 kB
Dirty: 412 kB
Writeback: 0 kB
AnonPages: 227924 kB
Mapped: 13240 kB
Shmem: 504 kB
Slab: 51196 kB
SReclaimable: 18600 kB
SUnreclaim: 32596 kB
KernelStack: 1736 kB
PageTables: 2776 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 20844052 kB
Committed_AS: 417412 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 150900 kB
VmallocChunk: 34359572980 kB
HardwareCorrupted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 6976 kB
DirectMap2M: 3072000 kB
DirectMap1G: 5242880 kB

total used free shared buffers cach ed
Mem: 7943 3000 4942 0 18 26 46
-/+ buffers/cache: 336 7606
Swap: 16383 0 16383

reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-b ack
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-b ack
reg02: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-b ack
reg03: base=0x200000000 ( 8192MB), size= 1024MB, count=1: write-b ack
reg04: base=0x0d8000000 ( 3456MB), size= 128MB, count=1: write-c ombining

Page block order: 9
Pages per block: 512

Free pages count per migrate type at order 0 1 2
3 4 5 6 7 8 9 10
Node 0, zone DMA, type Unmovable 2 3 1
2 2 2 0 0 1 0 0
Node 0, zone DMA, type Reclaimable 0 0 0
0 0 0 0 0 0 0 0
Node 0, zone DMA, type Movable 0 0 0
0 0 0 0 0 0 0 3
Node 0, zone DMA, type Reserve 0 0 0
0 0 0 0 0 0 1 0
Node 0, zone DMA, type Isolate 0 0 0
0 0 0 0 0 0 0 0
Node 0, zone DMA32, type Unmovable 1 1 0
0 0 1 0 1 1 1 0
Node 0, zone DMA32, type Reclaimable 0 0 0
0 0 0 0 0 0 0 0
Node 0, zone DMA32, type Movable 3 10 4
5 6 13 4 4 5 4 695
Node 0, zone DMA32, type Reserve 0 0 0
0 0 0 0 0 0 0 1
Node 0, zone DMA32, type Isolate 0 0 0
0 0 0 0 0 0 0 0
Node 0, zone Normal, type Unmovable 48 70 16
18 11 8 7 5 1 1 0
Node 0, zone Normal, type Reclaimable 1 1 2
1 1 1 1 0 1 0 0
Node 0, zone Normal, type Movable 1 0 0
0 1 1 1 1 1 1 525
Node 0, zone Normal, type Reserve 0 0 0
0 0 0 0 0 0 0 1
Node 0, zone Normal, type Isolate 0 0 0
0 0 0 0 0 0 0 0

Number of blocks type Unmovable Reclaimable Movable
Reserve Isolate
Node 0, zone DMA 1 0 6
1 0
Node 0, zone DMA32 2 0 1524
2 0
Node 0, zone Normal 54 10 2494
2 0

*********************************************************************** ****************************************

Je n'ai pas de traces des kernel oops, c'est le plus souvent le device
mapper qui est en cours d'exécution à ce moment la ce qui emp êche toute
sauvegarde de log (impossible de lancer de soft, impossible d'écri re un
fichier, ...)

Un dernier point, le système est parfaitement fonctionnel s'il n'y a que
deux barrettes, et à ce moment là le remapping se fait entre 4G et 5G
(si je me souvient bien).

Merci d'avance pour votre aide.

Thibaut






--------------enig4D9263C8831DFFB5E682D7E9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx9QxEACgkQLQe0eoqzCa3JQACg1vpIZ0ZBsFskZfMIT8/Ei4d1
8EsAoLJe53w1tfa896nwsrWnQqjj5RDO
=zTn8
-----END PGP SIGNATURE-----

--------------enig4D9263C8831DFFB5E682D7E9--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
JC
Le #22527031
Je viens vers vous car ma configuration plante (kernel oops), au bout
d'un certain temps, lorsque je sollicite l'intégralité de ma ra m (soft +
cache).
Je pense que le problème viens de l'adressage



Tu as combien de barrette de mémoire : 2 ou 4 ?
Et avec 1 seule barrette ?
le problème persiste ?

Et si ca venait de l'affichage ?
As-tu fais tourner un serveur SSH et essayé de prendre la machine à   distance ?

Cordialement.
--
Salutations.
Jean-Claude

Parole : Chose qui ne vaut si peu qu'on la donne.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Thibaut Chèze
Le #22528631
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigAAE0A04C6BDF4FCB12B88160
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bonjour,

Je viens vers vous car ma configuration plante (kernel oops), au bout
d'un certain temps, lorsque je sollicite l'intégralité de ma ram (soft +
cache).
Je pense que le problème viens de l'adressage



Tu as combien de barrette de mémoire : 2 ou 4 ?
Et avec 1 seule barrette ?
le problème persiste ?



J'avais mis plus de détails techniques dans la suite du mail. J'ai 4
barrettes, et le système est stable avec 2 (en dual channel).
Et si ca venait de l'affichage ?
As-tu fais tourner un serveur SSH et essayé de prendre la machine à distance ?



Et pour être plus précis, par ssh, ou console directe (clavier + ecran),
impossible de reprendre la main, car le device mapper étant planter
(Disques en raid6), plus d'accès disques possible, donc plus possibl e de
lancer de nouveaux soft (mem si théoriquement ils sont déjà chargés en
RAM). Le bash qui tournait avant le crash, tournait toujours, mais
impossible de lancer quoi que se soit dedans, ni même un autre bash. ..

J'ai réussi a avoir une trace par le passée, je te la met en fi n de
mail, mais il se peut que mes traces actuelles soit un peu différent e,
bien que très ressemble, car celle-ci à été faite à   l'époque où l'un de
mes jeux de barrettes était défectueux.
Cordialement.



************************************************************************* **************
Kernel oops :

[ 7461.450522] BUG: unable to handle kernel paging request at
ffff89018b4f98e8
[ 7461.452509] IP: [<ffffffffa0001628>] clone_endio+0x1e/0xad [dm_mod]
[ 7461.452509] PGD 0
[ 7461.452509] Oops: 0000 [#1] SMP
[ 7461.452509] last sysfs file: /sys/devices/virtual/block/md0/md/raid_di sks
[ 7461.452509] CPU 2
[ 7461.452509] Modules linked in: ext2 ext4 mbcache jbd2 crc16 raid456
async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_conservative
powernow_k8 xt_multiport iptable_filter ip_tables x_tables xfrm_user
xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 deflate zlib_deflate
ctr twofish twofish_common camellia serpent blowfish cast5 des_generic
cbc cryptd aes_x86_64 aes_generic xcbc rmd160 sha256_generic
sha1_generic hmac crypto_null af_key fuse clip atm md_mod dm_crypt
snd_hda_codec_nvhdmi snd_hda_codec_analog snd_hda_intel snd_hda_codec
snd_hwdep sd_mod crc_t10dif snd_pcm ide_pci_generic snd_timer edac_core
sata_promise video i2c_nforce2 ahci ata_generic joydev snd shpchp
serio_raw output wmi edac_mce_amd libata psmouse pcspkr i2c_core
asus_atk0110 pci_hotplug evdev amd74xx soundcore scsi_mod snd_page_alloc
button processor squashfs loop aufs(C) nfs lockd fscache nfs_acl
auth_rpcgss sunrpc ide_generic ide_core usbhid hid ohci_hcd sky2
ehci_hcd forcedeth usbcore nls_base thermal fan thermal_sys dm_mirror
dm_region_hash dm_log dm_mod
[ 7461.484282] Pid: 29577, comm: md0_raid6 Tainted: G C
2.6.32-trunk-amd64 #1 System Product Name
[ 7461.484282] RIP: 0010:[<ffffffffa0001628>] [<ffffffffa0001628>]
clone_endio+0x1e/0xad [dm_mod]
[ 7461.484282] RSP: 0018:ffff880125c49c70 EFLAGS: 00010286
[ 7461.484282] RAX: ffffffffa00a0010 RBX: 0000000000000000 RCX:
00000000001a000b
[ 7461.484282] RDX: ffff8801dccec7b8 RSI: 0000000000000000 RDI:
ffffc900063a0040
[ 7461.484282] RBP: ffff8802383ce780 R08: 0000000000000000 R09:
ffff8800000663c0
[ 7461.484282] R10: ffff880098126840 R11: ffffffffa000160a R12:
ffff8802129df858
[ 7461.484282] R13: 0000000000000000 R14: ffff89018b4f98e8 R15:
ffff88023b6960f0
[ 7461.484282] FS: 00007f4a2c1996f0(0000) GS:ffff880008880000(0000)
knlGS:0000000000000000
[ 7461.484282] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[ 7461.484282] CR2: ffff89018b4f98e8 CR3: 0000000001001000 CR4:
00000000000006e0
[ 7461.484282] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 7461.484282] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[ 7461.484282] Process md0_raid6 (pid: 29577, threadinfo
ffff880125c48000, task ffff88023a5d1c40)
[ 7461.484282] Stack:
[ 7461.484282] ffff8800747e4a80 ffff88007f686780 ffff88023bfbd000
0000000000000000
[ 7461.484282] <0> ffff880098126840 ffffffffa00014ec ffff88007f46d150
ffff8800747e4a80
[ 7461.484282] <0> ffff8801337c8950 ffff88023dace200 000000000000000c
0000000000000000
[ 7461.484282] Call Trace:
[ 7461.484282] [<ffffffffa00014ec>] ? dec_pending+0x130/0x157 [dm_mod]
[ 7461.484282] [<ffffffffa0358bed>] ? handle_stripe+0xc83/0x1785 [raid45 6]
[ 7461.484282] [<ffffffffa0354f0d>] ? __release_stripe+0x165/0x199
[raid456]
[ 7461.484282] [<ffffffffa0359a94>] ? raid5d+0x3a5/0x3ee [raid456]
[ 7461.484282] [<ffffffff812e5b9c>] ? schedule_timeout+0x2e/0xdd
[ 7461.484282] [<ffffffffa031f828>] ? md_thread+0xf1/0x10f [md_mod]
[ 7461.484282] [<ffffffff81064aae>] ? autoremove_wake_function+0x0/0x2e
[ 7461.484282] [<ffffffffa031f737>] ? md_thread+0x0/0x10f [md_mod]
[ 7461.484282] [<ffffffff810647e1>] ? kthread+0x79/0x81
[ 7461.484282] [<ffffffff81011b6a>] ? child_rip+0xa/0x20
[ 7461.484282] [<ffffffff81064768>] ? kthread+0x0/0x81
[ 7461.484282] [<ffffffff81011b60>] ? child_rip+0x0/0x20
[ 7461.484282] Code: 0f 0b eb fe 5b 5d 41 5c 41 5d 41 5e c3 41 56 41 55
41 54 55 48 89 fd 53 4c 8b 67 58 89 f3 49 8b 7c 24 08 4d 8b 34 24 48 8b
47 08 <4d> 8b 2e 4c 8b 40 48 48 8b 45 18 83 e0 01 09 f0 b8 fb ff ff ff
[ 7461.484282] RIP [<ffffffffa0001628>] clone_endio+0x1e/0xad [dm_mod]
[ 7461.484282] RSP <ffff880125c49c70>
[ 7461.484282] CR2: ffff89018b4f98e8
[ 7461.736996] ---[ end trace a448e113455b1dd6 ]---

************************************************************************* **************

Merci,

Thibaut


--------------enigAAE0A04C6BDF4FCB12B88160
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkx+AWcACgkQLQe0eoqzCa1KSwCgjd8+lhVARJaMB8eDsi2uqKVZ
FGoAn28cE/c4zuV5nlURVN57KtYCf6RD
=W6os
-----END PGP SIGNATURE-----

--------------enigAAE0A04C6BDF4FCB12B88160--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Alain Vaugham
Le #22529011
Le Wednesday 01 September 2010 09:31:51 Thibaut Chèze, vous avez à ©crit :
Bonjour,



Bonjour

>> Je viens vers vous car ma configuration plante (kernel oops), au bout
>> d'un certain temps, lorsque je sollicite l'intégralité de ma ram (soft +
>> cache).


[...]
[ 7461.450522] BUG: unable to handle kernel paging request at
ffff89018b4f98e8


[...]
Peut-être à rapprocher avec le même problème que j'ai s ignalé :
http://lists.debian.org/debian-user-french/2010/08/msg00221.html

Depuis, j'ai testé la ram pendant 48h. Il n'y a pas de défaut.
Comme les plantages sont assez facilement reproductibles, j'évite de s aturer
la ram avec de gros transferts de fichiers simultanés.
Ces plantages sont apparus depuis que j'ai installé rdiff-backup. Je n e sais
pas si c'est lié.


Chez moi le dernier plantage que j'ai reproduit était :
Aug 10 20:57:51 mach05 kernel: [40268.916052] BUG: unable to handle kernel
paging request at ffffa469c1d84000
Aug 10 20:57:51 mach05 kernel: [40268.916126] IP: [<ffffffff8028166a>]
handle_mm_fault+0xdb/0x867
Aug 10 20:57:51 mach05 kernel: [40268.916184] PGD 0
Aug 10 20:57:51 mach05 kernel: [40268.916215] Oops: 0000 [1] SMP
Aug 10 20:57:51 mach05 kernel: [40268.916251] CPU 0
Aug 10 20:57:51 mach05 kernel: [40268.916282] Modules linked in: appletalk
nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs ipv6 loop psmouse pcspkr
serio_raw snd_pcm snd_timer snd soundcore snd_page_alloc k8temp i2c_piix4
button i2c_cor
e shpchp pci_hotplug evdev ext3 jbd mbcache sd_mod ide_disk ide_pci_generic
3c59x mii e1000 ehci_hcd ohci_hcd sata_svw serverworks ide_core ata_generic
libata scsi_mod dock thermal processor fan thermal_sys [last unloaded:
scsi_wait_scan]
Aug 10 20:57:51 mach05 kernel: [40268.916623] Pid: 3623, comm: imap-login N ot
tainted 2.6.26-2-amd64 #1
Aug 10 20:57:51 mach05 kernel: [40268.916665] RIP: 0010:[<ffffffff8028166a> ]
[<ffffffff8028166a>] handle_mm_fault+0xdb/0x86



--
Alain Vaugham
Clef GPG : 0xD26D18BC

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Thibaut Chèze
Le #22529211
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1C5CFB4A70220B994CDD1817
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


[ 7461.450522] BUG: unable to handle kernel paging request at
ffff89018b4f98e8



[...]
Peut-être à rapprocher avec le même problème que j' ai signalé :
http://lists.debian.org/debian-user-french/2010/08/msg00221.html




Après lecture, il n'est vraiment pas impossible que nous ayons le mà ªme
problème. Essai peut-être de mettre moins de barrettes, pour mo i sa
devient fonctionnel. (Perso, pas de pb de voltage, il est bon, le cas
aussi... Physiquement, tout est ok normalement).
Depuis, j'ai testé la ram pendant 48h. Il n'y a pas de défaut .
Comme les plantages sont assez facilement reproductibles, j'évite de saturer
la ram avec de gros transferts de fichiers simultanés.
Ces plantages sont apparus depuis que j'ai installé rdiff-backup. Je ne sais
pas si c'est lié.




Par contre pas de rapport avec rdiff-backup, car je ne l'utilise pas, il
n'est même pas installer.
Ceci étant, je fais beaucoup d'action qui solicite la ram (transfert s,
encodage, ...) mais c'est pour sa que j'en ai mis autant, donc pour moi
il est exclut de limités ces utilisations...

Mais bon si l'on me trouve une solution, elle fonctionnera peut-être
aussi pour toi ^^.

Thibaut


--------------enig1C5CFB4A70220B994CDD1817
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkx+GpwACgkQLQe0eoqzCa2vWwCeN4Mg03rFJEEmGjbSxDonI1yV
0sMAn3NWZMUupSpMqAI5D0c3PuPzX8rf
=+PEG
-----END PGP SIGNATURE-----

--------------enig1C5CFB4A70220B994CDD1817--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Alain Vaugham
Le #22529321
Le Wednesday 01 September 2010 11:19:24 Thibaut Chèze, vous avez à ©crit :
>> [ 7461.450522] BUG: unable to handle kernel paging request at
>> ffff89018b4f98e8
>
> [...]
> Peut-être à rapprocher avec le même problème que j' ai signalé :
> http://lists.debian.org/debian-user-french/2010/08/msg00221.html

Après lecture, il n'est vraiment pas impossible que nous ayons le m ême
problème. Essai peut-être de mettre moins de barrettes, pour mo i sa
devient fonctionnel. (Perso, pas de pb de voltage, il est bon, le cas
aussi... Physiquement, tout est ok normalement).




Je n'ai pas encore vérifié la tension quand à mettre moins d e barrettes, je
vais essayer mais la machine est un serveur en production. Pour ce test, il
va falloir que je trouve un créneau pour l'arrêter longtemps ou m onter un
serveur de remplacement.
Dès que possible je mettrais ici les résultats.

--
Alain Vaugham
Clef GPG : 0xD26D18BC

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Sylvain L. Sauvage
Le #22529491
Le mercredi 1 septembre 2010 à 09:31:51, Thibaut Chèze a écr it :
Bonjour,



’jour,

[…]



Pour clairement (/proc/mtrr n’est pas utile, la preuve tu as
le même avec 7 ou 8 Gio) voir ce que Linux a comme RAM :
$ dmesg | grep -F Memory
[ 0.000000] Memory: 2048700k/2095936k available (3068k kernel
code, 388k absent, 46848k reserved, 1886k data, 580k init)
(available = memory + absent + reserved)

Si ça ne correspond pas à ce qui est installé, ça peu t être
parce que le BIOS ne donne pas tout : Linux se fie au BIOS (même
pas peur !).

Pour voir ce que Linux voit comme RAM passée par le BIOS :
$ dmesg | grep -F usable
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800
(usable)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000007fed0000
(usable)

Tu sommes ensuites les intervalles :
0x9f800 + 0x7fed0000-0x100000 = 2145843200
2145843200 ≈ 2046.44 Gio

Si ton PC plante seulement quand tu demandes au BIOS de rendre
les trous, c’est peut-être un problème de BIOS (= annon ce de
mauvaises plages à Linux). Personne n’a signalé de probl ème avec
ta carte mère ?

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Thibaut Chèze
Le #22531451
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig94395E238627FE5002A0872B
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bonsoir,

Pour clairement (/proc/mtrr n’est pas utile, la preuve tu as
le même avec 7 ou 8 Gio) voir ce que Linux a comme RAM :



En fait, le proc mtrr, c'était parce qu'il était différent dans le cas
ou dans le Bios je desactivais le Memory Hole Remapping, mais puisque le
système n'est pas plus stable dans ce cas, je n'ai pas insister.
$ dmesg | grep -F Memory
[ 0.000000] Memory: 2048700k/2095936k available (3068k kernel
code, 388k absent, 46848k reserved, 1886k data, 580k init)
(available = memory + absent + reserved)

Si ça ne correspond pas à ce qui est installé, ça peut être
parce que le BIOS ne donne pas tout : Linux se fie au BIOS (même
pas peur !).

Pour voir ce que Linux voit comme RAM passée par le BIOS :
$ dmesg | grep -F usable
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800
(usable)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000007fed0000
(usable)

Tu sommes ensuites les intervalles :
0x9f800 + 0x7fed0000-0x100000 = 2145843200
2145843200 ≈ 2046.44 Gio

Si ton PC plante seulement quand tu demandes au BIOS de rendre
les trous, c’est peut-être un problème de BIOS (= a nnonce de
mauvaises plages à Linux). Personne n’a signalé de pr oblème avec
ta carte mère ?




Pour ma carte mère la seul chose qui s'y rapproche c'était un p ost sur
le site d'asus avec le debut d'un boot kernel.
Mais je n'y ai rien vu de concluent :-$
Je donnerais le lien dès que je remet la main dessus.


Pour ce qui est des traces, la avec l'option "mem=" :

# dmesg | grep -F Memory
[ 0.000000] Memory: 7021668k/8322048k available (3067k kernel code,
1115796k absent, 184584k reserved, 1886k data, 584k init)
[ 30.409195] EDAC amd64: This node reports that Memory ECC is currently
disabled, set F3x44[22] (0000:00:18.3).

# dmesg | grep -F usable
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009b800 (usable)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000bbed0000 (usable)
[ 0.000000] BIOS-e820: 0000000100000000 - 0000000240000000 (usable)
[ 0.000000] user: 0000000000000000 - 000000000009b800 (usable)
[ 0.000000] user: 0000000000100000 - 00000000bbed0000 (usable)
[ 0.000000] user: 0000000100000000 - 00000001fbf00000 (usable)
[ 0.000000] e820 update range: 0000000000000000 - 0000000000010000
(usable) ==> (reserved)
[ 0.000000] e820 update range: 00000000c0000000 - 0000000100000000
(usable) ==> (reserved)

Et sans l'option "mem=" :
# dmesg | grep -F Memory
[ 0.000000] Memory: 8122476k/9437184k available (3067k kernel code,
1115796k absent, 198912k reserved, 1886k data, 584k init)
[ 45.902343] EDAC amd64: This node reports that Memory ECC is currently
disabled, set F3x44[22] (0000:00:18.3).

# dmesg | grep -F usable
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009b800 (usable)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000bbed0000 (usable)
[ 0.000000] BIOS-e820: 0000000100000000 - 0000000240000000 (usable)
[ 0.000000] e820 update range: 0000000000000000 - 0000000000010000
(usable) ==> (reserved)
[ 0.000000] e820 update range: 00000000c0000000 - 0000000100000000
(usable) ==> (reserved)

Que puis-je en conclure ? Que puis-je faire pour récupérer la p lage
00000001fbf00000 - 0000000240000000, ou l'empêcher de la dépass er ?

Merci d'avance,

Thibaut



--------------enig94395E238627FE5002A0872B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx+lrkACgkQLQe0eoqzCa3INACfRZAxaGYgLBq61DTPw6c0HJ3X
ygkAoIHOywbzwANUSCR2/jv9jvyGFgyv
™1G
-----END PGP SIGNATURE-----

--------------enig94395E238627FE5002A0872B--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Sylvain L. Sauvage
Le #22533171
Le mercredi 1 septembre 2010 à 20:08:57, Thibaut Chèze a écr it :
Bonsoir,



’jour,

[…]
Pour ce qui est des traces, la avec l'option "mem=" :

# dmesg | grep -F Memory
[ 0.000000] Memory: 7021668k/8322048k available (3067k kernel
code, 1115796k absent, 184584k reserved, 1886k data, 584k
init) [ 30.409195] EDAC amd64: This node reports that Memory
ECC is currently disabled, set F3x44[22] (0000:00:18.3).
[…]
Et sans l'option "mem=" :
# dmesg | grep -F Memory
[ 0.000000] Memory: 8122476k/9437184k available (3067k kernel
code, 1115796k absent, 198912k reserved, 1886k data, 584k
init) [ 45.902343] EDAC amd64: This node reports that Memory
ECC is currently disabled, set F3x44[22] (0000:00:18.3).



Donc, en fin de compte, mem= ne fait que limiter ta RAM à
8 Gio au total, mais comme tu en as un bout déplacé après 8 Gio,
tu le perds.

[…]
[ 0.000000] e820 update range: 0000000000000000 -
0000000000010000 (usable) ==> (reserved)



Bon, ça, je l’ai aussi, le message précédent à ©tant que Linux a
détecté un BIOS AMI et qu’il a peur que le début de la RAM ne
soit corrompue par celui-ci. 0x10000 = 64 kio, donc ça n’est pas
énorme.

[ 0.000000] e820 update range: 00000000c0000000 -
0000000100000000 (usable) ==> (reserved)



Je ne sais pas pourquoi il le fait mais ça fait pile poil
1 Gio. Et, sans mem=, tu as 9 Gio, donc 1 Gio d’absent (trou
« réservé »), c’est logique (en un sens).

Que puis-je en conclure ? Que puis-je faire pour récupérer la
plage 00000001fbf00000 - 0000000240000000, ou l'empêcher de
la dépasser ?



À mon avis, l’option mem= n’est pas la bonne piste car elle ne
fait que limiter la zone adressable. Tu as 8 Gio (moins env.
256 Mio) si tu ne la mets pas, ce qui semble correct.
En revanche, il reste savoir pourquoi ça plante aussi
fréquemment quand elle n’y est pas. Mais là, moi pas savo ir.
Peut-être voir avec la LKML (mais c’est sûr que sans trac e des
oops, ça n’est pas évident).
(Tu peux aussi essayer d’autres valeurs pour mem=. P.ex. peut-
être qu’à 8.5 Gio, tu récupèreras tout et ne pl anteras pas… Ça
peut être utile pour mieux cerner le problème.)

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Thibaut Chèze
Le #22548931
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3FDAE0F176ECD00E03063DD4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bonsoir à tous,

Je reviens vers vous, car de mon coté j'ai fais quelques avancé es, mais
bon toujours rien de pleinement fonctionnel...

Que puis-je en conclure ? Que puis-je faire pour récupérer l a
plage 00000001fbf00000 - 0000000240000000, ou l'empêcher de
la dépasser ?



À mon avis, l’option mem= n’est pas la bonne p iste car elle ne
fait que limiter la zone adressable. Tu as 8 Gio (moins env.
256 Mio) si tu ne la mets pas, ce qui semble correct.
En revanche, il reste savoir pourquoi ça plante aussi
fréquemment quand elle n’y est pas. Mais là, moi pas savoir.
Peut-être voir avec la LKML (mais c’est sûr que sans trace des
oops, ça n’est pas évident).
(Tu peux aussi essayer d’autres valeurs pour mem=. P.ex. pe ut-
être qu’à 8.5 Gio, tu récupèreras tout et n e planteras pas… Ça
peut être utile pour mieux cerner le problème.)




Je suis d'accord, mem= n'est pas la solution, mais c'est déjà un début
pour pouvoir fonctionné en dégradé.
Et j'ai d'ailleurs essayé d'autres valeurs sans aucun succès. L e système
plante plus vite, plus la mémoire est grande, à 8192M, le systà ¨me à tenu
4 jours...

Autrement, j'ai essayé d'autres options du noyau après avoir ex ploré ces
liens:
*
http://vip.asus.com/forum/view.aspx?id 080110054618984&board_id=1&m odel=M2NPV-VM&page=1&SLanguage=en-us
* http://fixunix.com/kernel/385042-aperture-memory-hole-x86_64-a.html
* http://fixunix.com/embedded/5808-memory-hole.html
*
http://ubuntuforums.org/showthread.php?t18854&highlight=enable+iom mu+option+bios
* http://ubuntuforums.org/showthread.php?t63612
*
http://ubuntuforums.org/showthread.php?t18854&highlight=enable+iom mu+option+bios&page=3
*
http://ww2.cs.fsu.edu/~rosentha/linux/2.6.26.5/docs/x86_64/boot-options.t xt
* http://ubuntuforums.org/showpost.php?ph55830&postcountˆ

J'ai adopté les options "iommu=soft,noaperture,memaper" pour ne pl us
avoir ce message dans dmesg (le memaper était dans l'espoir de ré soudre
le problème:
[0.004000] Aperture beyond 4Gb. Ignoring.
[0.004000] Your BIOS doesn't leave a aperture memory hole
[0.004000] Please enable the IOMMU option in the BIOS setup
[0.004000] This costs you 64 MB of RAM
...

Si quelqu'un en sait plus sur l'option iommu et peu me conseiller dans
les options à placer dans mon cas, n'hésitez-pas, j'essaierai ( pas avant
jeudi, la je suis en cours de reconstruction du RAID sur la machine...)
Je ne sais pas pourquoi, mais j'ai bien l'impression que mes soucis
proviennent de la.
D'ailleurs, avec cette option et sans la mem, la mémoire disponible dans
un free est inférieur de 1Mo que lors de l'absence de celle-ci.

Autrement, je souhaitais revalidé la bonne santé du nouveau jeu de
barrettes que j'ai installé suite au plantage à 8192M, elles so nt
bonnes. Et dans un dernier test, je ne tourne actuellement que sur
elles, je vous met toutes les infos que j'ai ci-après, des fois que cela
vous donne des pistes...

Merci

************************************************************************* ***************
# cat /proc/meminfo ; echo ; free -m ; echo ; cat /proc/mtrr ; echo ;
MemTotal: 3996320 kB
MemFree: 34656 kB
Buffers: 194684 kB
Cached: 2730776 kB
SwapCached: 0 kB
Active: 1386204 kB
Inactive: 2419260 kB
Active(anon): 540224 kB
Inactive(anon): 340516 kB
Active(file): 845980 kB
Inactive(file): 2078744 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 16777208 kB
SwapFree: 16777208 kB
Dirty: 12 kB
Writeback: 64 kB
AnonPages: 880004 kB
Mapped: 16368 kB
Shmem: 736 kB
Slab: 91768 kB
SReclaimable: 58352 kB
SUnreclaim: 33416 kB
KernelStack: 1672 kB
PageTables: 4800 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 18775368 kB
Committed_AS: 964500 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 143712 kB
VmallocChunk: 34359579124 kB
HardwareCorrupted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 4928 kB
DirectMap2M: 2025472 kB
DirectMap1G: 2097152 kB

total used free shared buffers cached
Mem: 3902 3869 33 0 190 2666
-/+ buffers/cache: 1012 2890
Swap: 16383 0 16383

reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-bac k
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-bac k
reg02: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-bac k
reg03: base=0x0d8000000 ( 3456MB), size= 128MB, count=1: write-com bining

# dmesg | grep -F Memory
[ 0.000000] Memory: 3985096k/5242880k available (3068k kernel code,
1115796k absent, 141988k reserved, 1886k data, 580k init)
[ 53.840105] EDAC amd64: This node reports that Memory ECC is
currently disabled, set F3x44[22] (0000:00:18.3).

# dmesg | grep -F usable
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009b800 (usable)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000bbed0000 (usable)
[ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
[ 0.000000] e820 update range: 0000000000000000 - 0000000000010000
(usable) ==> (reserved)
[ 0.000000] e820 update range: 00000000c0000000 - 0000000100000000
(usable) ==> (reserved)

************************************************************************* ***************


--------------enig3FDAE0F176ECD00E03063DD4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyGhTMACgkQLQe0eoqzCa2rkACfZrlxkuQXI/zxdWO0ps882CJN
myMAoMX70ATYyi5gvDaQUomJSrhG4htE
=akud
-----END PGP SIGNATURE-----

--------------enig3FDAE0F176ECD00E03063DD4--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Publicité
Poster une réponse
Anonyme