# AMD64 x2 inestable (solucionado)

## johnlu

He podido constatar que mi AMD64 x2 Socket AM2 no funciona como debería, no sé si a causa de algún problema de configuración de gentoo o bien que esté mi procesador en mal estado. Me gustaría saber algunas cosas sobre vuestras configuraciones para ver si yo difiero con vosotros.

$ cat /proc/cpuinfo 

```
processor       : 0

vendor_id       : AuthenticAMD

cpu family      : 15

model           : 75

model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+

stepping        : 2

cpu MHz         : 2210.183

cache size      : 512 KB

physical id     : 0

siblings        : 2

core id         : 0

cpu cores       : 2

fpu             : yes

fpu_exception   : yes

cpuid level     : 1

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy

bogomips        : 4424.14

TLB size        : 1024 4K pages

clflush size    : 64

cache_alignment : 64

address sizes   : 40 bits physical, 48 bits virtual

power management: ts fid vid ttp tm stc

processor       : 1

vendor_id       : AuthenticAMD

cpu family      : 15

model           : 75

model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+

stepping        : 2

cpu MHz         : 2210.183

cache size      : 512 KB

physical id     : 0

siblings        : 2

core id         : 1

cpu cores       : 2

fpu             : yes

fpu_exception   : yes

cpuid level     : 1

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy

bogomips        : 4420.45

TLB size        : 1024 4K pages

clflush size    : 64

cache_alignment : 64

address sizes   : 40 bits physical, 48 bits virtual

power management: ts fid vid ttp tm stc

```

CFLAGS, CHOST en /etc/make.conf

```
CFLAGS="-march=athlon64 -O2 -pipe"

CHOST="x86_64-pc-linux-gnu"

CXXFLAGS="${CFLAGS}"

```

He visto en http://gentoo-wiki.com/Safe_Cflags#Athlon_64_X2_.28AMD.29 que mi procesador acepta la opción -msse3, pero no la quiero añadir hasta dar con el problema. Estoy usando 2.6.20-gentoo-r8 como kernel. Si alguien quiere ver todo el .config lo añado en una respuesta al post, por ahora creo que basta con esto:

```
   Processor type and features  --->

        Subarchitecture Type (PC-compatible)  --->

        Processor family (AMD-Opteron/Athlon64)  --->  

```

Last edited by johnlu on Sat Jun 02, 2007 5:26 am; edited 1 time in total

----------

## Hefistion

Perdona mi ignorancia pero a que te refieres con "no funciona como debería" ?

salu2

----------

## i92guboj

A no ser que nos des algunos detalles de por qué piensas que no funciona como debería (síntomas) y de por qué piensas que es algo relacionado con tu cpu, no creo que podamos ayudar mucho.

----------

## johnlu

1) Se queda congelado el sistema al menos una vez al día. He actulizado del kernel gentoo-2.6.20-r7 al gentoo-2.6.20-r8 y lleva al menos 24h que no se me queda el sistema congelado, aún está por ver si es suerte o que realmente lo he arreglado.

2) Emerge se me queda colgado, en cualquier punto, una veces descomprimiendo, otras en el cambio de un paquete a otro... otras en medio de una compilación.

3) Otras veces fallan las compilaciones en emerge, siempre fallos distintos, y en distintos paquetes, hago emerge --resume y no se repite el fallo, pero sí que acaba fallando en otro paquete.

Me he equivocado al decir que mi CPU no funciona como debería, no tiene por que ser la CPU físicamente, sospecho que es algo relacionado con la configuración de CFLAGS o el kernel, pero la verdad que ni idea por ahora.

Por favor, además de las cosas que se os ocurran comparad lo que he puesto con lo que hay en vuestras configuraciones.  :Smile: 

----------

## Cereza

¿Tal vez tu CPU se sobrecalienta? prueba a instalar algún programa para verlo, como ksensors.

----------

## Stolz

Me apuesto unas cañas a que es problema de temperatura   :Rolling Eyes: 

----------

## i92guboj

Hola de nuevo,

 *johnlu wrote:*   

> 1) Se queda congelado el sistema al menos una vez al día. He actulizado del kernel gentoo-2.6.20-r7 al gentoo-2.6.20-r8 y lleva al menos 24h que no se me queda el sistema congelado, aún está por ver si es suerte o que realmente lo he arreglado.
> 
> 2) Emerge se me queda colgado, en cualquier punto, una veces descomprimiendo, otras en el cambio de un paquete a otro... otras en medio de una compilación.
> 
> 3) Otras veces fallan las compilaciones en emerge, siempre fallos distintos, y en distintos paquetes, hago emerge --resume y no se repite el fallo, pero sí que acaba fallando en otro paquete.
> ...

 

Todo esto, me hace suponer que se trata de un problema de hardware. Sobre todo el punto tres. Los fallos aleatorios, que además no se repiten, o se repiten en puntos distintos, sin patrón fijo alguno, son siempre síntoma de que algo está fallando en tu hardware. Los dos candidatos principales, como casi siempre, son CPU y memoria.

Yo comenzaría monitorizando la temperatura de la cpu, hazlo mientras compilas algo pesado, y fíjate si va subiendo de forma exagerada. Luego, pasa memtest86 (lo puedes emerger incluso, luego tan solo configura una entrada para él en grub.conf y listo).

Si has puesto algún set de "optimizaciones mágicas" en tu BIOS, desactívalas. Lo mismo si estás haciendo overclocking. Si tienes varias pastillas de memoria, prueba dejando solo una distinta cada vez, a ver que pasa.

Lo peor de estos problemas, a no ser que sea un problema evidente de temperatura y/o overclocking o ram timings, son algo complicados de diagnosticar.

 *Quote:*   

> Me he equivocado al decir que mi CPU no funciona como debería, no tiene por que ser la CPU físicamente, sospecho que es algo relacionado con la configuración de CFLAGS o el kernel, pero la verdad que ni idea por ahora.
> 
> 

 

Por 1 y 2, podría ser cualquiera de estas cosas. Un kernel defactuoso puede, ciértamente, dejar tu pc helado. Incluso un módulo de terceros que estés usando. Pero el punto 3 (fallos de compilación aleatorios y sin patrón) son denotativos de que algo va mal a un nivel más bajo: a nivel de hardware. Tanto más, si son segfaults.

 *Quote:*   

> Por favor, además de las cosas que se os ocurran comparad lo que he puesto con lo que hay en vuestras configuraciones. 

 

Suponiendo que no estés haciendo cosas raras en tu BIOS ni estés haciendo overclocking sobre tu cpu ni tu memoria, lo demás que has posteado en tu config es normal. De todas formas, postea tu emerge --info completo, por si acaso alguien viera algo raro. Pero no creo que el problema vaya por ahí.

----------

## sefirotsama

Vi algo similar en un amd K6 - 2 montado con piezas viejas que se queria usar como mule-server. En principio pensabamos que era por que la maquian se queria jubilar y no era muy potente... luego que la configuraciÃ³n, se culpÃ³ a windows, a bill gates, culparon a Ubuntu, culparon a la suciedad que habia sobre el hardware, se culpÃ³ la fuente de alimentaciÃ³n, a Jazztel (no tenia mucho que ver) a todo...

Un dia un colega se fijÃ³ al arrancar el PC que la bios solo detectaba 8MB de RAM (cuando tenia modulos para 128).

DespuÃ©s de eso cuando algo falla en un PC quito todas las piezas y pruebo una a una (le voy poniendo mÃ¡s poco a poco). Y las RAM aunque sean nuevas les dejo unas horas haciendo el memtest.

Primero mira que no sea alguna evidencia gorda tipo una RAM mal pinchada y si todo aparentemente es correcto y no dicen nada muy especial los tests, revisa la configuraciÃ³n del kernel (o activa las opciones de debug si esperas cuelgues).

 :Razz: 

----------

## johnlu

Entre 28ºC y 32ºC no creo que sea problema de temperatura, ¿o sí? Estoy acostumbrado a un athlon-tbird que estaba siempre a 60ºC así que no sé. Contadme vosotros. Probaré, la memoria con memtest en cuanto vuelva a casa, ¿si hay problemas de memoria qué debería pasar con memtest86?Last edited by johnlu on Fri Jun 01, 2007 5:55 pm; edited 1 time in total

----------

