Debian Etch n'utilise pas toute la RAM malgré une bonne détection BIOS

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: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:

Code :
  1. Memory: 2046300k/4194304k available (1700k kernel code, 40944k reserved, 625k data, 212k init, 1171008k highmem)


 
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
Reply

Marsh Posté le 18-02-2009 à 16:26:39   

Reply

Marsh Posté le 18-02-2009 à 16:29:12    

cat /proc/mtrr ?

Reply

Marsh Posté le 18-02-2009 à 16:30:00    

Taz a écrit :

cat /proc/mtrr ?


 
Voici:

Code :
  1. reg00: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
  2. reg01: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
  3. reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
  4. reg03: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
  5. reg04: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
  6. reg05: base=0x170000000 (5888MB), size= 128MB: write-back, count=1
  7. reg06: base=0x178000000 (6016MB), size=  64MB: write-back, count=1
  8. reg07: base=0xaf800000 (2808MB), size=   8MB: uncachable, count=1


 

Reply

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 ?
 


---------------
Relax. Take a deep breath !
Reply

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 ?

Reply

Marsh Posté le 18-02-2009 à 17:41:10    

o'gure a écrit :

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 ?

 



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.


Message édité par Taz le 19-02-2009 à 00:32:12
Reply

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 :
  1. cat .config | grep HIGH
  2. # CONFIG_NOHIGHMEM is not set
  3. CONFIG_HIGHMEM4G=y
  4. # CONFIG_HIGHMEM64G is not set
  5. CONFIG_HIGHMEM=y
  6. # CONFIG_HIGHPTE is not set


 


Message édité par redvivi le 18-02-2009 à 17:42:39
Reply

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 :
  1. BIOS-provided physical RAM map:
  2. BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
  3. BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
  4. BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
  5. BIOS-e820: 0000000000100000 - 000000007f790000 (usable)
  6. BIOS-e820: 000000007f790000 - 000000007f79e000 (ACPI data)
  7. BIOS-e820: 000000007f79e000 - 000000007f7e0000 (ACPI NVS)
  8. BIOS-e820: 000000007f7e0000 - 000000007f800000 (reserved)
  9. BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
  10. BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
  11. BIOS-e820: 0000000100000000 - 000000017c000000 (usable)
  12. Warning only 4GB will be used.
  13. Use a PAE enabled kernel.
  14. 3200MB HIGHMEM available.
  15. 896MB LOWMEM available.
  16. found SMP MP-table at 000ff780
  17. On node 0 totalpages: 1048576
  18.   DMA zone: 4096 pages, LIFO batch:0
  19.   Normal zone: 225280 pages, LIFO batch:31
  20.   HighMem zone: 819200 pages, LIFO batch:31
  21. DMI 2.4 present.


 

Reply

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

Reply

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.


Message édité par redvivi le 18-02-2009 à 18:25:42
Reply

Marsh Posté le 18-02-2009 à 18:24:22   

Reply

Marsh Posté le 18-02-2009 à 20:12:44    

oui essaye-le voir.

Reply

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 !

Reply

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.

Reply

Marsh Posté le 18-02-2009 à 21:20:47    

Merci pour ces précisions et un grand merci encore ;-)

Reply

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.
 
Tu vois bien que :
 
# BIOS-e820: 000000007f7e0000 - 000000007f800000 (reserved) -> 128K
# BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) -> 4K  
 
ça fait un trou de 2G.


 
Taz :jap:
 
On sent le mec qui en a chier sur des becannes avec beaucoup de ram avant de passer en 64 bits [:dawa]

Reply

Marsh Posté le 18-02-2009 à 23:47:52    

Très intéressant  :jap:


---------------
Feed HA/V          
Reply

Marsh Posté le 19-02-2009 à 00:13:44    

M300A a écrit :


 
Taz :jap:
 
On sent le mec qui en a chier sur des becannes avec beaucoup de ram avant de passer en 64 bits [:dawa]


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.

Reply

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.

Message cité 1 fois
Message édité par Taz le 19-02-2009 à 00:16:21
Reply

Marsh Posté le 19-02-2009 à 05:22:03    

Taz 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.


 
[:rofl] [:bien]


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

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...


---------------
Petit guide Kerberos pour l'administrateur pressé
Reply

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-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000df686c00 (usable)
 BIOS-e820: 00000000df686c00 - 00000000df688c00 (ACPI NVS)
 BIOS-e820: 00000000df688c00 - 00000000df68ac00 (ACPI data)
 BIOS-e820: 00000000df68ac00 - 00000000e0000000 (reserved)
 BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)
 BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
 BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
2678MB HIGHMEM available.
896MB LOWMEM available.


 


calcium:~# cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 512MB: write-back, count=1
reg03: base=0xdf800000 (3576MB), size=   8MB: uncachable, count=1
reg04: base=0xdf700000 (3575MB), size=   1MB: uncachable, count=1


 
BIOS A11 (à jour)
 


calcium:~# uname -a
Linux calcium 2.6.18-6-686-bigmem #1 SMP Sat Dec 27 10:38:36 UTC 2008 i686 GNU/Linux


 
Ca me fait la même si je boot un CD d'installe Lenny amd64.
Le BIOS reconnait bien 4Go.

