Linux de 64 bits no reconoce mi RAM entre 3 y 32 GB

8

Mis problemas fueron causados ​​por un módulo de memoria defectuoso y posiblemente un binario roto del núcleo.

Acabo de arrancar mi PC con hardware básicamente nuevo. He estado ejecutando Debian 6.0 AMD64 antes, y no hay cambios allí (literalmente; simplemente desconecté los discos duros de la placa base anterior y los volví a conectar a la nueva), pero encontré algo curioso:

  • Instalé físicamente 4 x 8 GB de RAM
  • La configuración de UEFI / BIOS informa 16383 MB de RAM
  • Linux free -mreporta 2985 MB de RAM

2985 MB parece demasiado cerca de la marca mágica de 3 GB para que sea pura coincidencia, pero se uname -rimprime 2.6.32-5-amd64; claramente un núcleo de 64 bits, que es todo lo que se ha instalado en la unidad del sistema que estoy usando. La nueva placa base es una Asus M5A97 Pro, que tiene cuatro ranuras DDR3 supuestamente compatibles con módulos de 8 GB. Los módulos de memoria en sí son idénticos, cuatro Corsair XMS3 PC12800 de 8 GB, comprados juntos.

No he examinado la configuración de UEFI en detalle, pero la examiné y no vi nada que pareciera que fuera necesario cambiar para habilitar grandes cantidades de RAM.

Editar: Confirmación adicional de que realmente estoy ejecutando 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
#

¿Qué pasa con esto y qué puedo hacer al respecto?

Edición 2: dmesg, dmidecode y meminfo, según lo solicitado. No tengo acceso físico al sistema en este momento, por lo que tendré que esperar hasta esta noche para extraer algunos módulos y ver qué hace. (Tenga en cuenta que dmidecode informa 3 x 8GB más una ranura DIMM vacía. También tenga en cuenta el mensaje de falta de coincidencia MTRR del kernel, lo que lleva a una pérdida de 13 GB, que al menos se suma a lo que informa la placa base).

# 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 para e820 muestra un montón de rangos, completando e820 update range: 00000000bdf00000 - 000000043f000000 (usable) ==> (reserved). 43f000000 es 16 GiB, bdf00000 es 3039 MiB. Yo no veo que el ser coincidencia.

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

EDITAR 3/4 - éxito parcial:

  • La actualización del UEFI BIOS de la versión 0705 x64 08/23/2011a 1007 02/10/2012no ayudó: el mismo problema persistió.
  • La eliminación de un módulo DIMM (supuse con suerte qué ranura era la número 4: la más alejada de la CPU) permitió que el BIOS detectara y usara los 24 GB restantes, aunque una configuración de tres DIMM no es "recomendada" según el diagrama en el manual del usuario. Notablemente, asentar uno de los DIMM restantes en la ranura # 4 todavía permitió su uso, por lo que la ranura está bien. Volver a colocar el DIMM "original" en esa ranura me dejó en mi punto de partida.
  • Arrancar desde el CD de instalación de Debian 6.0.3 AMD64 en un entorno de rescate y comprobar su dmesgsalida no muestra errores MTRR similares . Además, en ese entorno, con 3 x 8 GB instalados, 24 GB (más o menos épsilon veces pi o por ahí; no hice los cálculos exactos) se muestran como utilizables según free.
  • La actualización / reinstalación del kernel (hubo una actualización menor disponible) parece haber solucionado también los problemas de MTRR. dmesgahora informa un total de 26198016 KB y no hay errores de MTRR, lo que está en línea con lo que esperaría con 3 x 8GB instalados. free -mahora informa 24114 MB de RAM total, que francamente es lo suficientemente cerca para mí.

Esto huele a un DIMM con púas, más un kernel que por cualquier razón se dañó; eso último puede haber sucedido durante el corte de energía (¡aunque debo decir que es una forma extraña de que el núcleo se rompa!). El DIMM que no funciona volverá al distribuidor tan pronto como hable con ellos (espero que mañana).

(con suerte) EDICIÓN FINAL

Realicé un RMA en uno de los dos pares de DIMM, el revendedor lo aceptó como dañado y me enviaron un nuevo par, que parece funcionar bien. Por lo tanto, ahora estoy básicamente en el lugar donde originalmente pretendía hace casi un mes (aunque una gran parte de ese tiempo no se debió realmente al revendedor), con 32 GB de RAM utilizable; free -minforma 32194 MB de memoria total, y el núcleo informa 34586624kRAM en la inicialización, los cuales están en línea con mis expectativas.