## sefirotsama

Ojo con el memtest y la arquitectura, memtest86 es para x86.

 *Quote:*   

> Â¿si hay problemas de memoria quÃ© deberÃ­a pasar con memtest86?

 

Le daras a memtest en el grub y selecciona que pase los test que quieras. SI la RAM da pol culo pq es defectuosa apareceran mensages en rojo (no cal que les des aceptar ni nada, quedan en un alista).

Advierto que tarda mucho en hacerse todos los test de memoria, (no es moco de pavo).

----------

## johnlu

 *sefirotsama wrote:*   

> Ojo con el memtest y la arquitectura, memtest86 es para x86.

 

Y digo yo, Â¿no hay nada para 64bits al estilo memtest?

----------

## i92guboj

 *johnlu wrote:*   

>  *sefirotsama wrote:*   Ojo con el memtest y la arquitectura, memtest86 es para x86. 
> 
> Y digo yo, Â¿no hay nada para 64bits al estilo memtest?

 

Memtest86 se ejecuta fuera del SO, no tiene nada que ver con linux. Es como un kernel distinto en la lista de grub, y su única funcionalidad es la de testear la memoria. No importa si funciona en modo 32 o 64 bits. Eso es irrelevante, lo único que tiene que verificar es que se pueda escribir y leer de la memoria cualquier combinación de bits correctamente.

----------

## Hefistion

también podría ser el disco duro, utiliza algún software para comprobar que no haya sectores defectuosos, asi vamos descartando cosas.

salu2

----------

## AnFe

Eso que dices me pasaba a mi por tener la swap mal puesta en /etc/fstab. Es lo que pasa al modificar las particiones con partition magic...

Un saludo!

----------

## johnlu

En este momento memtest-86 lleva funcionando 16 horas y 10 minutos, y no ha detectado ningún error en la memoria. Creo que ya es suficiente como test de memoria, ¿verdad?

¿Qué me recomendáis para hacer un test al disco duro?

¿Y para la CPU?

----------

## i92guboj

 *johnlu wrote:*   

> En este momento memtest-86 lleva funcionando 16 horas y 10 minutos, y no ha detectado ningún error en la memoria. Creo que ya es suficiente como test de memoria, ¿verdad?
> 
> ¿Qué me recomendáis para hacer un test al disco duro?
> 
> ¿Y para la CPU?

 

Ni siquiera memtest86 es infalible, si tienes módulos extra para probar, y otro ordenador para cambiar las cpus, yo probaría. Para el disco duro, primero arranca desde un livecd, y pásale fsck a todas tus particiones, para ver si tienen algún error o algo. Si lo tienen, arréglalo y reinicia. 

Tus errores de compilación, como son exactamente? Puedes decirnos si son segfaults o errores de I/O? Algo que nos pueda dar más info en alguno de los errores?

----------

## Inodoro_Pereyra

 *Quote:*   

> también podría ser el disco duro

 

Errores de compilacion por una falla en el disco? Nahh...

Motherboard o Microprocesador o fuente de alimentacion, las 3 posibilidades que quedan.

Mother:

- Desactivar todo lo que tenga la palabra "cache" en la bios, la pc va a funcionar como si fuera a carbon pero deberia servir para hacer algunas pruebas basicas.

- Bajarle de alguna manera la temperatura al chipset de la placa madre, si tuviera 2, en particular al northbridge.

Microprocesador: Llevo 11 años dedicandome a esto y solo he visto 2 casos en donde "funciona pero no funciona", no creo...

Fuente: Si no estuviera filtrando bien el ripple a la salida de 3.3 podria originar una falla como la que presenta tu pc.

Memorias: Descartadas casi por lo del memtest, pero como dice 6thpink, nunca esta de mas cambiarlas. Si no fuera por memtest mi primer diagnostico hubiera sido el que ya te dieron, temperatura o memorias.

Saludos!

----------

## i92guboj

 *inodoro_pereyra wrote:*   

>  *Quote:*   también podría ser el disco duro 
> 
> Errores de compilacion por una falla en el disco? Nahh...
> 
> 

 

Pseeee jejeje, ¿nunca has tenido un disk i/o error mientras compilabas debido a algún fallo en tu partición var?, entonces eres afortunado  :Smile: 