Reply

Marsh Posté le 26-02-2009 à 15:40:06    

Ah oui pour préciser:


calcium:~# grep HIGHMEM /boot/config-2.6.18-6-686-bigmem
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_HIGHMEM=y


 


calcium:~# grep pae /proc/cpuinfo
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm

Reply

Marsh Posté le 26-02-2009 à 16:11:54    

bah tu passe en 64b...

Reply

Marsh Posté le 26-02-2009 à 16:14:56    

tu lis ce que les gens écrivent ?


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

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 ? [:dawa]

Reply

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 ? [:dawa]


 
Et si ca le résout, tu nous payes à boire?


---------------
Petit guide Kerberos pour l'administrateur pressé
Reply

Marsh Posté le 26-02-2009 à 18:03:26    

Cf plus haut.
 
J'AI DEJA ESSAYER EN 64BITS ET CEST PAREIL

Reply

Marsh 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.


---------------
Petit guide Kerberos pour l'administrateur pressé
Reply

Marsh Posté le 26-02-2009 à 18:28:30    

Reply

Marsh Posté le 26-02-2009 à 18:32:45    


 
Ah ben entre des gens qui parlent en caps lock et d'autres la bouche pleine, on est pas rendu :/


---------------
Petit guide Kerberos pour l'administrateur pressé
Reply

Marsh Posté le 26-02-2009 à 20:37:00    

M300A a écrit :


Ca me fait la même si je boot un CD d'installe Lenny amd64.
Le BIOS reconnait bien 4Go.


 
...

Reply

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.


Message édité par Gf4x3443 le 26-02-2009 à 21:14:09

---------------
Petit guide Kerberos pour l'administrateur pressé
Reply

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.
[/fixed]

 

Ca me fait la même si je boot un CD d'installe Lenny amd64.
Le BIOS reconnait bien 4Go.


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.


Message édité par Taz le 26-02-2009 à 22:21:14
Reply

Marsh Posté le 26-02-2009 à 22:18:40    

Vite torché:

 
Code :
  1. #!/usr/bin/env perl
  2. use strict;
  3. use warnings;
  4. sub hex2meg {
  5.     hex(substr(shift, 0, -5));
  6. }
  7. my $last = 0;
  8. while (my $line = <STDIN> ) {
  9.     if ($line =~ m/([0-9a-f]+)\s-\s([0-9a-f]+)/i) {
  10.         my ($low, $hi) = map { hex2meg $_ } ($1, $2);
  11.         chomp $line;
  12.         if (($last + 1) < $low) {
  13.             printf("# hole %dM\n", $low - $last);
  14.         }
  15.         $last = $hi;
  16.         printf("%s\t[%dM; %dM[\t= %dM\n", $line, $low, $hi, $hi - $low);
  17.     } else {
  18.         print $line;
  19.     }
  20. }
  

benoit@ssh::ibook >>> bios.pl < /tmp/bios
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)        [0M; 0M[        = 0M
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)      [0M; 1M[        = 1M
 BIOS-e820: 0000000000100000 - 00000000df686c00 (usable)        [1M; 3574M[     = 3573M
 BIOS-e820: 00000000df686c00 - 00000000df688c00 (ACPI NVS)      [3574M; 3574M[  = 0M
 BIOS-e820: 00000000df688c00 - 00000000df68ac00 (ACPI data)     [3574M; 3574M[  = 0M
 BIOS-e820: 00000000df68ac00 - 00000000e0000000 (reserved)      [3574M; 3584M[  = 10M
# hole 256M
 BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)      [3840M; 3904M[  = 64M
# hole 172M
 BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)      [4076M; 4077M[  = 1M
 BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved)      [4077M; 4077M[  = 0M
 BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)      [4078M; 4079M[  = 1M
# hole 12M
 BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)      [4091M; 4096M[  = 5M
2678MB HIGHMEM available.
896MB LOWMEM available

 

Bref ton bios présente pas tout ...


Message édité par Taz le 26-02-2009 à 22:57:02
Reply

Marsh Posté le 26-02-2009 à 22:22:51    

M300A a écrit :

Ah oui pour préciser:


calcium:~# grep HIGHMEM /boot/config-2.6.18-6-686-bigmem
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_HIGHMEM=y


 


calcium:~# grep pae /proc/cpuinfo
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm



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.

Reply

Marsh Posté le 26-02-2009 à 22:39:53    

C'est quand même dingue que le BIOS réserve 400Mo :D
 
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 :cry:

Reply

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 ?


Message édité par trouble_fete le 22-05-2009 à 10:58:57

---------------
Tyan Tiger 200T, SDR PC 133, 1*256Mo, Bi-Tualatin 1,4Ghz, disque Maxtor 6Y080L0 IDE 80Go, FX 5200 en format PCI, modem/routeur DSL-524T, le tout sous Gentoo
Reply

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.

Reply

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/


---------------
Celui qui pose une question est idiot 5 minutes. Celui qui n'en pose pas le reste toute sa vie. |  Membre du grand complot pharmaceutico-médico-scientifico-judéo-maçonnique.
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed