Mes problèmes ont été causés par un module de mémoire défectueux et très probablement un binaire du noyau cassé.
Je viens de démarrer mon PC avec du matériel essentiellement nouveau. J'ai déjà utilisé Debian 6.0 AMD64, et aucun changement (littéralement; je viens de débrancher les disques durs de l'ancienne carte mère et de les reconnecter à la nouvelle), mais j'ai trouvé quelque chose de curieux:
- J'ai installé physiquement 4 x 8 Go de RAM
- La configuration UEFI / BIOS signale 16383 Mo de RAM
- Linux
free -m
rapporte 2985 Mo de RAM
2985 Mo semble trop proche de la marque magique de 3 Go pour que ce soit purement une coïncidence, mais uname -r
s'imprime 2.6.32-5-amd64
; clairement un noyau 64 bits, qui est tout ce qui a jamais été installé sur le lecteur système que j'utilise. La nouvelle carte mère est un Asus M5A97 Pro, qui dispose de quatre emplacements DDR3 censés supporter des modules de 8 Go. Les modules de mémoire eux-mêmes sont identiques, quatre Corsair XMS3 PC12800 8 Go, achetés ensemble.
Je n'ai pas regardé la configuration UEFI en détail, mais je l'ai parcourue et je n'ai vu rien qui semblait devoir être modifié pour activer de grandes quantités de RAM.
Edit: confirmation supplémentaire que je suis vraiment en 64 bits:
# file `which free`
/usr/bin/free: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
#
Que se passe-t-il et que puis-je faire?
Édition 2: dmesg, dmidecode et meminfo, comme demandé. Je n'ai pas d'accès physique au système pour le moment, je devrai donc attendre ce soir pour retirer certains modules et voir ce que cela fait. (Notez que dmidecode rapporte 3 x 8 Go plus un emplacement DIMM vide. Notez également le message de non-concordance MTRR du noyau, entraînant une perte de 13 Go, ce qui correspond au moins à ce que la carte mère elle-même rapporte.)
# dmidecode --type memory
# dmidecode 2.9
SMBIOS 2.7 present.
Handle 0x0026, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Multi-bit ECC
Maximum Capacity: 32 GB
Error Information Handle: Not Provided
Number Of Devices: 4
Handle 0x0028, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x0026
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: DIMM0
Bank Locator: BANK0
Type: <OUT OF SPEC>
Type Detail: Synchronous
Speed: 1333 MHz (0.8 ns)
Manufacturer: Manufacturer0
Serial Number: SerNum0
Asset Tag: AssetTagNum0
Part Number: Array1_PartNumber0
Handle 0x002A, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x0026
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: DIMM1
Bank Locator: BANK1
Type: <OUT OF SPEC>
Type Detail: Synchronous
Speed: 1333 MHz (0.8 ns)
Manufacturer: Manufacturer1
Serial Number: SerNum1
Asset Tag: AssetTagNum1
Part Number: Array1_PartNumber1
Handle 0x002C, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x0026
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: DIMM2
Bank Locator: BANK2
Type: <OUT OF SPEC>
Type Detail: Synchronous
Speed: 1333 MHz (0.8 ns)
Manufacturer: Manufacturer2
Serial Number: SerNum2
Asset Tag: AssetTagNum2
Part Number: Array1_PartNumber2
Handle 0x002E, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x0026
Error Information Handle: Not Provided
Total Width: Unknown
Data Width: 64 bits
Size: No Module Installed
Form Factor: DIMM
Set: None
Locator: DIMM3
Bank Locator: BANK3
Type: Unknown
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Manufacturer3
Serial Number: SerNum3
Asset Tag: AssetTagNum3
Part Number: Array1_PartNumber3
#
======================================================================
# cat /proc/meminfo
MemTotal: 3056820 kB
MemFree: 1470820 kB
Buffers: 390204 kB
Cached: 194660 kB
SwapCached: 0 kB
Active: 488024 kB
Inactive: 419096 kB
Active(anon): 231112 kB
Inactive(anon): 96660 kB
Active(file): 256912 kB
Inactive(file): 322436 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 8 kB
Writeback: 0 kB
AnonPages: 322320 kB
Mapped: 33012 kB
Shmem: 5472 kB
Slab: 613952 kB
SReclaimable: 597404 kB
SUnreclaim: 16548 kB
KernelStack: 2384 kB
PageTables: 19472 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1528408 kB
Committed_AS: 621464 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 294484 kB
VmallocChunk: 34359429080 kB
HardwareCorrupted: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 9216 kB
DirectMap2M: 2054144 kB
DirectMap1G: 1048576 kB
#
======================================================================
# dmesg | grep -i memory
[ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 13295MB of RAM.
[ 0.000000] WARNING: at /tmp/buildd/linux-2.6-2.6.32/debian/build/source_amd64_none/arch/x86/kernel/cpu/mtrr/cleanup.c:1092 mtrr_trim_uncached_memory+0x2e6/0x311()
[ 0.000000] [<ffffffff814f7f1e>] ? mtrr_trim_uncached_memory+0x2e6/0x311
[ 0.000000] [<ffffffff814f7f1e>] ? mtrr_trim_uncached_memory+0x2e6/0x311
[ 0.000000] [<ffffffff814f7f1e>] ? mtrr_trim_uncached_memory+0x2e6/0x311
[ 0.000000] initial memory mapped : 0 - 20000000
[ 0.000000] init_memory_mapping: 0000000000000000-00000000bdf00000
[ 0.000000] PM: Registered nosave memory: 000000000009d000 - 000000000009e000
[ 0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[ 0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
[ 0.000000] PM: Registered nosave memory: 00000000bd94d000 - 00000000bd99c000
[ 0.000000] PM: Registered nosave memory: 00000000bd99c000 - 00000000bd9a6000
[ 0.000000] PM: Registered nosave memory: 00000000bd9a6000 - 00000000bdade000
[ 0.000000] PM: Registered nosave memory: 00000000bdade000 - 00000000bdaef000
[ 0.000000] PM: Registered nosave memory: 00000000bdaef000 - 00000000bdb02000
[ 0.000000] PM: Registered nosave memory: 00000000bdb02000 - 00000000bdb04000
[ 0.000000] PM: Registered nosave memory: 00000000bdb04000 - 00000000bdb0d000
[ 0.000000] PM: Registered nosave memory: 00000000bdb0d000 - 00000000bdb13000
[ 0.000000] PM: Registered nosave memory: 00000000bdb13000 - 00000000bdb75000
[ 0.000000] PM: Registered nosave memory: 00000000bdb75000 - 00000000bdd78000
[ 0.000000] Memory: 3046732k/3111936k available (3075k kernel code, 4728k absent, 60476k reserved, 1879k data, 584k init)
[ 1.636730] Freeing initrd memory: 9501k freed
[ 1.647370] Freeing unused kernel memory: 584k freed
[ 4.876602] [TTM] Zone kernel: Available graphics memory: 1528410 kiB.
[ 4.876615] [drm] radeon: 256M of VRAM memory ready
[ 4.876617] [drm] radeon: 512M of GTT memory ready.
[ 25.571018] VBoxDrv: dbg - g_abExecMemory=ffffffffa051d6c0
#
Grepping pour e820 montre un tas de gammes, complétant avec e820 update range: 00000000bdf00000 - 000000043f000000 (usable) ==> (reserved)
. 43f000000 est de 16 Gio, bdf00000 est de 3039 Mio. Je ne vois pas cela comme une coïncidence.
# dmesg | grep -i e820
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009d800 (usable)
[ 0.000000] BIOS-e820: 000000000009d800 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000bd94d000 (usable)
[ 0.000000] BIOS-e820: 00000000bd94d000 - 00000000bd99c000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bd99c000 - 00000000bd9a6000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000bd9a6000 - 00000000bdade000 (reserved)
[ 0.000000] BIOS-e820: 00000000bdade000 - 00000000bdaef000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bdaef000 - 00000000bdb02000 (reserved)
[ 0.000000] BIOS-e820: 00000000bdb02000 - 00000000bdb04000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bdb04000 - 00000000bdb0d000 (reserved)
[ 0.000000] BIOS-e820: 00000000bdb0d000 - 00000000bdb13000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bdb13000 - 00000000bdb75000 (reserved)
[ 0.000000] BIOS-e820: 00000000bdb75000 - 00000000bdd78000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000bdd78000 - 00000000bdf00000 (usable)
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec10000 - 00000000fec11000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec20000 - 00000000fec21000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed01000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed61000 - 00000000fed71000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed80000 - 00000000fed90000 (reserved)
[ 0.000000] BIOS-e820: 00000000fef00000 - 0000000100000000 (reserved)
[ 0.000000] BIOS-e820: 0000000100001000 - 000000043f000000 (usable)
[ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[ 0.000000] e820 update range: 00000000bdf00000 - 000000043f000000 (usable) ==> (reserved)
[ 0.000000] update e820 for mtrr
#
EDIT 3/4 - succès partiel:
- La mise à niveau du BIOS UEFI de la version
0705 x64 08/23/2011
vers1007 02/10/2012
n'a pas aidé: le même problème persiste. - La suppression d'un module DIMM (j'ai eu la chance de savoir quel emplacement était n ° 4: celui le plus éloigné du CPU) a permis au BIOS de détecter et d'utiliser les 24 Go restants, bien qu'une configuration à trois DIMM ne soit pas "recommandée" selon le schéma dans le manuel de l'utilisateur. Notamment, le fait de placer l'un des barrettes DIMM restantes dans l'emplacement n ° 4 permettait toujours de l'utiliser, donc l'emplacement est correct. La réinstallation de la barrette DIMM "d'origine" dans cet emplacement m'a fait revenir à mon point de départ.
- Amorcer à partir du CD d'installation Debian 6.0.3 AMD64 dans un environnement de secours et vérifier sa
dmesg
sortie ne montre aucune erreur MTRR similaire . De plus, dans cet environnement, avec 3 x 8 Go installés, 24 Go (plus ou moins epsilon fois pi ou environ; je n'ai pas fait le calcul exact) apparaît comme utilisable selonfree
. - La mise à niveau / réinstallation du noyau (une mise à niveau mineure était disponible) semble également avoir résolu les problèmes MTRR.
dmesg
rapporte maintenant 26198016 Ko au total et aucune erreur MTRR, ce qui correspond à ce que j'attendrais avec 3 x 8 Go installés.free -m
rapporte maintenant 24114 Mo de RAM totale, ce qui est franchement assez proche pour moi.
Cela sent comme un module DIMM barfed, plus un noyau qui, pour une raison quelconque, a été endommagé; ce dernier s'est peut- être produit lors de la panne de courant (même si je dois dire que c'est une façon étrange pour le noyau de se casser!). Le module DIMM non fonctionnel retournera chez le revendeur dès que je leur parlerai (avec un peu de chance demain).
(j'espère) FINAL EDIT
J'ai RMA l'une des deux paires de modules DIMM, elle a été acceptée par le revendeur comme étant endommagée et ils m'ont envoyé une nouvelle paire, qui semble fonctionner très bien. Je suis donc maintenant à peu près là où je l'avais prévu il y a près d'un mois (bien qu'une grande partie de ce temps ne soit pas vraiment due au revendeur), avec 32 Go de RAM utilisable; free -m
rapporte 32194 Mo de mémoire totale, et le noyau signale la 34586624k
RAM à l'initialisation, les deux étant bien en ligne avec mes attentes.
dmidecode --type memory
et les cent premières lignes environ de la sortie dedmesg
(assurez-vous d'inclure tout ce qui ressemble à de la mémoire).WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 13295MB of RAM.
Eh bien, il y a votre 13G manquant.Réponses:
Premièrement, si votre BIOS / UEFI ne détecte pas correctement votre RAM, votre système d'exploitation ne fera pas mieux. Il n'est pas nécessaire d'aller plus loin si votre BIOS affiche des informations incorrectes sur votre configuration.
=> Vous avez probablement au moins un problème matériel.
EDIT : De votre dmesg | grep memory, il semble que vous ayez en fait un problème matériel, localisé dans votre bios embarqué. Au moins, Linux a détecté et vous avertit à ce sujet:
WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 13295MB of RAM
. Il semble également que l'un de vos 4 modules RAM soit incorrectement reconnu ou inséré.Vous pouvez soit le signaler à votre fabricant, mettre à jour votre bios et changer votre carte mère. Il y a de nombreuses chances qu'avec moins de RAM, vous ne rencontriez pas ce bug.
En remarque, vous pouvez être d'accord avec cette célèbre citation de Linus Torvalds sur les fabricants de BIOS :
Deuxièmement, lorsque votre BIOS est OK avec ce que vous avez vraiment sur votre carte mère, vous pouvez jeter un œil sur Linux
/proc/meminfo
. Il est souvent très clair sur ce que votre système Linux sait et fait avec votre mémoire. Voici ce que j'ai sur mon 64bit / 8 Go de RAM:À propos du processus de démarrage et de ce qui est utilisé / libéré par le noyau Linux, vous pouvez le récupérer à partir de
dmesg
:EDIT : Comme Gilles l'a dit, avec
dmidecode --type memory
, vous pouvez avoir des détails sur votre configuration matérielle. Il ressemble à ceci pour un système 4x2Gb:la source
Recherchez / var / log / dmesg pour la carte mémoire (grep pour 'e820') et comptez combien de mémoire y est signalée comme utilisable. C'est ce que le BIOS dit au système d'exploitation chargé pour la mémoire.
(Ceci est correct uniquement pour un démarrage de style ancien. Je ne sais pas comment la mémoire est signalée si un démarrage de style EFI est utilisé, mais je suppose qu'il existe un rapport similaire.)
En outre, signaler 16 Go par BIOS alors que 32 Go est installé signifie une certaine bizarrerie dans la configuration de la mémoire. Essayez de réduire la mémoire installée à 4 ou 8 Go et comparez les effets.
la source
De nombreuses cartes AMD plus anciennes peuvent avoir 4 emplacements, mais si vous remplissez le dernier emplacement, vous posez des problèmes. C'est un problème de chipset qui ne peut pas être résolu.
la source