Lo hice y lo entendí

Mi ordenador principal, que acaba de cumplir 4 años, lleva una placa Asus A8N-SLI Deluxe (socket 939, chipset NForce4 SLI), un AMD Athlon64 X2 4600+ (era 3500+ y lo actualicé), una GForce 6600 de 256 MiB y 2 GiB de RAM Kingston DDR400 PC3200 CL3. Es el mismo ordenador con dos discos en RAID 0 al que le instalé Ubuntu Hardy Heron en Abril.

Pues bien, la semana pasada le compré otros dos módulos Kingston de 1 GiB exactamente iguales que los originales para ampliar la memoria a un total de 4 GiB. La memoria es de una marca y modelo oficialmente soportados por esta placa base.

Yo ya sabía que algo que en teoría debería de ser pinchar & listo (plug & play) a menudo causa problemas, ya que, ¿cuántas veces no nos hemos encontrado con memorias de las que la placa sólo reconocía la mitad? ¿o que colgaban el ordenador a la primera de cambio? ¿o que nos obligaba a bajar la velocidad del bus o los parámetros de memoria en los parámetros de la BIOS? En este caso, no ha sido menos, ya que la dichosa ampliación de memoria me ha tenido un buen número de horas en vilo de saber si algún día podría usar esos 4 GiB de RAM en mi sistema.

Tras pinchar la memoria me encontré la primera cosa extraña: La BIOS había bajado la velocidad de la memoria de 400 MHz a 333 MHz. La verdad es que algo así ya me lo esperaba, ya que precisamente uno de las preguntas de las FAQ de la A8N-SLI es, precisamente:

Why does the memory run at 333MHz if I use four DDR400 512MB/256MB memory modules on A8N-SLI?

To be more compatible and stable with some memory modules, the default clock will be at 333MHz if four DDR400 memory modules are plugged on the A8N-SLI. But you still can set at 400MHz manually in the Bios to gain better performance. Moreover, in order to get best performance and compatibility, please choose those memory modules which are verified by us. You can get the QVL from the link below:

http://www.asus.com/products.aspx?l1=3&l2=15&l3=148&model=375&modelmenu=1

Así que entré en la BIOS, puse la configuración de la memoria en Manual, seleccioné la velocidad de 400 MHz y… el ordenador se colgaba instantes después del comienzo del arranque de cualquier sistema operativo. Y es que al poner la configuración manual de la memoria, los otros parámetros de la memoria como CAS# latency, RAS# to CAS# delay, Min RAS# active time o Row Precharge Time dejaban de configurarse automáticamente, así que tuve que volver a poner la memoria en Auto / 333 MHz y entrar en Linux para ver los parámetros de los DIMMs usando el decode-dimm.pl.

El decode-dimm.pl es un script del proyecto lm-sensors que permite leer los parámetros de los módulos DIMM que tenemos instalados por SPD. Era parte de lm-sensors 2, pero en lm-sensors 3 no está, así que como ésta última es la versión que trae Ubuntu 8.04, no lo tendremos en nuestro sistema tras instalar el lm-sensors. Para obtener el script, por tanto, tenemos que bajarnos el .tar.gz de la última versión 2.X de lm-sensors, y en él encontraremos el script.

Para usarlo, el único prerequisito es cargar el módulo eeprom y ya está:

$ sudo modprobe eeprom
$ ./decode-dimms.pl

Memory Serial Presence Detect Decoder
By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner,
Jean Delvare and others
Version 2.10.1

Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/0-0050
Guessing DIMM is in                             bank 1 

[...]
---=== Memory Characteristics ===---
Maximum module speed                            400MHz (PC3200)
Size                                            1024 MB
tCL-tRCD-tRP-tRAS                               3-3-3-8
Supported CAS Latencies                         3, 2.5, 2
Supported CS Latencies                          0
Supported WE Latencies                          1
Minimum Cycle Time (CAS 3)                      5 ns
Maximum Access Time (CAS 3)                     0.7 ns
Minimum Cycle Time (CAS 2.5)                    6 ns
Maximum Access Time (CAS 2.5)                   0.7 ns
Minimum Cycle Time (CAS 2)                      7.5 ns
Maximum Access Time (CAS 2)                     0.75 ns
[...]