Todo depende, como dije arriba, segfaults aleatorios = memoria, cpu o placa base. disk i/o errors, también frecuentes en las compilaciones debido a la gran cantidad de ficheros que se manejan, = error en la partición, o incluso fallo de hardware del disco.

Tanto en un caso como en otro, el fallo puede aparecer en las tareas cotidianas, al igual que compilando, pero en ambos casos (aunque por distinto motivo) la compilación aumenta las posibilidades de que el error aparezca. Un fallo grave de disco duro, dependiendo de donde pille al kernel, puede bloquear el pc igual que un fallo de segmentación.

 *Quote:*   

> Motherboard o Microprocesador o fuente de alimentacion, las 3 posibilidades que quedan.
> 
> 

 

No descartaría la memoria tan rápido, como dije arriba. He visto muchísimos casos en los que memtest86 no detecta nada, pero todo desaparece al cambiar el modulito.

En cualquier caso, si pudieras pegar al menos uno de los errores, quizás dejaríamos de dar palos de ciego.

----------

## johnlu

Tengo un error fresco, conforme vaya teniendo más los pongo.

```
x86_64-pc-linux-gnu-gcc ether_line.c -c -std=gnu99 -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -march=athlon64 -pipe -Wstrict-prototypes -mpreferred-stack-boundary=2  -fPIC    -I../include -I/var/tmp/portage/sys-libs/glibc-2.5-r3/work/build-x86-x86_64-pc-linux-gnu-nptl/inet -I/var/tmp/portage/sys-libs/glibc-2.5-r3/work/build-x86-x86_64-pc-linux-gnu-nptl -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386 -I../ports/sysdeps/unix/sysv/linux -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv/i386 -I../ports/sysdeps/unix/sysv -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../ports/sysdeps/unix -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../nptl/sysdeps/i386/i686 -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../ports -I../nptl  -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h  -DPIC -DSHARED      -o /var/tmp/portage/sys-libs/glibc-2.5-r3/work/build-x86-x86_64-pc-linux-gnu-nptl/inet/ether_line.os -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.5-r3/work/build-x86-x86_64-pc-linux-gnu-nptl/inet/ether_line.os.dt -MT /var/tmp/portage/sys-libs/glibc-2.5-r3/work/build-x86-x86_64-pc-linux-gnu-nptl/inet/ether_line.os

The bug is not reproducible, so it is likely a hardware or OS problem.

make[2]: *** [/var/tmp/portage/sys-libs/glibc-2.5-r3/work/build-x86-x86_64-pc-linux-gnu-nptl/inet/getrpcbynumber_r.os] Error 1

make[2]: *** Se espera a que terminen otras tareas....

make[2]: se sale del directorio `/var/tmp/portage/sys-libs/glibc-2.5-r3/work/glibc-2.5/inet'

make[1]: *** [inet/subdir_lib] Error 2

make[1]: se sale del directorio `/var/tmp/portage/sys-libs/glibc-2.5-r3/work/glibc-2.5'

make: *** [all] Error 2

!!! ERROR: sys-libs/glibc-2.5-r3 failed.

Call stack:

  ebuild.sh, line 1615:   Called dyn_compile

  ebuild.sh, line 972:   Called qa_call 'src_compile'

  ebuild.sh, line 44:   Called src_compile

  glibc-2.5-r3.ebuild, line 1159:   Called src_compile

  glibc-2.5-r3.ebuild, line 1170:   Called toolchain-glibc_src_compile

  glibc-2.5-r3.ebuild, line 272:   Called die

!!! make for x86 failed

!!! If you need support, post the topmost build error, and the call stack if relevant.

!!! A complete build log is located at '/var/tmp/portage/sys-libs/glibc-2.5-r3/temp/build.log'.

```

Creo que "The bug is not reproducible, so it is likely a hardware or OS problem." es suficientemente descriptivo.

----------

## johnlu

 *6thpink wrote:*   

> Memtest86 se ejecuta fuera del SO, no tiene nada que ver con linux. Es como un kernel distinto en la lista de grub, y su única funcionalidad es la de testear la memoria. No importa si funciona en modo 32 o 64 bits. Eso es irrelevante, lo único que tiene que verificar es que se pueda escribir y leer de la memoria cualquier combinación de bits correctamente.

 