linux 64bit ram un CVn
fuente
2
Desde su primera declaración, ¿parece que movió discos duros con un sistema operativo instalado a una nueva placa del sistema? Una prueba realmente buena sería descargar una distribución en vivo e iniciarla. Slax, DSL, Ubuntu o lo que sea. Si eso reconoce la cantidad correcta de RAM, es probable que encuentre problemas de HAL / udev. En ese momento, ahorrará mucho más tiempo haciendo copias de seguridad y reinstalando que intentando solucionarlo. A menos que seas un geek como yo y quieras perder horas o días en eso:}
2bc
2
Publique la salida de dmidecode --type memoryy las primeras cien líneas más o menos de la salida de dmesg(asegúrese de incluir cualquier cosa que parezca que se trata de memoria).
Gilles 'SO- deja de ser malvado'
1
WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 13295MB of RAM.Bueno, ahí está tu 13G perdido.
Mat
1
@ Mat, no el otro 16G faltante, sin embargo. Es probable que tome un poco más buscando.
un CVn
1
Me interesaría lo que diría un arranque Debian live (/ ubuntu, ya que es lo próximo más cercano), ya que puede usarse para distinguir fácilmente entre problemas con su hardware y problemas con su configuración.
dtech 22/03/12

Respuestas:

14

Primero, si su BIOS / UEFI no detecta correctamente su RAM, entonces su sistema operativo no lo hará mejor. No es necesario ir más allá si su BIOS muestra información incorrecta sobre su configuración.

=> Probablemente tenga al menos un problema de hardware.

EDITAR : desde tu dmesg | grep memory, parece que de hecho tiene un problema de hardware, ubicado en su BIOS incrustado. Al menos, Linux ha detectado y le avisa de ello: WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 13295MB of RAM. También parece que uno de sus módulos de 4 ram es incorrectamente reconocido o insertado.

Puede informarlo a su fabricante, actualizar su BIOS y cambiar su placa base. Hay muchas posibilidades de que con menos RAM, no encuentre este error.

Como nota al margen, puede estar de acuerdo con esta famosa cita de Linus Torvalds sobre los fabricantes de BIOS :

Los escritores de BIOS son invariablemente monos totalmente incompetentes adictos al crack

En segundo lugar, cuando su BIOS está bien con lo que realmente tiene en su placa base, puede echar un vistazo a Linux en /proc/meminfo. A menudo es muy claro lo que su sistema Linux sabe y hace con su memoria. Esto es lo que tengo en mi 64bit / 8 Gb de RAM:

$ cat /proc/meminfo 
MemTotal:        8175652 kB
MemFree:         5476336 kB
Buffers:           63924 kB
Cached:          1943460 kB
SwapCached:            0 kB
[...]

Sobre el proceso de arranque y lo que utiliza / libera el kernel de Linux, puede obtenerlo de dmesg:

$ dmesg | grep Memory
[    0.000000] Memory: 8157672k/8904704k available (6138k kernel code, 534168k absent, 212864k reserved, 6896k data, 988k init)

EDITAR : como dijo Gilles, con dmidecode --type memory, puede tener detalles sobre la configuración de su hardware. Se ve así para un sistema de 4x2Gb:

$ sudo dmidecode --type memory
# dmidecode 2.9
SMBIOS 2.6 present.

Handle 0x0020, DMI type 16, 15 bytes
Physical Memory Array
    Location: System Board Or Motherboard
    Use: System Memory
    Error Correction Type: None
    Maximum Capacity: 32 GB
    Error Information Handle: Not Provided
    Number Of Devices: 4

Handle 0x0022, DMI type 17, 28 bytes
Memory Device
    Array Handle: 0x0020
    Error Information Handle: Not Provided
    Total Width: 64 bits
    Data Width: 64 bits
    Size: 2048 MB
    [...]
[This block is repeated for each module]
Coren
fuente
5

Busque / var / log / dmesg para el mapa de memoria (grep para 'e820') y cuente cuánta memoria se reporta allí como utilizable. Esto es lo que el BIOS le dice al sistema operativo cargado para la memoria.

(Esto es correcto solo para el arranque de estilo antiguo. No sé cómo se informa la memoria si se usa el arranque de estilo EFI, pero supongo que hay un informe similar).

Además, informar 16 GB por BIOS mientras 32 GB está instalado significa algo extraño en la configuración de la memoria. Intente reducir la memoria instalada a 4 u 8 GB y compare los efectos.

Netch
fuente
Vea mi edición para los datos de e820. Quitar físicamente los módulos de memoria para ver qué debe hacer tendrá que esperar hasta esta noche. Los únicos módulos DDR3 que tengo son de 8 GB cada uno.
un CVn
Bueno, parece que es suficiente ahora: tienes hardware y software funcionando correctamente. La última acción es instalar el módulo de memoria correcto para llenarlo y hacer que funcione el doble canal. Felicidades.
Netch
0

Muchas placas AMD antiguas pueden tener 4 ranuras, pero si llena la última ranura, está buscando problemas. Es un problema de chipset que no se puede solucionar.

Almiar
fuente
No consideraría exactamente el Asus M5A97 Pro como una placa madre "más antigua" (no sé su fecha exacta de fabricación, pero se basa en el chipset AMD 970, y Wikipedia pone la serie 900 en una fecha de lanzamiento de junio de 2011, menos un año antes de que esta pregunta estuviera vigente en marzo de 2012). Y la ejecución desde los medios de instalación mostró una imagen bastante diferente de la realidad desde el punto de vista del sistema operativo. Y los problemas finalmente se resolvieron reemplazando el módulo de memoria defectuoso por uno que funcionaba y reinstalando el kernel (como dice justo en la parte superior de la pregunta).
un CVn