Hace un tiempo, en una de las entradas de la VIA EPIA ya puse una salida del decode-dimms.pl completa, que podemos consultar como ejemplo adicional.

Asimismo, en Windows podemos usar el CPU-Z para obtener la información SPD de la memoria de nuestro sistema.

Usando estos datos en la BIOS, ya no ha habido ningún problema con la velocidad de la memoria o con sus parámetros.

También en ese mismo apartado de la BIOS, el de la configuración de la DRAM, tengo otros dos parámetros para habilitar el remapping de la memoria por software o por hardware: “S/W DRAM Over 4G Remapping” y “H/W DRAM Over 4G Remapping“. Estas opciones no están descritas en el manual de la placa base, porque se introdujeron en revisiones posteriores de la BIOS, pero son de vital importancia para ampliar la memoria de un sistema por encima de 3 GiB.

En las FAQ de la placa leemos incluso una explicación de las diferencias entre ambos parámetros:

I often find hardware and software re-mapping (or sometimes called memory hole) in BIOS options for detecting 4GB or more memory installed on my system. However, there is no explanation about the differences between them. Can ASUS kindly help explaining them?

Below are the differences between these two types of memory re-remapping technuqie:

Hardware re-map:
Done through addressing lines, which re-maps memory above a particular memory address to spaces above 4GB. The main advantage is the fact that it is capable of re-mapping a small amount of memory space at a time, which makes memory usage much more flexible. Hardware support required to enable this option.

Software re-map:
Done through memory controller, which re-maps the particular row of memory to spaces above 4GB.
Disadvantage of this technique is the fact that since it needs to re-map a whole DIMM module at a time, the memory usage is much less flexible under this manner. Pure software implementation, no hardware support required to enable this option.

Pero, ¿de qué va todo esto del remapping de memoria?

Resulta que los sistemas de 32 bits sólo pueden direccionar 2³² = 4204067296 Bytes = 4 GiB de memoria, a menos que se implemente algún método más sofisticado como las PAE de la arquitectura x86/x86-64. Eso debería ser suficiente para gestionar 4 GiB de RAM en el PC, sea con Linux de 32 bits, con Windows de 32 bits o con cualquier otro sistema operativo de 32 bits. Sin embargo, en los PC no es tan fácil.

Los procesadores 8086 tenían un bus de direcciones de 20 bits, lo que resultaba en un espacio de direccionamiento de 1 MiB. Sin embargo, en aquella época los ingenieros de IBM pensaron que la ingente cantidad de 640 KiB debería ser más que suficiente para cualquiera, por lo que dedicaron los 384 KiB superiores de memoria para la BIOS (64 KiB o 128 KiB), para la tarjeta de vídeo (128 KiB), tarjetas de red o para cualquier tarjeta de ampliación adicional que quisiera instalar RAM adicional, de forma que se accediera a ella a través de esa RAM. Así, quedaron 384 KiB que no se podían usar fácilmente. En la época del MS-DOS la usábamos en parte para cargar en ella controladores como el del ratón o el del CD-ROM con LOADHIGH para liberar la máxima memoria convencional posible, que en las últimas etapas del MS-DOS siempre iba muy escasa (PC Memory Architecture Overview).

Con la llegada del 386, el primer procesador de arquitectura x86 de 32 bits, y su modo protegido, empezó a ser posible direccionar hasta 4GB. Sin embargo, en aquella época en la que 2 MiB de RAM costaban una fortuna, ¿quién se iba a imaginar que algún día haría falta tanta memoria? Así que se repitió la historia y de los 4 posibles GiB de memoria, dejaron casi un GiB de memoria reservado por arriba para comunicación con los dispositivos. Sobre todo, para tarjetas de vídeo más modernas que las VGA que usaran mucho más de los 384 KiB que cabían en la memoria superior (como los 256 MiB que tiene mi 6600).

Así, el esquema de la memoria de un PC actual de 8 GiB queda así, con los dos agujeros (memory hole) que hemos mencionado, el de justo antes del primer MiB y el de justo antes de los 4 GiB (esquema de Dude, Where’s My 4 Gigabytes of RAM?):

