Re: Utilisation stable de l'intégralité de la ram disponible
Bonjour, Après tests et surveillance, mes barrettes ne dépassent jamais les 45°C, et sont le plus souvent à 42°C (:-)), la différence est dû à la température de l'air qui entre dans la tour, non à l'utilisation de la ram. Le voltage oscile entre 2.14V et 2.16V... Je ne pense pas que le problème soit physique du coup... Et la franchement, je ne vois pas quoi changer dans la conf pour changer cela. Le 12/09/2010 17:47, Thibaut Chèze a écrit : Bonjour Reste à voir la stabilité avec 8 Gio. Là-dessus, mon avis est de faire gaffe à la température (donc aussi à la tension) : la RAM semble perdre en cohérence quand elle a chaud. (4 barrettes sont aussi plus difficiles à refroidir que 2 (plus serrées, etc.).) En effet, perso, quand je les touches, elles ne sont pas très chaudes, il y a un ventilateur d'extraction de 12cm 3cm au dessus d'elles. Les sensors m'indiquent qu'elles sont à 45°C en usage normal (pas spécialement stressant). Je ferais un retour si jamais elle augmente significativement lors d'une opération la sollicitant fortement. Autrement, le voltage est réglé à 2.10V dans le Bios, et le capteur indique 2.14 V, mais je ne pense pas qu'une si faible différence soit la cause des problèmes (Je regarderai egalement si cette valeur change lorsque le système est chargé). signature.asc Description: OpenPGP digital signature
Re: Utilisation stable de l'intégralité de la ram disponible
Bonjour Reste à voir la stabilité avec 8 Gio. Là-dessus, mon avis est de faire gaffe à la température (donc aussi à la tension) : la RAM semble perdre en cohérence quand elle a chaud. (4 barrettes sont aussi plus difficiles à refroidir que 2 (plus serrées, etc.).) En effet, perso, quand je les touches, elles ne sont pas très chaudes, il y a un ventilateur d'extraction de 12cm 3cm au dessus d'elles. Les sensors m'indiquent qu'elles sont à 45°C en usage normal (pas spécialement stressant). Je ferais un retour si jamais elle augmente significativement lors d'une opération la sollicitant fortement. Autrement, le voltage est réglé à 2.10V dans le Bios, et le capteur indique 2.14 V, mais je ne pense pas qu'une si faible différence soit la cause des problèmes (Je regarderai egalement si cette valeur change lorsque le système est chargé). signature.asc Description: OpenPGP digital signature
Re: Utilisation stable de l'intégralité de la ram disponible
On 09/09/2010 11:02 PM, Thibaut Chèze wrote: Bonsoir, J'ai remonter les deux autres barretes: Voici les résultats pour en ne mettant pas l'option mem et en changeant dans le bios la configuration de la ram pour la carte vidéo: * Vidéo 64M : # dmesg | grep -F Memory [0.00] Memory: 8122468k/9437184k available (3068k kernel code, 1115796k absent, 198920k reserved, 1886k data, 580k init) Par curiosité, que signifie la partie absent ? Je ne la vois pas sur ma machine... -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4c8b403d.6020...@free.fr
Re: Utilisation stable de l'intégralité de la ram disponible
Le jeudi 9 septembre 2010 à 23:02:45, Thibaut Chèze a écrit : Bonsoir, ’jour, […] 8122468k - 8056932k = 65536k = 64M Ok. 8056932k - 7927908k = 129024k = 126M NOk devrait être 128M. 7927908k - 7669860k = 258048k = 252M NOk devrait être 256M. Bon, je ne sais trop quoi en conclure... Les résultats ne sont pas exactement pile poil se qu'ils devraient, mais en même temps, je ne sais pas avec précisions ce qu'ils doivent être... Tout ce que je peux dire, c'est qu'ils n'en sont pas si éloignés, et que du coup, je ne pense pas qu'il y ai un soucis vis à vis de cela. Une opinion ? La même que toi. L’idée était surtout de vérifier que quand tu lui dis de prendre X, il prend bien X et pas 2×X ou X+K. Reste à voir la stabilité avec 8 Gio. Là-dessus, mon avis est de faire gaffe à la température (donc aussi à la tension) : la RAM semble perdre en cohérence quand elle a chaud. (4 barrettes sont aussi plus difficiles à refroidir que 2 (plus serrées, etc.).) -- 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/201009111447.18125.sylvain.l.sauv...@free.fr
Re: Utilisation stable de l'intégralité de la ram disponible
Le samedi 11 septembre 2010 à 10:39:25, deb a écrit : […] # dmesg | grep -F Memory [0.00] Memory: 8122468k/9437184k available (3068k kernel code, 1115796k absent, 198920k reserved, 1886k data, 580k init) Par curiosité, que signifie la partie absent ? Linux a vu 9 Gi d’adresses alors qu’il n’y en a que 8 Gio de mémoire. Sans doute parce qu’un bout de mémoire a été déplacé (remapped) à une adresse supérieure à 8 Gi (8 Gi donc = 9 Gi). Mais il n’y a évidemment que 8 Gio de RAM. Donc sur les 9 Gio qui ont une adresse, seuls 8 Gio sont vraiment disponibles. Donc 1 Gio adressable est absent. (Bon, là, c’est 1 Gio + 64 Mio + 1684 kio.) (Encore une fois, ce ne sont que les déductions d’un borgne…) Je ne la vois pas sur ma machine... Ça dépend. Sur un système à 2 Gio, j’ai seulement 388 kio d’absents. Sur un système à 4 Gio, j’ai 768 Mio + 1924 kio d’absents, remappage du framebuffer de 128 Mio de la carte graphique intégrée au dessus de 4 Gi oblige. Et sur mon routeur à 32 Mio, j’ai 0 absent… -- 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/201009111509.28018.sylvain.l.sauv...@free.fr
Re: Utilisation stable de l'intégralité de la ram disponible
Bonjour,
[…]
Le 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
exploré ces liens:
[…]
Ce sont surtout des aveugles qui se guident entre eux, et donc
tournent en rond. (Un peu comme nous, donc.)
Le « problème » qu’ils essaient de régler, ce sont des
messages bénins du noyau et la « perte » de 64 Mio pour/par
l’IOMMU. Ça ne me semble pas en rapport avec ton problème de
plantage.
:-D
J'ai adopté les options iommu=soft,noaperture,memaper pour
ne plus 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.
Mm, moi pas. Comme quoi les impressions…
Les options iommu :
soft :
Puisque tu as un AMD (d’après ta carte mère), Linux peut
utiliser le GART (donc pas la peine de mettre iommu=soft).
Tu dois aussi voir ce genre de messages dans dmesg :
[0.785442] PCI-DMA: Disabling AGP.
[0.785520] PCI-DMA: aperture base @ 2000 size 65536 KB
[0.785521] PCI-DMA: using GART IOMMU.
[0.785524] PCI-DMA: Reserving 64MB of IOMMU area in the AGP
aperture
memaper :
C’est pour changer la taille du IOMMU. Sans valeur, c’est
64 Mio, donc idem que sans l’option.
noaperture :
Si je comprends bien, c’est pour empêcher d’utiliser
l’ouverture prévue pour l’AGP pour l’IOMMU.
Pour voir l’effet de chaque option, dmesg dm-{opts}
et regarde-les côte à côte…
Cependant, le noyau semble très bien se débrouiller tout seul.
Et les 64 Mio pour l’IOMMU semblent soit ne pas être un vrai
problème, soit, de toute façon, ne pas être récupérables sans
aide du BIOS.
Merci pour tes précisions. Manifestement, j'ai la fausse illusion de
comprendre ce que je fais :-D. Effectivement, par la suite j'ai les 4
lignes que tu as cité.
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 sont 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...
Quand tu fais un test, tu laisses tourner suffisamment ?
(24-48 h)
Oui, oui :-). Dernier test, 57h (et quand je les ai eux, j'ai testé
pendant plus de 4j, suite à mes problèmes, je voulais vraiment pouvoir
avoir confiance).
À noter aussi que memtest ne stresse pas toujours les
barrettes comme une utilisation réelle. Un bon gros md5sum sur
des données plus grosses que la RAM réussissait à me faire
planter des barrettes qui tenaient très bien face à memtest.
Et actuellement, le système tourne sur les 2 barrettes récemment
obtenues (et dernièrement testées), il ne semble pas y avoir de problème
avec l'utilisation normal que j'en fais (comme tu l'a mentionner, gros
md5 de 8G en moyenne, par2 de fichiers ... et reconstruction du raid6).
Pour le moment aucun problème, le raid devrais finir aujourd'hui, a voir
si il n'y a pas de plantage au moment où il finit. Et si j'ai le temps,
je remet les 2 autres barrettes ce soir.
Donc, avec 4 Gio, tu perds « seuleument » 200 Mio. Ce qui est
quand même beaucoup si ta carte vidéo ne prend que 64 Mio (je
perds 142 Mio sur une machine dont la c.v. est à 128 Mio (mais
c’est pas forcément comparable : elle utilise le « Sideport »
d’AMD)) mais c’est sans rapport avec le Gio perdu avant.
Tu n’as aucune autre option dans le BIOS ? Tu as essayé de
changer la taille de la RAM de la c.v. pour voir si la
répercussion était exacte ?
J'avais fait le test, j'ai plus les valeurs en tête, mais oui, je crois
bien me rappeler qu'en augmentant la taille de la ram video, je perdais
l'équivalent en ram disponible. Je referais le test et communiquerai les
infos.
Au fait, avec 8 Gio, c’était les mêmes barrettes (marque
caractéristiques) ? Parfois les mélanges…
Oui ce sont les mêmes barrettes exactement, les DDR2 Corsair XMS2 de 2G
chacunes (1066Mhz, cas 5-5-5-15 T2 à 2.10V).
Merci beaucoup.
Thibaut
signature.asc
Description: OpenPGP digital signature
Re: Utilisation stable de l'intégralité de la ram disponible
Bonsoir,
J'ai remonter les deux autres barretes:
Voici les résultats pour en ne mettant pas l'option mem et en changeant
dans le bios la configuration de la ram pour la carte vidéo:
* Vidéo 64M :
# dmesg | grep -F Memory
[0.00] Memory: 8122468k/9437184k available (3068k kernel code,
1115796k absent, 198920k reserved, 1886k data, 580k init)
[ 53.814785] EDAC amd64: This node reports that Memory ECC is
currently disabled, set F3x44[22] (:00:18.3).
* Vidéo 128M :
# dmesg | grep -F Memory
[0.00] Memory: 8056932k/9437184k available (3068k kernel code,
1181332k absent, 198920k reserved, 1886k data, 580k init)
[ 34.580225] EDAC amd64: This node reports that Memory ECC is
currently disabled, set F3x44[22] (:00:18.3).
* Vidéo 256M :
# dmesg | grep -F Memory
[0.00] Memory: 7927908k/9437184k available (3068k kernel code,
1312404k absent, 196872k reserved, 1886k data, 580k init)
[ 50.808586] EDAC amd64: This node reports that Memory ECC is
currently disabled, set F3x44[22] (:00:18.3).
* Vidéo 512M :
# dmesg | grep -F Memory
[0.00] Memory: 7669860k/9437184k available (3068k kernel code,
1574548k absent, 192776k reserved, 1886k data, 580k init)
[ 24.375618] EDAC amd64: This node reports that Memory ECC is
currently disabled, set F3x44[22] (:00:18.3).
* Vidéo Auto :
# dmesg | grep -F Memory
[0.00] Memory: 7927908k/9437184k available (3068k kernel code,
1312404k absent, 196872k reserved, 1886k data, 580k init)
[ 23.845597] EDAC amd64: This node reports that Memory ECC is
currently disabled, set F3x44[22] (:00:18.3).
Auto est donc de 256M.
8122468k - 8056932k = 65536k = 64M Ok.
8056932k - 7927908k = 129024k = 126M NOk devrait être 128M.
7927908k - 7669860k = 258048k = 252M NOk devrait être 256M.
Bon, je ne sais trop quoi en conclure... Les résultats ne sont pas
exactement pile poil se qu'ils devraient, mais en même temps, je ne sais
pas avec précisions ce qu'ils doivent être... Tout ce que je peux dire,
c'est qu'ils n'en sont pas si éloignés, et que du coup, je ne pense pas
qu'il y ai un soucis vis à vis de cela.
Une opinion ?
Thibaut
Le 09/09/2010 11:05, Thibaut Chèze a écrit :
Bonjour,
[…]
Le 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
exploré ces liens:
[…]
Ce sont surtout des aveugles qui se guident entre eux, et donc
tournent en rond. (Un peu comme nous, donc.)
Le « problème » qu’ils essaient de régler, ce sont des
messages bénins du noyau et la « perte » de 64 Mio pour/par
l’IOMMU. Ça ne me semble pas en rapport avec ton problème de
plantage.
:-D
J'ai adopté les options iommu=soft,noaperture,memaper pour
ne plus 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.
Mm, moi pas. Comme quoi les impressions…
Les options iommu :
soft :
Puisque tu as un AMD (d’après ta carte mère), Linux peut
utiliser le GART (donc pas la peine de mettre iommu=soft).
Tu dois aussi voir ce genre de messages dans dmesg :
[0.785442] PCI-DMA: Disabling AGP.
[0.785520] PCI-DMA: aperture base @ 2000 size 65536 KB
[0.785521] PCI-DMA: using GART IOMMU.
[0.785524] PCI-DMA: Reserving 64MB of IOMMU area in the AGP
aperture
memaper :
C’est pour changer la taille du IOMMU. Sans valeur, c’est
64 Mio, donc idem que sans l’option.
noaperture :
Si je comprends bien, c’est pour empêcher d’utiliser
l’ouverture prévue pour l’AGP pour l’IOMMU.
Pour voir l’effet de chaque option, dmesg dm-{opts}
et regarde-les côte à côte…
Cependant, le noyau semble très bien se débrouiller tout seul.
Et les 64 Mio pour l’IOMMU semblent soit ne pas être un vrai
problème, soit, de toute façon, ne pas être récupérables sans
aide du BIOS.
Merci pour tes précisions. Manifestement, j'ai la fausse illusion de
comprendre ce que je fais :-D. Effectivement, par la suite j'ai les 4
lignes que tu as cité.
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 sont bonnes. Et dans un dernier test, je ne
tourne actuellement que sur elles, je vous met toutes les
infos que j'ai
Re: Utilisation stable de l'intégralité de la ram disponible
Le mardi 7 septembre 2010 à 20:32:18, Thibaut Chèze a écrit :
Bonsoir à tous,
’jour,
[…]
Le 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
exploré ces liens:
[…]
Ce sont surtout des aveugles qui se guident entre eux, et donc
tournent en rond. (Un peu comme nous, donc.)
Le « problème » qu’ils essaient de régler, ce sont des
messages bénins du noyau et la « perte » de 64 Mio pour/par
l’IOMMU. Ça ne me semble pas en rapport avec ton problème de
plantage.
J'ai adopté les options iommu=soft,noaperture,memaper pour
ne plus 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.
Mm, moi pas. Comme quoi les impressions…
Les options iommu :
soft :
Puisque tu as un AMD (d’après ta carte mère), Linux peut
utiliser le GART (donc pas la peine de mettre iommu=soft).
Tu dois aussi voir ce genre de messages dans dmesg :
[0.785442] PCI-DMA: Disabling AGP.
[0.785520] PCI-DMA: aperture base @ 2000 size 65536 KB
[0.785521] PCI-DMA: using GART IOMMU.
[0.785524] PCI-DMA: Reserving 64MB of IOMMU area in the AGP
aperture
memaper :
C’est pour changer la taille du IOMMU. Sans valeur, c’est
64 Mio, donc idem que sans l’option.
noaperture :
Si je comprends bien, c’est pour empêcher d’utiliser
l’ouverture prévue pour l’AGP pour l’IOMMU.
Pour voir l’effet de chaque option, dmesg dm-{opts}
et regarde-les côte à côte…
Cependant, le noyau semble très bien se débrouiller tout seul.
Et les 64 Mio pour l’IOMMU semblent soit ne pas être un vrai
problème, soit, de toute façon, ne pas être récupérables sans
aide du BIOS.
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 sont 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...
Quand tu fais un test, tu laisses tourner suffisamment ?
(24-48 h)
À noter aussi que memtest ne stresse pas toujours les
barrettes comme une utilisation réelle. Un bon gros md5sum sur
des données plus grosses que la RAM réussissait à me faire
planter des barrettes qui tenaient très bien face à memtest.
[…]
Note que free donne moins d’info que /proc/meminfo, lequel
donne des infos inutiles. dmesg est franchement plus clair.
# dmesg | grep -F Memory
[0.00] Memory: 3985096k/5242880k available (3068k
kernel code, 1115796k absent, 141988k reserved, 1886k data,
580k init)
Donc, avec 4 Gio, tu perds « seuleument » 200 Mio. Ce qui est
quand même beaucoup si ta carte vidéo ne prend que 64 Mio (je
perds 142 Mio sur une machine dont la c.v. est à 128 Mio (mais
c’est pas forcément comparable : elle utilise le « Sideport »
d’AMD)) mais c’est sans rapport avec le Gio perdu avant.
Tu n’as aucune autre option dans le BIOS ? Tu as essayé de
changer la taille de la RAM de la c.v. pour voir si la
répercussion était exacte ?
Au fait, avec 8 Gio, c’était les mêmes barrettes (marque
caractéristiques) ? Parfois les mélanges…
--
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 debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/201009081619.03177.sylvain.l.sauv...@free.fr
Re: Utilisation stable de l'intégralité de la ram disponible
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 la plage 0001fbf0 - 00024000, 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 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. peut- être qu’à 8.5 Gio, tu récupèreras tout et ne 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. Le 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 exploré ces liens: * http://vip.asus.com/forum/view.aspx?id=20080110054618984board_id=1model=M2NPV-VMpage=1SLanguage=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?t=1018854highlight=enable+iommu+option+bios * http://ubuntuforums.org/showthread.php?t=1063612 * http://ubuntuforums.org/showthread.php?t=1018854highlight=enable+iommu+option+biospage=3 * http://ww2.cs.fsu.edu/~rosentha/linux/2.6.26.5/docs/x86_64/boot-options.txt * http://ubuntuforums.org/showpost.php?p=6855830postcount=88 J'ai adopté les options iommu=soft,noaperture,memaper pour ne plus 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 sont 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 sharedbuffers cached Mem: 3902 3869 33 0190 2666 -/+ buffers/cache: 1012 2890 Swap:16383 0 16383 reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back reg01: base=0x08000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x1 ( 4096MB), size= 1024MB, count=1: write-back reg03: base=0x0d800 ( 3456MB), size= 128MB, count=1: write-combining # dmesg | grep -F Memory [0.00] 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,
Re: Utilisation stable de l'intégralité de la ram disponible
Le mercredi 1 septembre 2010 à 20:08:57, Thibaut Chèze a écrit : Bonsoir, ’jour, […] Pour ce qui est des traces, la avec l'option mem= : # dmesg | grep -F Memory [ 0.00] 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] (:00:18.3). […] Et sans l'option mem= : # dmesg | grep -F Memory [ 0.00] 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] (: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.00] e820 update range: - 0001 (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. 0x1 = 64 kio, donc ça n’est pas énorme. [ 0.00] e820 update range: c000 - 0001 (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 0001fbf0 - 00024000, 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 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. peut- être qu’à 8.5 Gio, tu récupèreras tout et ne planteras 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/201009021115.15516.sylvain.l.sauv...@free.fr
Re: Utilisation stable de l'intégralité de la ram disponible
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 possible 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 fin de mail, mais il se peut que mes traces actuelles soit un peu différente, 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 89018b4f98e8 [ 7461.452509] IP: [a0001628] clone_endio+0x1e/0xad [dm_mod] [ 7461.452509] PGD 0 [ 7461.452509] Oops: [#1] SMP [ 7461.452509] last sysfs file: /sys/devices/virtual/block/md0/md/raid_disks [ 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:[a0001628] [a0001628] clone_endio+0x1e/0xad [dm_mod] [ 7461.484282] RSP: 0018:880125c49c70 EFLAGS: 00010286 [ 7461.484282] RAX: a00a0010 RBX: RCX: 001a000b [ 7461.484282] RDX: 8801dccec7b8 RSI: RDI: c900063a0040 [ 7461.484282] RBP: 8802383ce780 R08: R09: 880663c0 [ 7461.484282] R10: 880098126840 R11: a000160a R12: 8802129df858 [ 7461.484282] R13: R14: 89018b4f98e8 R15: 88023b6960f0 [ 7461.484282] FS: 7f4a2c1996f0() GS:88000888() knlGS: [ 7461.484282] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [ 7461.484282] CR2: 89018b4f98e8 CR3: 01001000 CR4: 06e0 [ 7461.484282] DR0: DR1: DR2: [ 7461.484282] DR3: DR6: 0ff0 DR7: 0400 [ 7461.484282] Process md0_raid6 (pid: 29577, threadinfo 880125c48000, task 88023a5d1c40) [ 7461.484282] Stack: [ 7461.484282] 8800747e4a80 88007f686780 88023bfbd000 [ 7461.484282] 0 880098126840 a00014ec 88007f46d150 8800747e4a80 [ 7461.484282] 0 8801337c8950 88023dace200 000c [ 7461.484282] Call Trace: [ 7461.484282] [a00014ec] ? dec_pending+0x130/0x157 [dm_mod] [ 7461.484282] [a0358bed] ? handle_stripe+0xc83/0x1785 [raid456] [ 7461.484282] [a0354f0d] ? __release_stripe+0x165/0x199 [raid456] [ 7461.484282] [a0359a94] ? raid5d+0x3a5/0x3ee [raid456] [ 7461.484282] [812e5b9c] ? schedule_timeout+0x2e/0xdd [ 7461.484282] [a031f828] ? md_thread+0xf1/0x10f [md_mod] [ 7461.484282] [81064aae] ? autoremove_wake_function+0x0/0x2e [ 7461.484282] [a031f737] ? md_thread+0x0/0x10f [md_mod] [ 7461.484282] [810647e1] ? kthread+0x79/0x81 [ 7461.484282] [81011b6a] ? child_rip+0xa/0x20 [ 7461.484282] [81064768] ?
Re: Utilisation stable de l'intégralité de la ram disponible
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 89018b4f98e8 [...] Peut-être à rapprocher avec le même problème que j'ai signalé : 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 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é. 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 a469c1d84000 Aug 10 20:57:51 mach05 kernel: [40268.916126] IP: [8028166a] 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: [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 Not tainted 2.6.26-2-amd64 #1 Aug 10 20:57:51 mach05 kernel: [40268.916665] RIP: 0010:[8028166a] [8028166a] 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/201009011044.56881.al...@vaugham.com
Re: Utilisation stable de l'intégralité de la ram disponible
[ 7461.450522] BUG: unable to handle kernel paging request at 89018b4f98e8 [...] 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 moi 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 (transferts, 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 signature.asc Description: OpenPGP digital signature
Re: Utilisation stable de l'intégralité de la ram disponible
Le Wednesday 01 September 2010 11:19:24 Thibaut Chèze, vous avez écrit : [ 7461.450522] BUG: unable to handle kernel paging request at 89018b4f98e8 [...] 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 moi 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 de 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 monter 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/201009011142.11683.al...@vaugham.com
Re: Utilisation stable de l'intégralité de la ram disponible
Le mercredi 1 septembre 2010 à 09:31:51, Thibaut Chèze a écrit : 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.00] 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.00] BIOS-e820: - 0009f800 (usable) [0.00] BIOS-e820: 0010 - 7fed (usable) Tu sommes ensuites les intervalles : 0x9f800 + 0x7fed-0x10 = 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 (= annonce 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/201009011216.46065.sylvain.l.sauv...@free.fr
Re: Utilisation stable de l'intégralité de la ram disponible
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.00] 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.00] BIOS-e820: - 0009f800 (usable) [0.00] BIOS-e820: 0010 - 7fed (usable) Tu sommes ensuites les intervalles : 0x9f800 + 0x7fed-0x10 = 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 (= annonce de mauvaises plages à Linux). Personne n’a signalé de problème avec ta carte mère ? Pour ma carte mère la seul chose qui s'y rapproche c'était un post 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.00] 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] (:00:18.3). # dmesg | grep -F usable [ 0.00] BIOS-e820: - 0009b800 (usable) [ 0.00] BIOS-e820: 0010 - bbed (usable) [ 0.00] BIOS-e820: 0001 - 00024000 (usable) [ 0.00] user: - 0009b800 (usable) [ 0.00] user: 0010 - bbed (usable) [ 0.00] user: 0001 - 0001fbf0 (usable) [ 0.00] e820 update range: - 0001 (usable) == (reserved) [ 0.00] e820 update range: c000 - 0001 (usable) == (reserved) Et sans l'option mem= : # dmesg | grep -F Memory [ 0.00] 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] (:00:18.3). # dmesg | grep -F usable [ 0.00] BIOS-e820: - 0009b800 (usable) [ 0.00] BIOS-e820: 0010 - bbed (usable) [ 0.00] BIOS-e820: 0001 - 00024000 (usable) [ 0.00] e820 update range: - 0001 (usable) == (reserved) [ 0.00] e820 update range: c000 - 0001 (usable) == (reserved) Que puis-je en conclure ? Que puis-je faire pour récupérer la plage 0001fbf0 - 00024000, ou l'empêcher de la dépasser ? Merci d'avance, Thibaut signature.asc Description: OpenPGP digital signature
Re: Utilisation stable de l'intégralité de la ram disponible
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. Mais 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) 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'option , sans succès) qui me permet d'avoir 6363M d'utilisables, soit une perte 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 possibles 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 sharedbuffers cached Mem: 6868 6816 51 0103 5624 -/+ buffers/cache: 1089 5778 Swap:16383 0 16383 reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back reg01: base=0x08000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x1 ( 4096MB), size= 4096MB, count=1: write-back reg03: base=0x2 ( 8192MB), size= 1024MB, count=1: write-back reg04: base=0x0d800 ( 3456MB), size= 128MB, count=1: write-combining 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 Node0, zone DMA, typeUnmovable 2 2 3 3 3 1 0 0 1 0 0 Node0, zone DMA, type Reclaimable 0 0 0 0 0 0 0 0 0 0 0 Node0, zone DMA, type Movable 0 0 0 0 0 0 0 0 0 0 3 Node0, zone DMA, type Reserve 0 0 0 0 0 0 0 0 0 1 0 Node0, zone DMA, type Isolate 0 0 0 0 0 0 0 0 0 0 0 Node0, zoneDMA32, typeUnmovable 2979 75 4 1 0 0 0 0 0 0 0 Node0, zoneDMA32, type Reclaimable 1212 7 3 0 0 0 0 0 0 0 0 Node0, zoneDMA32, type Movable230205133 77 0 0 0 0 0 0 0 Node0, zoneDMA32, type Reserve 0 0 2 6 6 6 2 0 0 1 0 Node0, zoneDMA32, type Isolate 0 0 0 0 0 0 0 0 0 0 0 Node0, zone Normal, typeUnmovable519 0 0 0 0 0 0 0 0 0
Re: Utilisation stable de l'intégralité de la ram disponible
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 ? 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20100831202052.3c7f3...@debian1-home.aygalenq.net
