Lo hice y lo entendí

El blog de Vicente Navarro
14 jul

La odisea de ampliar la memoria a 4 GiB

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 232 = 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 %ld 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%d 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:

Actualización 20/9/2010: Wikipedia: 3 GB barrier
:wq

Entradas relacionadas

22 Comentarios a “La odisea de ampliar la memoria a 4 GiB”

  • En verdad, ante vos, me quito el sombrero… Digo, a mi también me han pasado unos cuantos ‘issues’ en cuestiones hardware/software, pero en varias ocasiones la paciencia se me ha acabado antes de solucionarlo.
    Supongo que es cuestión de no impacientarse y ser constante, pero habemos algunos que no entendemos ^__^U .

  • Pifaf dice:

    Me parece un artículo estupendo.
    Es de agradecer que haya alguien con el talento y las ganas de compartir su tiempo y trabajo con los demás y explicarlo de una manera sencilla.

    Ánimo, y esperamos nuevos artículos pronto.

  • Bienvenido al mundo de las cosas raras. Yo cuando tengo tiempo (Cada vez menos) me peleo con cosas como éstas, en otras casos, se busca el remedio, aun sin saber qué está pasando.

    Y por cierto lo que me cuentas, se parece muchísimo a una incidencia que tuvimos hace un mes y que se resolvió por la bravas. Cliente que amplia el PC, nueva placa, nuevo micro y 4 gigas de Ram. Instala Ubuntu, pone su sintonizadora de TV y su Wifi y aquello empieza a petar, Quita la sintonizadora y el wifi y no peta… al final ponemos otra wifi (15 euros) y desaparecen los problemas. Y el chip de la primera wifi era un Atheros… así que ahora si que lo entiendo.

  • Iván dice:

    Enhorabuena por el artículo, muy bueno y muy bien explicado. Me has aclarado muchísimas dudas que tenía sobre la famosa barrera de los 4 GB.

    Yo también me estaba planteando ampliar de 2 a 4 GB, pero visto lo visto me lo voy a pensar otra vez. Además, tendría que instalar Ubuntu de 64 bits (en su momento instalé el de 32 y ahora me da mucha pereza reinstalar) y no tengo tanto tiempo de momento.

    Por cierto, necesitas 4 GB por algo en especial?. Porque mi ordena con 2 GB en Ubuntu va sobradísimo. De hecho muchas veces tengo también arrancada una máquina virtual vmware windows xp con 512 MB y le doy mucha caña y todavía no he conseguido “llenar” los 2 GB. Es simple curiosidad.

    Saludos, Iván.

    –Edito el comentario–
    P.D: No he sido capaz de poner el comentario con mi url. Después de autenticarme en mi proveedor de OpenID me redireccionaba a WordPress y ahí no había manera de logarme. Has cambiado algo?. Es que nunca me había redireccionado ahí.
    Gracias.

  • @Kureno Asakura, @Pifaf ¡Gracias! ¡Me alegro de que os haya gustado!

    @tenderodigital Pues sí, las interacciones entre los componentes del hardware y los drivers a veces son de lo más sorprendentes… 8O ¡Gracias por la visita!

    @Iván ¡Gracias! Pues lo he hecho precisamente por tener varias máquinas virtuales funcionando al mismo tiempo para ciertas pruebas que quisiera hacer. En realidad, para uso como máquina individual, sin imágenes virtuales, como dices, los 2 GiB nunca se llenaban.

    Sobre el OpenID, no sé que puede pasar… Acabo de probar a dejar comentarios con las URLs http://lohiceyloentendi.wordpress.com y http://lohiceyloentendi.blogspot.com (estando previamente registrado en Google y en WordPress.com) y ambos comentarios se han guardado con OpenID sin problemas…

  • cls4ever dice:

    Menuda enciclopedia con patas estas hecho SuperCoco…xD
    Quiza no tenga mucho que ver con el tema principal de esta entrada, pero tenia una curiosidad sobre la nomenclatura que usas de “MiB” y “GiB” para los comunmente conocidos como “Mb” y “Gb”. Quiza sea fruto de mi ignorancia o una simple obviedad…
    Me viene a la cabeza otra similitud sobre la forma de pronunciar dichos terminos… Hay quien dice “Giga” y quien lo hace como “Yiga”
    Gracias
    ——
    PD: A mi tambien me ha dado un problemilla en el login de OpenId pero al final me ha dejado. Quiza sea porque soy amateur en lo de OpenId y creo que me cree cuentas OpenId en diferentes paginas y no se como es su uso y compatibilidad. me informare.. xD

  • @cls4ever ¡Gracias!

    Respecto a lo que preguntas, K, M o G son prefijos del sistema internacional que implican 103, 106 y 109 respectivamente. Desde el comienzo de la informática se solían usar esos mismos prefijos para denotar 210, 220 y 230, ya que tienen valores bastante parecidos, aunque no iguales (1000 es distinto de 1024). Desde los años 70 era común usar los prefijos con significado binario para memorias RAM y los prefijos con significado decimal para discos duros, como sigue siendo habitual hoy en día.

    Sin embargo, en los años 70, la diferencia entre “1 mega decimal” y “1 mega binario” era muy pequeña. Hoy en día, es muchísima la diferencia entre “500 gigas decimales” y “500 gigas binarios”, lo que produce mucha confusión entre los usuarios y consumidores. Confusión agravada por el hecho de que en redes de comunicaciones también se usan los prefijos decimales (p.e. una red de 100 Mbps).

    Por eso, el IEEE introdujo el estándar IEC 60027 en 1999 y el IEEE 1541 en 2005, que debería de eliminar cualquier rastro de confusión para siempre dejando los prefijos decimales K, M o G tal y como se usan en el sistema internacional e introdujo los prefijos Ki (kibi), Mi (mibi) y Gi (gibi) para denotar prefijos binarios.

    Así:

    1 GB = 1000 MB
    1 MB = 1000 KB
    1 KB = 1000 B
    1 GiB = 1024 MiB
    1 MiB = 1024 KiB
    1 KiB = 1024 B

    Sería muy conveniente que todos (fabricantes, usuarios) adoptáramos esta nomenclatura siempre para que nunca más pudiera haber lugar a dudas sobre cuánto ancho de banda estamos contratando o de cuánta capacidad es exactamente nuestro nuevo disco duro.

    Más info en la WikiPedia:

    Binary prefix
    Gigabyte
    Megabyte

  • maty dice:

    Y yo que había corregido lo del GiB en el texto que había reproducido… Ya lo he solventado.

    Lo dicho, aprendo leyéndote, lo que no puedo decir de la mayoría de los sumarios RSS blogosféricos en los que ando subscrito.

  • maty dice:

    Deberías retocar la plantilla para aumentar la separación entre líneas. De paso, cambiar el color de la cita en los comentarios para diferenciarlos de los de la anotación. Y cambiar el lateral a la derecha, más usable si se accede desde pantallas pequeñas, como en los nuevos portátiles baratos.

  • @maty Me alegro mucho de que te haya parecido interesante, ¡y gracias por la referencia en tu blog!

    Respecto a tus sugerencias sobre la plantilla, las tendré muy en cuenta la próxima vez que me ponga a retocarla, algo que hago de vez en cuando. Como bien sabrás, no se puede tocar muy a la ligera porque a veces con el CSS cortas de aquí y se abre por allá ;-)

    Me parece muy razonable lo de aumentar el espaciado, y es algo que no había apreciado, pero tienes razón en que las líneas están demasiado juntas. Y lo de la barra latera, en su día hice pruebas y me convenció más así, pero ¡las volveré a hacer!

    ¡Gracias por las sugerencias!

  • Eduardo dice:

    Muchas gracias por otro fantástico artículo, solo comentar que el script decode-dimms.pl ahora viene en el paquete i2c-tools.

    Por supuesto en debian aptitude install i2c-tools :-P

  • Bytecoders dice:

    Rayos, si que resulta complicada la ampliación a 4GB. El método de prueba y error suele ser bastante costoso y tedioso pero nos alegramos de que lo consiguieras y que lo compartas.

    Bueno, tal vez algún día nos aventuremos en el tema de la ampliación de RAM de momento parece que me basta con 1 GB (no hace demasiado uso de la swap).

    Saludetes

  • @Eduardo Tienes mucha razón. Fíjate que yo ya había probado a instalar ese paquete y resulta que como no encontraba el decode-dimms.pl pensaba que era que es que ya no venía. ¡Y no es eso! ¡Es que ahora viene en /usr/bin/decode-dimms y como yo buscaba el fichero .pl no lo encontraba! ¡Qué cosas! ¡Muchas gracias por la puntualización!

    @Bytecoders Bueno, ser fácil es fácil… si te conformas con tener sólo 3 GiB y pico… :P

  • Ringmaster dice:

    Artículo de obligada consulta para los que quieran ampliar a 4 GB; tengo un equipo muy similar al tuyo y de momento me sobra y basta con 2GB en mi Ubuntu 32 Bits.
    Pero siempre hay más de un “vistaizado” que los necesite… y otros que exploten al máximo su ordenador (como Super Coco) ¡Eso es sacarle provecho!!

  • AndresZua dice:

    @supercoco…. hola amigo quise utilizar tu script pero me sale que no existen esas librerias….. como hago para instalarlas en ubuntu 8.04.1__??

  • @AndresZua ¿Qué error en concreto te da?

  • AndresZua dice:

    Hola supercoco…

    Bien si que me porte tonto al no mandarte el error especifico… y aprovechando te mando todos los detalles de lo que hice quiza por ahi me haya equivocado…

    en el menu principal hice… Lugares>Carpeta personal ahi hice clic derecho>crear un documento>archivo vacio… le puse nombre a.c.. lo abri y escribi el codigo de la memoria ram… lo guarde y cerre…. abri la terminal y puse el comando make a y me sale lo siguiente….

    andreszua@andreszua-laptop:~$ make a
    cc a.c -o a
    a.c:1:20: error: stdlib.h: No existe el fichero ó directorio
    a.c:2:19: error: stdio.h: No existe el fichero ó directorio
    a.c: En la función ‘main’:
    a.c:13: aviso: declaración implícita incompatible de la función interna ‘printf’
    a.c:13: error: ‘size_t’ no se declaró aquí (primer uso en esta función)
    a.c:13: error: (Cada identificador no declarado solamente se reporta una vez
    a.c:13: error: para cada funcion en la que aparece.)
    a.c:16: aviso: declaración implícita incompatible de la función interna ‘exit’
    a.c:19: aviso: declaración implícita incompatible de la función interna ‘malloc’
    a.c:21: error: ‘NULL’ no se declaró aquí (primer uso en esta función)
    a.c:23: aviso: declaración implícita incompatible de la función interna ‘exit’
    a.c:34: aviso: declaración implícita incompatible de la función interna ‘exit’
    make: *** [a] Error 1
    andreszua@andreszua-laptop:~$

    Y me pueso fijar claramente que en la primera linea y segunda me sale que no existe el fichero o directorio y supongo que de ahi deriban los demas errores…. a tu codigo no le cambie ni una coma… gracias por la ayuda…

  • @AndresZua Instala el paquete libc6-dev y si no me equivoco, ya te funcionará.

  • AndresZua dice:

    Hola supercoco,,, que bien ya instale el ubuntu 64 sin problemas la memoria me corre super bien, la dell sps m1330 se ha portado bien con el ubuntu me sirve absolutamente todo claro con unos issues al comienzo pero solucionables todos… estoy muy contento lo unico que no me tiene tan contento es que no puedo jugar el warcraft con crack supongo que es por el crack que no funciona con el wine ya que el warcraft si esta en la lista de aplicaciones soportadas…. ahhh y tambien el hibernar no funciona tan bien como en windows pero no importa…. bueno despues de contarte mi experiencia positiva quiero preguntarte algo que me salto a la mente mientras corria tu programa…. y es sobre la memoria swap,,, la puse al ultimo del disco duro ya que se supone es la parte mas rapida y de tamaño 4gb que es = a la ram instalada pues eso lo sugiere en el wiki de dell&ubuntu …. bien pero al hacer la prueba con tu programa apenas se lleno algo menos de 1gigaymedio,,, me parece que desperdicio 2gbymedio que me parece considerable juajuajau soy un poco avaro…. que opinas de esto? vi que tu tama;o es de 1,7gb porque pusiste este valor? que valor me aconsejas?… gracias por todo creo que mas de uno tendra esta duda ya que en internet hay miles de formulas y sugerencias…… personalmente creo que una swap de 2gb es mas que suficiente si tienes 4gb de ram porque no hay programa que necesite mas de 2gb… saludos…

  • @AndresZua El programilla por defecto sólo llena 4.5 GiB. Puedes modificarlo cambiando esto:

    MEMMiB=4ULL*1024+512

    Sobre la swap, hoy en día, en ordenadores de 2 GiB de RAM o más, es bastante raro que llegue a usarse en algún momento, así que puedes poner lo que quieras, incluso no poner nada. Yo ahora tengo 1.7 GiB porque al principio tenía 4 GiB y necesité ampliar otra partición y le robé espacio. Para lo que sí resulta útil tener algo más en la swap que en la RAM es por si quieres hibernar el sistema en la partición de swap.

Trackbacks y pingbacks:

Tema LHYLE09, creado por Vicente Navarro