Con las cantidades de memoria que manejamos todos hoy en día, los 384 KiB de la memoria superior no nos importan en absoluto, pero el hueco que hay entro los 3 GiB y los 4 GiB molesta, y mucho. Tanto, que ocasiona que en los sistemas operativos de 32 bits para PC normalmente sólo se puedan ver entre 3 GiB y 3.12 GiB de memoria, como nos cuenta la propia Microsoft en: La memoria del sistema que aparece en el cuadro de diálogo Información del sistema en Windows Vista es menor de lo esperado si se ha instalado 4 GB de RAM.

Lo que hacen opciones de la BIOS como la “H/W DRAM Over 4G Remapping” de mi PC es mover el cuarto GiB de RAM que normalmente iría de los 3 a los 4 GiB al rango de los 4 a los 5 GiB o incluso más arriba si tenemos más de 4 GiB de memoria instalados. Es por eso que necesitamos un sistema operativo capaz de direccionar más de 4 GiB, aunque sólo tengamos 4 GiB.

Las PAE que mencionábamos antes permiten, mediante ciertas técnicas que consumen algo de CPU, direccionar 36 bits, hasta 64 GiB. Sin embargo, aunque sistemas operativos como Linux soportan PAE sin problemas, en Windows hay graves problemas con los drivers de dispositivos que sólo saben gestionar un bus de memoria de 32 bits. Por eso, tras sufrir interminables problemas con la opción /PAE del boot.ini, Microsoft decidió en el SP2 de XP que el rango máximo de memoria aceptable serían 4 GiB, descontando el agujero de memoria. Para el Windows Vista de 32 bits, como los drivers son básicamente los mismos, estamos en la misma situación, así que también “4 GiB menos el agujero” como máximo (Ask Dan: What’s with the 3Gb memory barrier?).

Así que algunas de las soluciones que tenemos hoy en día para usar 4 GiB (o más) son: usar Linux de 32 bits con PAE (no lo he probado personalmente), Linux de 64 bits o usar Windows Vista de 64 bits, siempre que nuestra BIOS tenga alguna opción de “memory remapping“.

Si queremos ver los efectos de ese “memory remapping“, no tenemos más que ver las primeras líneas del dmesg que muestran los primerísimos instantes del arranque de un Linux de 64 bits:

[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009d000 (usable)
[    0.000000]  BIOS-e820: 000000000009d000 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000bfff0000 (usable)
[    0.000000]  BIOS-e820: 00000000bfff0000 - 00000000bfff3000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000bfff3000 - 00000000c0000000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)

Si vamos traduciendo las direcciones hexadecimales a decimal, veremos que el mapa de memoria que la BIOS le presenta a Linux es este:

0 KiB a 628 KiB (disponible)
628 KiB a 640 KiB (reservada)
960 KiB a 1024 kiB (reservada)
1 MiB a 3 GiB-64 KiB (disponible)
3 GiB-64 KiB a 3 GiB-52 KiB (ACPI NVS)
3 GiB-52 KiB a 3 GiB (ACPI data)
3.0 GiB a 3.5 GiB (reservada)
4 GiB-20 MiB a 4 GiB (reservada)
4 GiB a 5 GiB (disponible)

Y en la última línea vemos, efectivamente, el “remapping” que ha hecho la BIOS del último GiB de RAM.

Si vamos al administrador de dispositivos de Windows XP podremos saber también en qué se usa exactamente toda la memoria de los 3 GiB a los 4 GiB. Sin embargo, no se verá el cuarto GiB que para el sistema es el quinto (rangos de memoria de 0xC0000000/3 GiB a 0xFFFFFFFF/4 GiB):

Cuando me decidí a hacer la ampliación a 4 GiB, a mí me resultaba indiferente que Windows XP sólo viera 3 GiB de memoria, ya que daba por hecho que en mi Ubuntu AMD64 no tendría ningún problema.

Sin embargo, no fue así. Desde el primer momento, siempre que activaba el remapping de la memoria en la BIOS, Ubuntu nunca conseguía arrancar. Unas veces daba un panic con mensaje de error, otras lo daba sin mensaje de error pero los leds de “Caps Lock” y “Scroll Lock” del teclado se ponían intermitentes indicando el panic y otras, simplemente, se colgaba.