Supongo que lo unico que influye es si tienes más de 4GiB de RAM por que con 32 bits no se pueden direccionar a no ser que tengas soporte PAE o algo así, pero bueno, eso ya es OffTopic.  :Very Happy: 

----------

## johnlu

Otro error distinto con el mismo paquete.

```
x86_64-pc-linux-gnu-gcc hstcache.c -c -std=gnu99 -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -march=athlon64 -pipe -Wstrict-prototypes   -DHAVE_SENDFILE -DIS_IN_nscd=1 -D_FORTIFY_SOURCE=2 -fpie -fstack-protector   -I../include -I/var/tmp/portage/sys-libs/glibc-2.5-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl/nscd -I/var/tmp/portage/sys-libs/glibc-2.5-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl -I../sysdeps/x86_64/elf -I../nptl/sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/wordsize-64 -I../ports/sysdeps/unix/sysv/linux -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../ports/sysdeps/unix -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/fpu -I../nptl/sysdeps/x86_64 -I../sysdeps/x86_64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../ports -I../nptl  -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h   -DNOT_IN_libc=1     -o /var/tmp/portage/sys-libs/glibc-2.5-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl/nscd/hstcache.o -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.5-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl/nscd/hstcache.o.dt -MT /var/tmp/portage/sys-libs/glibc-2.5-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl/nscd/hstcache.o

En el fichero incluído de ../include/elf.h:2,

                 de ../elf/link.h:25,

                 de ../include/link.h:33,

                 de ../include/dlfcn.h:3,

                 de ../nss/nsswitch.h:29,

                 de ../nss/getXXbyYY_r.c:23,

                 de getgrnam_r.c:27:

../elf/elf.h:1096:2: error: directiva de preprocesamiento #denine inválida

make[2]: *** [/var/tmp/portage/sys-libs/glibc-2.5-r3/work/build-amd64-x86_64-pc-linux-gnu-nptl/nscd/getgrnam_r.o] Error 1

make[2]: *** Se espera a que terminen otras tareas....

make[2]: se sale del directorio `/var/tmp/portage/sys-libs/glibc-2.5-r3/work/glibc-2.5/nscd'

make[1]: *** [nscd/others] Error 2

make[1]: se sale del directorio `/var/tmp/portage/sys-libs/glibc-2.5-r3/work/glibc-2.5'

make: *** [all] Error 2

!!! ERROR: sys-libs/glibc-2.5-r3 failed.

Call stack:

  ebuild.sh, line 1615:   Called dyn_compile

  ebuild.sh, line 972:   Called qa_call 'src_compile'

  ebuild.sh, line 44:   Called src_compile

  glibc-2.5-r3.ebuild, line 1159:   Called src_compile

  glibc-2.5-r3.ebuild, line 1170:   Called toolchain-glibc_src_compile

  glibc-2.5-r3.ebuild, line 272:   Called die

!!! make for amd64 failed

!!! If you need support, post the topmost build error, and the call stack if relevant.

!!! A complete build log is located at '/var/tmp/portage/sys-libs/glibc-2.5-r3/temp/build.log'.
```

----------

## johnlu

¡Bien! ¡Ya he conseguido encontrar el problema!

Os cuento:

Primero quité un módulo de memoria y emerge dejó de dar problemas. Después intercambié las memorias y sigió sin dar problemas, pero al terminar puse otra vez las dos memorias en dual-channel y ¡emerge comenzó a fallar de nuevo!

Esto me hizo pensar que podría ser un problema de configuración de hardware más que alguna pieza de hardware en mal estado. He mirado en la guía de usuario de mi placa base (ASUS M2N-E) y he encontrado en la lista de vendedores de ram soportados por la placa que el modelo de ram que he comprado (Kingston KVR667D2N5/1G) no soporta dual-channel para un único par de módulos de ram. Sin embargo sí lo soporta para dos pares de módulos.

Solución temporal:

He colocado los dos módulos de memoria en single-channel.

Solución definitiva:

Descambiar en la tienda estos módulos por otros que mi placa sí soporte en dual-channel para un único par de módulos.

----------

