Debian Etch n'utilise pas toute la RAM malgré une bonne détection BIOS - Hardware - Linux et OS Alternatifs
Marsh Posté le 18-02-2009 à 16:30:00
Taz a écrit : cat /proc/mtrr ? |
Voici:
Code :
|
Marsh Posté le 18-02-2009 à 16:32:47
D'où vient ton kernel linux ?
A t il été packagé par l'équipe debian, ou l'as tu compilé toi même ?
Dans le dernier cas, as tu activé l'option CONFIG_HIGHMEM ?
Marsh Posté le 18-02-2009 à 17:40:04
dans ton /var/log/messages au tout début de ton boot, tu dois avoir une ligne "BIOS-provided physical RAM map:" suivi de plusieurs lignes reserved/usable, ça donne quoi ?
Marsh Posté le 18-02-2009 à 17:41:10
o'gure a écrit : D'où vient ton kernel linux ? |
il est en HI, c'est certain vu qu'il passe les 896. C'est une histoire de mtrr, y a des trous dans les mappages mémoires. Je pense que ça va se régler par une MAJ du BIOS.
Marsh Posté le 18-02-2009 à 17:42:24
Je l'ai recompilé moi même car j'avais besoin d'y inclure des patches. Une rapide vérification me confirme que cette option est activé:
Code :
|
Marsh Posté le 18-02-2009 à 17:47:08
Taz a écrit : dans ton /var/log/messages au tout début de ton boot, tu dois avoir une ligne "BIOS-provided physical RAM map:" suivi de plusieurs lignes reserved/usable, ça donne quoi ? |
Voici ce qu'il dit:
Code :
|
Marsh Posté le 18-02-2009 à 17:58:16
# BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) -> 639K
# BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) -> 1K
# BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) -> 112K
# BIOS-e820: 0000000000100000 - 000000007f790000 (usable) -> 2038M
# BIOS-e820: 000000007f790000 - 000000007f79e000 (ACPI data) -> 56K
# BIOS-e820: 000000007f79e000 - 000000007f7e0000 (ACPI NVS) -> 4K
# BIOS-e820: 000000007f7e0000 - 000000007f800000 (reserved) -> 128K
# BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) -> 4K
# BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved) -> 5M
# BIOS-e820: 0000000100000000 - 000000017c000000 (usable) -> 1984M
Grosso merdo, t'as tes 4G de mappés. Sauf que le dernier bloc de 1984M, il démarre à l'adresse 0x0000000100000000, c'est à dire qu'il est mappé à partir du 4ème G. Du coup c'est pas utilisable
Ce que tu peux faire:
- essayer une maj de bios pour qu'il soit mappé plus bas. A cause des zones réservées, à quelques Ko près (mapping ACPI, etc), t'as tes 4G.
- essayer un HIMEM64
- passer en 64bits
Marsh Posté le 18-02-2009 à 18:24:22
J'utilise le dernier du bios, je vais recompiler le kernel en HIGHMEM64G (c'est bien celà que tu m'as conseillé Taz?) pour voir ce que celà donne.
Marsh Posté le 18-02-2009 à 20:16:40
Ok, avec le HIGHMEM64G ça passe. Visiblement le HIGHMEM4G ne fonctionne pas si tu as un total de 4GB physiquement installé et plus (l'option fonctionne probablement pour un total de RAM strictement inférieur à 4G).
Un grand merci en tout cas !
Marsh Posté le 18-02-2009 à 20:36:33
Si il fonctionne le 4G. Le problème, c'est qu'il permet d'accéder les adresses de 0 à 4G. Sauf que si comme dans ton cas, une partie de ta mémoire est mappée sur des adresses supérieures, ben ça le fait pas. C'est un peu le problème de pas mal de BIOS qui ont tendance à reléguer au delà du 4G pour des histoires de compatiblités.
Tu vois bien que :
# BIOS-e820: 000000007f7e0000 - 000000007f800000 (reserved) -> 128K
# BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) -> 4K
ça fait un trou de 2G.
Marsh Posté le 18-02-2009 à 21:34:14
Taz a écrit : Si il fonctionne le 4G. Le problème, c'est qu'il permet d'accéder les adresses de 0 à 4G. Sauf que si comme dans ton cas, une partie de ta mémoire est mappée sur des adresses supérieures, ben ça le fait pas. C'est un peu le problème de pas mal de BIOS qui ont tendance à reléguer au delà du 4G pour des histoires de compatiblités. |
Taz
On sent le mec qui en a chier sur des becannes avec beaucoup de ram avant de passer en 64 bits
Marsh Posté le 19-02-2009 à 00:13:44
M300A a écrit : |
Même pas. Un jour j'ai du faire un inventaire, j'ai sorti les quantités de mémoires disponibles sur des serveurs (64bits). Et là il a fallu expliquer au chef grincheux pourquoi sur les serveurs il avait pas exactement 32G parce que y avait des zones réservées de quelques mégas (mais des fois plusieurs dizaines) dans le tas. Ca et le fait que la mémoire pour l'image du noyau n'est pas disponible (le "kernel code" ). Au final j'ai creusé un peu et j'ai fini par faire des jolis arrondis pour que la feuille excel de l'autre soit jolie.
Marsh Posté le 19-02-2009 à 00:15:12
Le truc qu'il faut creuser maintenant, c'est la différence d'implémentation entre le 4G et le 64G (j'imagine un niveau d'indirection supplémentaire) pour en connaître le coup.
Savoir si on paye le prix du 64G même sur les 4G premiers. Et conclure alors pourquoi les distributions n'activent pas carrément le 64G d'office aujourd'hui.
Marsh Posté le 19-02-2009 à 05:22:03
Taz a écrit : |
Marsh Posté le 19-02-2009 à 15:32:55
Taz a écrit : Savoir si on paye le prix du 64G même sur les 4G premiers. Et conclure alors pourquoi les distributions n'activent pas carrément le 64G d'office aujourd'hui. |
- instabilité, surtout que la tendance est plutot de se tourner vers le 64 bits ou PAE. Il faut pouvoir remapper comme KVA dans Linux des adresses qui sont sur 36 bits (et plus 32).
- performance, HIGHMEM64 a besoin d'opération arithmétiques 64 bits atomiques, qui sont lourdes (il faut un compxch atomique sur 64 bits sous archi 32 bits, par exemple). Remercier l'architecture x86 pour son élégance...
Marsh Posté le 26-02-2009 à 15:31:33
Je rebondis sur ce problème car je l'ai aussi actuellement sur un Optiplex GX520.
2x 2Go de RAM installé seulement 3.6 utilisable.
|
|
BIOS A11 (à jour)
|
Ca me fait la même si je boot un CD d'installe Lenny amd64.
Le BIOS reconnait bien 4Go.
Marsh Posté le 26-02-2009 à 15:40:06
Ah oui pour préciser:
|
|
Marsh Posté le 26-02-2009 à 16:14:56
tu lis ce que les gens écrivent ?
Marsh Posté le 26-02-2009 à 16:21:46
J'ai ma netinstall lenny64 devant les yeux pour faire la fête à ce serveur vmware en etch32. Ca me démange mais comment je vais justifier ça si ça résout pas le problème ?
Marsh Posté le 26-02-2009 à 17:55:33
M300A a écrit : Ca me démange mais comment je vais justifier ça si ça résout pas le problème ? |
Et si ca le résout, tu nous payes à boire?
Marsh Posté le 26-02-2009 à 18:03:26
ReplyMarsh Posté le 26-02-2009 à 18:25:23
M300A a écrit : J'AI DEJA ESSAYER EN 64BITS ET CEST PAREIL |
ON PARLE DE LA BIDOUILLE BIEN LINUXIENNE QU'EST HIGHMEM OU D'UN VRAI SUPPORT 64BITS DANS LA MMU?
PARCE QUE CA A PAS L'AIR BIEN CLAIR POUR TOI LA DIFFERENCE.
Marsh Posté le 26-02-2009 à 18:32:45
Modération a écrit : hmmm hmmm |
Ah ben entre des gens qui parlent en caps lock et d'autres la bouche pleine, on est pas rendu
Marsh Posté le 26-02-2009 à 20:37:00
M300A a écrit : |
...
Marsh Posté le 26-02-2009 à 21:04:44
Je doute bien de la chose, déjà, impossible que les mappings correspondent.
Ta situation est "normale" sur x86_32 (les Mo qui manquent doivent venir de l'adressage reservé pour les bus PCI/PCI-e), et sous x86_64, well, tu ne donnes rien du tout, donc...
Le PAE ne t'aidera pas non plus, vu que c'est un contournement pour adresser sur 36 bits physique au lieu de 32, mais l'adressage (de la VM) reste en 32 bits.
Si tu veux grapiller un peu, tu peux toujours réduire l'aperture offert pour le bus AGP (si ton BIOS le supporte, et si ta carte graphique est sur un port AGP - mais je ne pense pas).
Edit: ou tu peux retirer des cartes PCI, ca fera moins d'espace mangé pour les MMIO.
Marsh Posté le 26-02-2009 à 21:56:48
M300A a écrit : Je rebondis sur ce problème car je l'ai aussi actuellement sur un Optiplex GX520. Ca me fait la même si je boot un CD d'installe Lenny amd64. |
Bah ça correspond exactement à ce que le noyau te dit au démarrage. Ton BIOS voit ce qu'il veut, sauf qu'il réserve tout sauf c'est 3.6Go. Pour 400Mo, c'est pas le peine de se prendre la tête je pense.
Marsh Posté le 26-02-2009 à 22:18:40
Vite torché:
Code :
|
benoit@ssh::ibook >>> bios.pl < /tmp/bios |
Bref ton bios présente pas tout ...
Marsh Posté le 26-02-2009 à 22:22:51
M300A a écrit : Ah oui pour préciser:
|
Toi dans ton cas ça a a aidé, parce qu'on voit que ton BIOS map des trucs au delà du 4ème giga. Ici, non justement, on ne voit rien au delà. Y a rien à récupérer.
Marsh Posté le 26-02-2009 à 22:39:53
C'est quand même dingue que le BIOS réserve 400Mo
Enfin bon, j'ai deja fais pas mal de vérif d'usage et il semble bien que je sois bloqué la dessus...
Tant pis pour mes 400Mo
Marsh Posté le 22-05-2009 à 10:58:46
Peut-être y a t-il une maj de BIOS qui résout le problème ?
Marsh Posté le 22-05-2009 à 12:05:39
Si le chipset est un peu ancien, il est possible qu'il soit matériellement incapable de maper plus de 4Go.
Marsh Posté le 13-07-2009 à 21:17:51
un lien rapide sur le même sujet :
http://www.codemonkey.org.uk/2009/ [...] e-gotchas/
Marsh Posté le 18-02-2009 à 16:26:39
Bonjour à tous !
J'utilise une Debian Etch 2.6.18 sur une carte mère Asus P5B-VM avec 2*2GB de RAM Corsair (choisie à l'aide du sélecteur Corsair). Au début, le BIOS ne détectait que 2808 MB de RAM, j'ai donc activé l'option memory remapping dans le BIOS. Maintenant, les 4GB sont affichés correctement dans le BIOS. Par contre, lorsque je controle ma RAM dans linux à l'aide de free, le système n'utilise que 2GB
Voici le message que j'ai dans mon dmesg:
Que dois-je faire pour utiliser la totalité de la RAM ?
Merci d'avance !
RedVivi
Message édité par redvivi le 18-02-2009 à 21:20:55