Las primeras veces se colgaba inexplicablemente arrancando el subsistema de Bluetooth pero arrancando correctamente en modo monousuario. Las siguientes veces, al deshabilitar el Bluetooth, se colgaba al arrancar las X. Aquí ya fue la locura total de no saber qué estaba pasando.

Se me ocurrió probar con el LiveCD de Fedora 9 AMD64 con gran éxito: todo funcionaba a la perfección y los 4 GiB eran reconocidos, así que debía de ser problema de mi instalación de Ubuntu.

Por probar, se me ocurrió instalar el kernel de servidor de Ubuntu (linux-image-server)… ¡y sorprendentemente comenzó a funcionar todo! Repasando los respectivos config, me di cuenta de que realmente, las diferencias del kernel -generic con el -server son mínimas, así que no entendía por qué ya funcionaba todo bien. Y en una de las pruebas fue cuando me di cuenta de que con el -server se estaba usando el driver abierto nv y no el cerrado nvidia, ya que el paquete linux-restricted-modules-server no estaba instalado. Por tanto, descubrí que el problema estaba en alguno de los drivers no abiertos que usaba en mi sistema.

El sospechoso parecía ser el driver cerrado de NVidia, siendo que además tenía antecedentes (ejemplo 1, ejemplo 2, ejemplo 3). Pero, ¿sabéis qué? Que después de algunas pruebas y de haber culpado injustamente al odioso driver cerrado de NVidia (¡cerrado tenía que ser! ¿cómo no va a ir mal?), resulta que no era ese, ¡sino el driver MadWifi para los chipsets WiFi de Atheros!

Así que, desde que los deshabilité, no he tenido absolutamente ningún problema con los 4 GiB. Eso sí, lamentablemente, a costa de un montón de horas de pruebas.

Por último, aunque todo parecía correcto, no estaba seguro de si toda la memoria sería correctamente accesible sin que generara panics o problemas. Por eso decidí hacerme este pequeño programa (malloc4g.c) que llenara toda la memoria, usando incluso parte de la memoria swap:

#include <stdlib.h>
#include <stdio.h>

int main(int argc, char **argv)
{
   unsigned char *mem;
   unsigned long long int MEMMiB=4ULL*1024+512; // Memoria que queremos llenar en MiB: 4 GiB + 512 MiB
   unsigned long long int MiB=1024ULL*1024ULL; // Bytes que tiene un MiB
   unsigned long long int MEM=MEMMiB*MiB; // Memoria que queremos llenar en bytes
   char FILL=255; // Valor con el que llenamos la memoria
   unsigned long long int i;

   printf("Estamos en un sistema de %d bits.\n",sizeof(size_t)*8);
   if (sizeof(size_t)<8) {
      printf("Esta utilidad necesita un sistema de 64bits.\n");
      exit(1);
   }

   mem=malloc(MEM);

   if (mem==NULL) {
      printf("El malloc no ha funcionado.\n");
      exit(2);
   }

   printf("Llenando %lld bytes\n",MEM);

   for (i=0;i<MEM;i++) {
      mem[i]=FILL;
      if (i%MiB==0)
         printf("\r%lld MiB / %lld MiB",lldiv(i,MiB),MEMMiB);
   }

   exit(0);
}

Lo compilamos, lo ejecutamos:

 $ make malloc4g
cc     malloc4g.c   -o malloc4g
$ ./malloc4g
Estamos en un sistema de 64 bits.
Llenando 4831838208 bytes
4607 MiB / 4608 MiB

y vemos que podemos llenar toda la memoria sin nuevos panics, cuelgues o problemas:

:wq

Entradas relacionadas

• Wake on LAN (2)
• SMB connection failed: Insufficient server memory to perform the requested function. (2)
• Recuperación de particiones perdidas con gpart (2)
• Petición para que VIA tome una postura clara respecto a Linux (2)
• Pero, ¿qué les pasa a los fabricantes de hardware? (2)
• Los DPI en pantalla en Windows y Linux (2)

Esta entrada fue publicada bajo una licencia CC el 14 Julio 2008 a las 22:19 y pertenece a la categoría GNU/Linux, Hardware, Windows. Etiquetas: GNU/Linux, Hardware, memoria RAM, Windows. Puedes seguir las respuestas a través de RSS. Puedes dejar un comentario, o hacer trackback desde tu página.