[opensuse-es] Cuelgues del servidor
Hola, Desde un tiempo para acá estoy experimentando cuelgues de mi servidor doméstico. Hasta ahora no he encuentrado el motivo. Se puede volver a arrancar y puede pasarse varios días funcionando correctamente hasta que se cuelga otra vez: no responde a nada gráfico (no se puede hacer login, escribo el nombre de usuario pero ya no deja escribir el password). Entonces si arranco una consola hay algunos comandos que tienen respuesta otros no. Con lo que sólo me queda que hacer poweroff -f (ni shutdown, ni halt responden. Supongo que poweroff equivale a darle al botón). A nivel de logs no he visto nada significativo. Con estos síntomas ¿Por dónde puedo intentar buscar la solución? Gracias -- ---- Josep M Solé
Josep> Desde un tiempo para acá estoy experimentando cuelgues de mi servidor Josep> doméstico. Hasta ahora no he encuentrado el motivo. Se puede volver a Josep> arrancar y puede pasarse varios días funcionando correctamente hasta que se Josep> cuelga otra vez: no responde a nada gráfico (no se puede hacer login, escribo Josep> el nombre de usuario pero ya no deja escribir el password). Entonces si Josep> arranco una consola hay algunos comandos que tienen respuesta otros no. Si "tiene vida" desde cónsola, podría tratarse de un problema con la targeta gráfica y el escritorio. Recuerda que algunos comandos no estan al alcance del usuario y hay que ejecutarlos bien con "sudo" bien como "root" Si esto te pasa ejecutando desde "root" también podría tratarse de un problema físico con el HD o de alguna memoria defectuosa. Si se tratarade un problema de calor la máquina se cerraría sin hacer cosas extrañas. Lo que si es raro es que estando "vivo" no deje rastros del error en /var/log/messages También podrías investigar los procesos que quedan abiertos y su consumo de CPU, al producirse el error, para intentar averiguar por donde van los tiros. O si alguno de los que debieran estar ejecutándose se ha cerrado. En fin, y en mi opinión, hacen falta más pistas......
El Monday 20 October 2008 20:17:00 J.M.Queralt escribió:
Si "tiene vida" desde cónsola, podría tratarse de un problema con la targeta gráfica y el escritorio.
** Tiene vida "limitada" ya que muchos comandos no dan respuesta o quedan indefinidamente (= horas) sin resolverse.
Recuerda que algunos comandos no estan al alcance del usuario y hay que ejecutarlos bien con "sudo" bien como "root"
Si esto te pasa ejecutando desde "root" también podría tratarse de un problema físico con el HD o de alguna memoria defectuosa.
** Pensando un poco si este error sigue algun tipo de pauta, puedo decir que reaparece entre 48 y 72 horas.
Si se tratarade un problema de calor la máquina se cerraría sin hacer cosas extrañas.
Lo que si es raro es que estando "vivo" no deje rastros del error en /var/log/messages
** Me aparece el siguiente error: Oct 20 21:04:28 server python: hp-systray[3583]: error: option -s not recognized
También podrías investigar los procesos que quedan abiertos y su consumo de CPU, al producirse el error, para intentar averiguar por donde van los tiros. O si alguno de los que debieran estar ejecutándose se ha cerrado.
** Ya pero no puedo guardar nada y no sé cuál debe estar . Ejecuto ps -aef, que sí que funciona, pero no veo, o no sé ver, nada alarmante. ¿Cómo puedo saber los que deberían ejecutarse?
En fin, y en mi opinión, hacen falta más pistas......
** Dime e intentaré aportarlas, pero como el error tarda en reproducirse... estoy a la espera.... -- ---- Josep M Solé
** Pensando un poco si este error sigue algun tipo de pauta, puedo decir que reaparece entre 48 y 72 horas.
Hay algún proceso en el cron que se ejecute cada 48-72 horas ??
** Me aparece el siguiente error: Oct 20 21:04:28 server python: hp-systray[3583]: error: option -s not recognized
No creo que tenga relación, HP-Systray es un script escrito en Python que, me parece, se usa de forma predeterminada con GNOME.
** Ya pero no puedo guardar nada y no sé cuál debe estar . Ejecuto ps -aef, que sí que funciona, pero no veo, o no sé ver, nada alarmante. ¿Cómo puedo saber los que deberían ejecutarse?
Comparando la salida que da mientras funciona correctamente con la que obtengas al producirse la incidencia.
** Dime e intentaré aportarlas, pero como el error tarda en reproducirse... estoy a la espera....
Aumenta el nivel de depuración de los mensajes de error del kernel. Otra cosa, haz un "memtest" pero lo más largo posible, ya que si el problema es de memoria, puede tardar muchas horas en producirse. Para descartar que se trate de un problema con la targeta y/o el entorno gráfico, tambien podrias intentar prescindir del entorno gráfico, dejando el sistema en init 3 durante 4-5 días. a ver que pasa.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-21 a las 09:46 +0200, J.M.Queralt escribió:
** Me aparece el siguiente error: Oct 20 21:04:28 server python: hp-systray[3583]: error: option -s not recognized
No creo que tenga relación, HP-Systray es un script escrito en Python que, me parece, se usa de forma predeterminada con GNOME.
No, es el programa de control de las impresoras HP (¿scanners tb?). - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj9snUACgkQtTMYHG2NR9URVwCeJvPsDj88S4EGJqjeTIsxAodG VtgAn0hb/bnUBKJB40ZxJywtW18hdhjq =EA23 -----END PGP SIGNATURE-----
El día 21 de octubre de 2008 8:44, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-10-21 a las 09:46 +0200, J.M.Queralt escribió:
** Me aparece el siguiente error: Oct 20 21:04:28 server python: hp-systray[3583]: error: option -s not recognized
No creo que tenga relación, HP-Systray es un script escrito en Python que, me parece, se usa de forma predeterminada con GNOME.
No, es el programa de control de las impresoras HP (¿scanners tb?).
No digo que no exista ese problema, pero la temperatura del micro es demasiado elevada, y con 5° C mas que aumente por cualquier causa, se cuelga. Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El día 21 de octubre de 2008 8:44, Carlos E. R. <> escribió:
El 2008-10-21 a las 09:46 +0200, J.M.Queralt escribió:
** Me aparece el siguiente error: Oct 20 21:04:28 server python: hp-systray[3583]: error: option -s not recognized
No creo que tenga relación, HP-Systray es un script escrito en Python que, me parece, se usa de forma predeterminada con GNOME.
No, es el programa de control de las impresoras HP (¿scanners tb?).
No digo que no exista ese problema, pero la temperatura del micro es demasiado elevada, y con 5° C mas que aumente por cualquier causa, se cuelga.
Oye, que yo no he dicho que HP-Systray sea un problema, ni que la temperatura no sea un problema. Fíjate bien. Por otra parte, fíjate que no es un cuelgue completo: sigue pudiendo ejecutar algunos programas, y otros se quedan en espera indefinida: ¿Son esos los sintomas de un cuelgue por temperatura? No digo que no tenga problemas de temperatura, ni que los tenga, pero los sintomas no parecen de eso. Por temperatura se apaga todo y te deja frito, mientras que su máquina sigue funcionando. El que unos programas funcionen y otros no, quedandose en espera infinta, más parece un conflicto del kernel por obtener algún recurso. ¿Puede la cpu apagarse parcialmente por temperatura? - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj9vYMACgkQtTMYHG2NR9XbMwCgiOOMY0oNOqMeyF+4LTeH1NAS xLAAn1iDDY12YJWgtkmrxRLGmSMzFUgy =Jajs -----END PGP SIGNATURE-----
El 21/10/08, Carlos E. R. escribió:
Oye, que yo no he dicho que HP-Systray sea un problema, ni que la temperatura no sea un problema. Fíjate bien.
No Carlos, yo tampoco creo que sea culpa de HP-Systray... (je, je...) :-P :-P >:-P
Por otra parte, fíjate que no es un cuelgue completo: sigue pudiendo ejecutar algunos programas, y otros se quedan en espera indefinida: ¿Son esos los sintomas de un cuelgue por temperatura?
No suele serlo. Pero como el equipo tiene años, es posible que en caso de sobrecalentarse, no le pite y se apague directamente o tenga síntomas raros como los que tiene. Aún así, el micro es AMD (estufas por definición :-P) y su modelo concreto permite una media de temperatura de 85º-90º y el suyo no llega a los 70º...
El que unos programas funcionen y otros no, quedandose en espera infinta, más parece un conflicto del kernel por obtener algún recurso. ¿Puede la cpu apagarse parcialmente por temperatura?
Apagarse parcialmente no sé, pero ralentizar el sistema sí. Pero si fuera por exceso de calor, el síntoma le aparecería a lo largo del día, no cada 2 / 3 días :-? ¿No era recompilando el kernel como se ponía a prueba ésto de los calores? >:-) Yo sigo apostando por la memoria... ¡hagan sus apuestas, señores! :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-21 a las 14:13 +0200, Camaleón escribió:
El 21/10/08, Carlos E. R. escribió:
Oye, que yo no he dicho que HP-Systray sea un problema, ni que la temperatura no sea un problema. Fíjate bien.
No Carlos, yo tampoco creo que sea culpa de HP-Systray...
(je, je...)
:-P :-P >:-P
X'-)
Por otra parte, fíjate que no es un cuelgue completo: sigue pudiendo ejecutar algunos programas, y otros se quedan en espera indefinida: ¿Son esos los sintomas de un cuelgue por temperatura?
No suele serlo.
Pero como el equipo tiene años, es posible que en caso de sobrecalentarse, no le pite y se apague directamente o tenga síntomas raros como los que tiene.
Mmmm... ?
Aún así, el micro es AMD (estufas por definición :-P) y su modelo concreto permite una media de temperatura de 85º-90º y el suyo no llega a los 70º...
Lo pensé, pero me faltó comprobarlo.
El que unos programas funcionen y otros no, quedandose en espera infinta, más parece un conflicto del kernel por obtener algún recurso. ¿Puede la cpu apagarse parcialmente por temperatura?
Apagarse parcialmente no sé, pero ralentizar el sistema sí. Pero si fuera por exceso de calor, el síntoma le aparecería a lo largo del día, no cada 2 / 3 días :-?
Claro. Bueno, es que un mecanismo de defensa del sistema operativo o de la cpu ante el exceso de temperatura puede ser bajar la frecuencia de reloj o incluso meter pausas en el procesador. Imaginate un portatil: la temperatura sube, pues puedes encender o acelerar el ventilador - lo cual supone más gasto de bateria - o moderar la velocidad de la cpu y/o la carga de trabajo. Puede ser una medida ajustable e inteligente. Puedes poner el ventilador, y si sigue subiendo, actuar sobre la carga. Depende de la situación y de los criterios. Ahora bien, ¿existe esto? Pues no lo se. ¿Si existe, podría dar esos sintomas? Vaya usted a saber.
¿No era recompilando el kernel como se ponía a prueba ésto de los calores? >:-)
Si, es una de las maneras.
Yo sigo apostando por la memoria... ¡hagan sus apuestas, señores! :-)
Pero parece raro... - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj910kACgkQtTMYHG2NR9VRqgCfYQfH3mwku4vKhKy853ZBCYgX whIAnjwK5t7BmJyzqU2Is6vKpw9VVtko =QhfU -----END PGP SIGNATURE-----
Por otra parte, fíjate que no es un cuelgue completo: sigue pudiendo ejecutar algunos programas, y otros se quedan en espera indefinida: ¿Son esos los sintomas de un cuelgue por temperatura?
No suele serlo.
Pero como el equipo tiene años, es posible que en caso de sobrecalentarse, no le pite y se apague directamente o tenga síntomas raros como los que tiene.
Sea lo que sea lo que produce los cuelgues, la temperatura de ese equipo está muy mal y si no es la causa principal del problema es muy probable que esté relacionado.
Aún así, el micro es AMD (estufas por definición :-P) y su modelo concreto permite una media de temperatura de 85º-90º y el suyo no llega a los 70º...
Los AMDs como los Intel sólo son estufas si nos les das buena
refrigeración. Yo tengo un Athlon64 2000MHz...
mauricio@xxxxxxxxxxx:~$ sensors
k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp: +32.0°C
Core1 Temp: +32.0°C
Ciertamente no es un problema de AMD, sino del mantenimiento que se le
dé.
Saludos.
--
Mauricio J. Adonis C.
Mauricio> Sea lo que sea lo que produce los cuelgues, la temperatura de ese equipo Mauricio> está muy mal y si no es la causa principal del problema es muy probable Mauricio> que esté relacionado. Creo que no tienes razón. El AMD se desconectaría sobre los 90 º por lo que 65-70 no es nada alarmante. Por otro lado si estuviera delante de un problema de temperatura, le desconectaría la placa, y él se queja de que puede ejecutar comandos en cónsola, por lo que no es el caso.
El mar, 21-10-2008 a las 21:56 +0200, J.M.Queralt escribió:
Mauricio> Sea lo que sea lo que produce los cuelgues, la temperatura de ese equipo Mauricio> está muy mal y si no es la causa principal del problema es muy probable Mauricio> que esté relacionado.
Creo que no tienes razón. El AMD se desconectaría sobre los 90 º por lo que 65-70 no es nada alarmante.
Por otro lado si estuviera delante de un problema de temperatura, le desconectaría la placa, y él se queja de que puede ejecutar comandos en cónsola, por lo que no es el caso.
Por mal me refiero a que está fuera de los rangos habituales. Sin saber
exactamente que está corriendo en su equipo, ni en qué medio ambiente,
esa tª, aún sin ser necesariamente alarmante, es anormal para ese
procesador (Los Athlon son «carne de cañón» son extremadamente
resistentes al mal trato, que lo diga el mío que en una ocasión llegó a
un peak superior a 100º, por culpa mía. Quizás un record Guinness). 90º
es un máximo de laboratorio, en la práctica éstos no suelen ni acercarse
a esos valores, siempre que cuenten con una correcta disipación de
calor.
Quizás la tª no es la causa de los cuelgues, sin embargo a ese equipo le
hace falta una manito de gato, todos sabemos que cuando el bebé llora es
porque está pidiendo atención...
Saludos.
--
Mauricio J. Adonis C.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-21 a las 17:59 -0300, Mauricio J. Adonis C. escribió:
Por mal me refiero a que está fuera de los rangos habituales. Sin saber exactamente que está corriendo en su equipo, ni en qué medio ambiente, esa tª, aún sin ser necesariamente alarmante, es anormal para ese procesador (Los Athlon son «carne de cañón» son extremadamente resistentes al mal trato, que lo diga el mío que en una ocasión llegó a un peak superior a 100º, por culpa mía. Quizás un record Guinness). 90º es un máximo de laboratorio, en la práctica éstos no suelen ni acercarse a esos valores, siempre que cuenten con una correcta disipación de calor.
No, en absoluto, eso es un error. Puede interesar, por decisión técnica consciente, hacer que el chip trabaje a la mayor temperatura posible, por la sencilla razón de que aumenta el rendimiento del disipador y puedes bajar la velocidad del ventilador, y por tanto el consumo global del equipo y su ruido. En chips, cuanta más alta sea la temperatura admisible, mejor... ...Y que es distinto de, cuanta más baja sea la disipación (las pérdidas), mejor. Y que a más baja temperatura, menor "sufrimiento": pero eso también es relativo, porque no tiene interés garantizar una vida media del chip de 100 años, sino que 10 pueden ser suficientes y de sobra. Lo mismo que no interesan neumaticos que aguanten 20 años... - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj+VEAACgkQtTMYHG2NR9XkhQCfWNi32C9IOy6u6NhuHq0Ya1uF nqEAn34ryRPKCE2hvl72PRJZ6LhE3z36 =+N1J -----END PGP SIGNATURE-----
El día 21 de octubre de 2008 20:14, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-10-21 a las 17:59 -0300, Mauricio J. Adonis C. escribió:
Por mal me refiero a que está fuera de los rangos habituales. Sin saber exactamente que está corriendo en su equipo, ni en qué medio ambiente, esa tª, aún sin ser necesariamente alarmante, es anormal para ese procesador (Los Athlon son «carne de cañón» son extremadamente resistentes al mal trato, que lo diga el mío que en una ocasión llegó a un peak superior a 100º, por culpa mía. Quizás un record Guinness). 90º es un máximo de laboratorio, en la práctica éstos no suelen ni acercarse a esos valores, siempre que cuenten con una correcta disipación de calor.
No, en absoluto, eso es un error.
Puede interesar, por decisión técnica consciente, hacer que el chip trabaje a la mayor temperatura posible, por la sencilla razón de que aumenta el rendimiento del disipador y puedes bajar la velocidad del ventilador, y por tanto el consumo global del equipo y su ruido.
En chips, cuanta más alta sea la temperatura admisible, mejor...
...Y que es distinto de, cuanta más baja sea la disipación (las pérdidas), mejor. Y que a más baja temperatura, menor "sufrimiento": pero eso también es relativo, porque no tiene interés garantizar una vida media del chip de 100 años, sino que 10 pueden ser suficientes y de sobra.
Lo mismo que no interesan neumaticos que aguanten 20 años...
Una cosa es la temperatura maxima de destrucción o deterioro del chip, y otra cosa es la temperatura maxima de trabajo aconsejada por el fabricante. Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-21 a las 20:16 -0200, Juan Erbes escribió:
Una cosa es la temperatura maxima de destrucción o deterioro del chip, y otra cosa es la temperatura maxima de trabajo aconsejada por el fabricante.
Claro. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj+WhoACgkQtTMYHG2NR9VKfACffROhIjMBhhtMbJIowM5ccW8v WJwAoJTVjM8fP2vnSFlb/GujoJYMivD2 =T4Bd -----END PGP SIGNATURE-----
No, en absoluto, eso es un error.
Puede interesar, por decisión técnica consciente, hacer que el chip trabaje a la mayor temperatura posible, por la sencilla razón de que aumenta el rendimiento del disipador y puedes bajar la velocidad del ventilador, y por tanto el consumo global del equipo y su ruido.
Eso sería muy raro, ya que al aumentar la temperatura del procesador la placa madre sube las revoluciones del ventilador y no al revés, por lo tanto sube el consumo eléctrico. Según he visto ningún manual de mantenimiento de computadores habla de la «conveniencia» tener funcionando el procesador a altas temperaturas; se habla de aumentar el rendimiento del procesador... overclockearlo si se quiere pero siempre manteniéndolo a la temperatura más baja posible y la razón es muy evidente, los semiconductores (de Silicio y/o Germanio) del procesador disminuyen su rendimiento a mayor temperatura (el mismo procesador no rinde lo mismo a 30º que a 70º) perdiendo conductividad, lo cual suele producir cuelques o errores o daños de otro tipo.
En chips, cuanta más alta sea la temperatura admisible, mejor...
¿mejor para qué? ¿desde qué punto de vista?
...Y que es distinto de, cuanta más baja sea la disipación (las pérdidas), mejor. Y que a más baja temperatura, menor "sufrimiento": pero eso también es relativo, porque no tiene interés garantizar una vida media del chip de 100 años, sino que 10 pueden ser suficientes y de sobra.
Lo mismo que no interesan neumaticos que aguanten 20 años...
Otra rara suposición... créame, si yo pudiera hacer que los neumáticos
del auto me duraran 20 años en buen estado... ¡lo haría!... ¡si le
cambiaba neumáticos cada 2 años, me ahorraría hasta 9 juegos de
neumáticos! Puede que haya gente que cambia el auto cada 4 o 5 años,
pero si no se tiene otra opción por los próximos 20 años, pues esa es la
mejor opción.
Quizás en una empresa cuando se le quema el procesador de uno de sus 200
equipos sencillamente cambian el chip (o hasta el computador) y denuevo
a la pelea... pero para muchos usuarios de casa (me cuento) perder el
procesador, si bien no es una pérdida irreparable, si es una pérdida que
incomoda mucho, por lo tanto yo lo cuido tanto como puedo.
Saludos.
--
Mauricio J. Adonis C.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-22 a las 10:05 -0300, Mauricio J. Adonis C. escribió:
No, en absoluto, eso es un error.
Puede interesar, por decisión técnica consciente, hacer que el chip trabaje a la mayor temperatura posible, por la sencilla razón de que aumenta el rendimiento del disipador y puedes bajar la velocidad del ventilador, y por tanto el consumo global del equipo y su ruido.
Eso sería muy raro, ya que al aumentar la temperatura del procesador la placa madre sube las revoluciones del ventilador y no al revés, por lo tanto sube el consumo eléctrico. Según he visto ningún manual de
No lo entiendes. Yo hablo como diseñador, como ingeniero, no como usuario. Al diseñar, prefiero un chip que funcione a 200 grados, porque a esa temperatura la corriente de aire por convección es suficiente sin necesidad de ventilador. Date cuenta que no es lo mismo temperatura de trabajo alta que consumo alto. De otra forma: la eficacia de los radiadores sube con la temperatura. Así, diseño para, digamos, una temperatura de 70 grados, activo el ventilador a partir de los 80, y paro la cpu por alarma a los 90. Por ejemplo. Si, dado ese mismo chip que aguanta hasta 90, me empeño en mantenerlo a 50, pues tengo que tener un ventilador fuerte todo el rato, con lo que consumo más en el ventilador.
mantenimiento de computadores habla de la «conveniencia» tener funcionando el procesador a altas temperaturas; se habla de aumentar el rendimiento del procesador... overclockearlo si se quiere pero siempre manteniéndolo a la temperatura más baja posible y la razón es muy evidente, los semiconductores (de Silicio y/o Germanio) del procesador disminuyen su rendimiento a mayor temperatura (el mismo procesador no rinde lo mismo a 30º que a 70º) perdiendo conductividad, lo cual suele producir cuelques o errores o daños de otro tipo.
Ojo. Esa perdida de rendimiento sólo me importa si voy a "overclokear" el chip. Si el fabricante ha especificado una temperatura máxima de funcionamiento de 90 grados, te aseguro que funcionará a la misma velocidad en tu placa a 20 grados que a 90. ¡Pero! Si quiero aumentar la velocidad por encima de la que ha especificado el fabricante, entonces sí que debo bajar la temperatura.
En chips, cuanta más alta sea la temperatura admisible, mejor...
¿mejor para qué? ¿desde qué punto de vista?
Me facilita el diseño. Si un chip sólo me admite 20 grados es horrible, porque necesito un firgorífico para hacerlo funcionar.
Lo mismo que no interesan neumaticos que aguanten 20 años...
Otra rara suposición... créame, si yo pudiera hacer que los neumáticos del auto me duraran 20 años en buen estado... ¡lo haría!... ¡si le cambiaba neumáticos cada 2 años, me ahorraría hasta 9 juegos de neumáticos! Puede que haya gente que cambia el auto cada 4 o 5 años, pero si no se tiene otra opción por los próximos 20 años, pues esa es la mejor opción.
En buen estado, ojo. Real, no aparente. Porque yo consigo hacer durar los neumáticos unos cienmil kilometros, así que con un coche de domingos para ir a misa te aseguro que me durarían esos veinte años. ¿Problema? Que estarían duros, con poca adherencia, frágiles...
Quizás en una empresa cuando se le quema el procesador de uno de sus 200 equipos sencillamente cambian el chip (o hasta el computador) y denuevo a la pelea... pero para muchos usuarios de casa (me cuento) perder el procesador, si bien no es una pérdida irreparable, si es una pérdida que incomoda mucho, por lo tanto yo lo cuido tanto como puedo.
Claro. Pero muy poca gente usa el mismo procesador durante veinte años. Los calculan para unuso habitual de 5, aunque duran mucho más. Dudo que realmente se atrevan a garantizar el funcionamiento de una cpu "de consumo" durante 25 años. Eso es lo que quiero decir, que no es una electrónica "para la eternidad", en cuyo caso especificarían una temperatura de trabajo más baja. ¿Que más me da si trabajando a 100 grados sólo me garantizan 10 años, si a los 5 lo voy a tirar? - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj/O3MACgkQtTMYHG2NR9Ws/ACfZHKziRdUgNsJC4FkjaKDTPEl TEQAn2TCySem0z3UBA5Ms28qq7QgxOVW =XILw -----END PGP SIGNATURE-----
El Tuesday 21 October 2008 19:44:51 Mauricio J. Adonis C. escribió:
Por otra parte, fíjate que no es un cuelgue completo: sigue pudiendo ejecutar algunos programas, y otros se quedan en espera indefinida: ¿Son esos los sintomas de un cuelgue por temperatura?
No suele serlo.
Pero como el equipo tiene años, es posible que en caso de sobrecalentarse, no le pite y se apague directamente o tenga síntomas raros como los que tiene.
Sea lo que sea lo que produce los cuelgues, la temperatura de ese equipo está muy mal y si no es la causa principal del problema es muy probable que esté relacionado.
Aún así, el micro es AMD (estufas por definición :-P) y su modelo concreto permite una media de temperatura de 85º-90º y el suyo no llega a los 70º...
Los AMDs como los Intel sólo son estufas si nos les das buena refrigeración. Yo tengo un Athlon64 2000MHz...
mauricio@xxxxxxxxxxx:~$ sensors k8temp-pci-00c3 Adapter: PCI adapter Core0 Temp: +32.0°C Core1 Temp: +32.0°C
Ciertamente no es un problema de AMD, sino del mantenimiento que se le dé.
Saludos.
-- Mauricio J. Adonis C.
**Creo que no es tema de temperatura. Ya veremos, pero en la página siguiente hay una media de temperatura de algunos procesadores: http://www.computerhope.com/issues/ch000687.htm -- ---- Josep M Solé
El Tuesday 21 October 2008 14:13:52 Camaleón escribió:
El 21/10/08, Carlos E. R. escribió:
Oye, que yo no he dicho que HP-Systray sea un problema, ni que la temperatura no sea un problema. Fíjate bien.
No Carlos, yo tampoco creo que sea culpa de HP-Systray...
(je, je...)
:-P :-P >:-P :
Por otra parte, fíjate que no es un cuelgue completo: sigue pudiendo ejecutar algunos programas, y otros se quedan en espera indefinida: ¿Son esos los sintomas de un cuelgue por temperatura?
No suele serlo.
Pero como el equipo tiene años, es posible que en caso de sobrecalentarse, no le pite y se apague directamente o tenga síntomas raros como los que tiene.
Aún así, el micro es AMD (estufas por definición :-P) y su modelo concreto permite una media de temperatura de 85º-90º y el suyo no llega a los 70º...
** Eso creo. Aquí va una tabla que lo situaría dentro de la normalidad: http://www.computerhope.com/issues/ch000687.htm
El que unos programas funcionen y otros no, quedandose en espera infinta, más parece un conflicto del kernel por obtener algún recurso. ¿Puede la cpu apagarse parcialmente por temperatura?
Apagarse parcialmente no sé, pero ralentizar el sistema sí. Pero si fuera por exceso de calor, el síntoma le aparecería a lo largo del día, no cada 2 / 3 días :-?
**No se ralentiza el sistema, simplemente se cuelga.
¿No era recompilando el kernel como se ponía a prueba ésto de los calores?
:-)
**No lo voy a probar. No quiero crearme más problemas ;-)
Yo sigo apostando por la memoria... ¡hagan sus apuestas, señores! :-)
** ¿Cuanto tiempo es preciso pasar el memtest?
Saludos,
-- Camaleón
-- ---- Josep M Solé
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-22 a las 08:16 +0200, Josep M Solé Valls escribió:
Yo sigo apostando por la memoria... ¡hagan sus apuestas, señores! :-)
** ¿Cuanto tiempo es preciso pasar el memtest?
Pues un dia estaría bien, han dicho otras veces. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj+6iQACgkQtTMYHG2NR9UyNgCfWTLmLZiKM+lFvBXCXkowB64N zMAAnjx+PfCo3dZfpk2zrOUUmUQNjamB =to9y -----END PGP SIGNATURE-----
El Tuesday 21 October 2008 12:44:00 Carlos E. R. escribió:
El 2008-10-21 a las 09:46 +0200, J.M.Queralt escribió:
** Me aparece el siguiente error: Oct 20 21:04:28 server python: hp-systray[3583]: error: option -s not recognized
No creo que tenga relación, HP-Systray es un script escrito en Python que, me parece, se usa de forma predeterminada con GNOME.
No, es el programa de control de las impresoras HP (¿scanners tb?).
**Eso creo, aparentemente funciona bien. -- ---- Josep M Solé
El Tuesday 21 October 2008 12:44:00 Carlos E. R. escribió:
El 2008-10-21 a las 09:46 +0200, J.M.Queralt escribió:
** Me aparece el siguiente error: Oct 20 21:04:28 server python: hp-systray[3583]: error: option -s not recognized
No creo que tenga relación, HP-Systray es un script escrito en Python que, me parece, se usa de forma predeterminada con GNOME.
No, es el programa de control de las impresoras HP (¿scanners tb?).
**Sí, eso creo. Aparentemente la impresora y el escaner - excepto lo del calibrado (ver lista)- funciona bien. -- ---- Josep M Solé
No creo que tenga relación, HP-Systray es un script escrito en Python que, me parece, se usa de forma predeterminada con GNOME.
No, es el programa de control de las impresoras HP (¿scanners tb?).
**Sí, eso creo. Aparentemente la impresora y el escáner (excepto el tema del calibrado -ver lista-) funciona correctamente. -- ---- Josep M Solé
El Tuesday 21 October 2008 09:46:39 J.M.Queralt escribió:
** Pensando un poco si este error sigue algun tipo de pauta, puedo decir que reaparece entre 48 y 72 horas.
Hay algún proceso en el cron que se ejecute cada 48-72 horas ??
** Me aparece el siguiente error: Oct 20 21:04:28 server python: hp-systray[3583]: error: option -s not recognized
No creo que tenga relación, HP-Systray es un script escrito en Python que, me parece, se usa de forma predeterminada con GNOME.
*** Yo lo relaciono con la impresora/escáner por ahora funciona (ya lo revisaré.
** Ya pero no puedo guardar nada y no sé cuál debe estar . Ejecuto ps -aef, que sí que funciona, pero no veo, o no sé ver, nada alarmante. ¿Cómo puedo saber los que deberían ejecutarse?
Comparando la salida que da mientras funciona correctamente con la que obtengas al producirse la incidencia.
*** He guardado un informe en condiciones normales, estoy esperando el cuelgue.
** Dime e intentaré aportarlas, pero como el error tarda en reproducirse... estoy a la espera....
Aumenta el nivel de depuración de los mensajes de error del kernel.
Otra cosa, haz un "memtest" pero lo más largo posible, ya que si el problema es de memoria, puede tardar muchas horas en producirse.
***He hecho uno de unas 3 horas: nada.
Para descartar que se trate de un problema con la targeta y/o el entorno gráfico, tambien podrias intentar prescindir del entorno gráfico, dejando el sistema en init 3 durante 4-5 días. a ver que pasa.
-- ---- Josep M Solé
El 20/10/08, Josep M Solé Valls escribió:
Con estos síntomas ¿Por dónde puedo intentar buscar la solución?
Explica un poco qué tienes en ese equipo (en cuanto a software y hardware) qué carga de trabajo tiene, qué uso le das, etc... En alguna ocasión ha salido este tema de los cuelgues aleatorios y que no dejan rastro y por lo general, los culpables suelen ser: a) ¡¡ReiserFS, ReiserFS!! :-P b) Calor (pero si no pita, descartado) c) Algún componente crítico que falla (procesador, módulo de memoria o fuente de alimentación) d) Algún bug del kernel que te esté mordiendo ¿Has intentado iniciar una sesión vía ssh cuando se cuelga para descartar cualquier problema relacionado con el entono gráfico? :-? ¿Te saca algo "dmesg" en el momento del cuelgue inminente? ¿hay algún patrón de cuelgue (por ejemplo, a la misma hora del día)? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Monday 20 October 2008 20:20:40 Camaleón escribió:
El 20/10/08, Josep M Solé Valls escribió:
Con estos síntomas ¿Por dónde puedo intentar buscar la solución?
Explica un poco qué tienes en ese equipo (en cuanto a software y hardware) qué carga de trabajo tiene, qué uso le das, etc...
** Procesador (CPU): AMD Athlon(tm) XP 2800+ Velocidad: 2075,06 MHz Temperatura: 69°C Memoria total (RAM): 1010,6 MB Memoria disponible: 337,9 MB (+ 384,7 MB cachés) Espacio de intercambio disponible: 1,0 GB Fabricante: nVidia Corporation Modelo: GeForce FX 5200 Controlador: nvidia SO: Linux 2.6.25.16-0.1-pae i686 Sistema: openSUSE 11.0 (i586) KDE: 3.5.9 "release 49.1"
En alguna ocasión ha salido este tema de los cuelgues aleatorios y que no dejan rastro y por lo general, los culpables suelen ser:
a) ¡¡ReiserFS, ReiserFS!! :-P
b) Calor (pero si no pita, descartado) ** No pita. c) Algún componente crítico que falla (procesador, módulo de memoria o fuente de alimentación) ** Es un cuelgue con mucho "delay" ( en un principio sospeché de la memoria,
** No: ext3 però después de un par de horas de memtest no dio nada)
d) Algún bug del kernel que te esté mordiendo
**Lo tengo actualizado
¿Has intentado iniciar una sesión vía ssh cuando se cuelga para descartar cualquier problema relacionado con el entono gráfico? :-?
**Sí, fue imposible.
¿Te saca algo "dmesg" en el momento del cuelgue inminente? ¿hay algún patrón de cuelgue (por ejemplo, a la misma hora del día)?
** Si, parece que se reproduce entre 48 y 72 horas.
Saludos,
-- Camaleón
-- ---- Josep M Solé
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-20 a las 21:50 +0200, Josep M Solé Valls escribió:
Fabricante: nVidia Corporation Modelo: GeForce FX 5200 Controlador: nvidia
¿Usas el driver abierto o el cerrado?
** No: ext3
¿Alguna partición encriptada? Ejecuta un fsck y un badblocks.
d) Algún bug del kernel que te esté mordiendo
**Lo tengo actualizado
Yo también pienso en el kernel. Aumenta la verbosidad de su log; /etc/sysconfig/syslog KERNEL_LOGLEVEL=7
¿Has intentado iniciar una sesión vía ssh cuando se cuelga para descartar cualquier problema relacionado con el entono gráfico? :-?
**Sí, fue imposible.
Sin embargo, sí puedes ejecutar algunos comandos, imagino que en consola, y que algunos se paran. ¿Sabes cuales? Podrías intentar reinstalar esos que fallan, por si estuvieran corruptos. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj87v4ACgkQtTMYHG2NR9VlogCgkiEfTVbintrwCMuVp2ec5iQa TzUAmwYIWK42HqtYwrtrWV6x0opm1xd1 =rWli -----END PGP SIGNATURE-----
El Monday 20 October 2008 22:50:03 Carlos E. R. escribió:
El 2008-10-20 a las 21:50 +0200, Josep M Solé Valls escribió:
Fabricante: nVidia Corporation Modelo: GeForce FX 5200 Controlador: nvidia
¿Usas el driver abierto o el cerrado?
** No: ext3
¿Alguna partición encriptada?
Ejecuta un fsck y un badblocks.
d) Algún bug del kernel que te esté mordiendo
**Lo tengo actualizado
Yo también pienso en el kernel. Aumenta la verbosidad de su log;
/etc/sysconfig/syslog
KERNEL_LOGLEVEL=7
***Hecho, estoy esperando que se cuelgue.
¿Has intentado iniciar una sesión vía ssh cuando se cuelga para descartar cualquier problema relacionado con el entono gráfico? :-?
**Sí, fue imposible.
Sin embargo, sí puedes ejecutar algunos comandos, imagino que en consola, y que algunos se paran. ¿Sabes cuales? Podrías intentar reinstalar esos que fallan, por si estuvieran corruptos.
***Cuando no está colgado funcionan perfectamente. -- ---- Josep M Solé
El Monday 20 October 2008 22:50:03 Carlos E. R. escribió:
El 2008-10-20 a las 21:50 +0200, Josep M Solé Valls escribió:
Fabricante: nVidia Corporation Modelo: GeForce FX 5200 Controlador: nvidia
¿Usas el driver abierto o el cerrado?
*** Creo que es el cerrado NVidia (¿el libre era nv?). ¿Puede esto afectar a la los comandos en consola, en un init 5? Al instalar el driver, me dió un error la tarjeta gráfica y por ello instalé el cerrado.
Sin embargo, sí puedes ejecutar algunos comandos, imagino que en consola, y que algunos se paran. ¿Sabes cuales? Podrías intentar reinstalar esos que fallan, por si estuvieran corruptos.
***Que haya comprobado: No funcionan: man, ls, cd, mkdir, shutdown, halt, cat, tail, ... Funcionan: ps, top, poweroff... ***El jueves se volvió ha colgar, la anterior vez había sido el domingo o lunes. Pasé durante más de 13 horas el memtest y no sacó ningún error. Me inclino a pensar que tiene que ver con el driver gráfico, si es que éste puede afectar a los anteriores comandos. Como el driver de nvidia me dió ya trabajo durante la instalación, le tengo un poco de respeto, aunque creo que toca cambiarlo por el libre y más aún en un servidor. ¿Voy bien? -- ---- Josep M Solé
El 25/10/08, Josep M Solé Valls escribió:
***El jueves se volvió ha colgar, la anterior vez había sido el domingo o lunes. Pasé durante más de 13 horas el memtest y no sacó ningún error.
No estoy segura, pero creo que el memtest sólo analiza los módulos de memoria. Si tienes un problema con el zócalo de la placa (dañado o al que le llega un voltaje incorrecto) podría ser problemático.
Me inclino a pensar que tiene que ver con el driver gráfico, si es que éste puede afectar a los anteriores comandos.
Eso ya no lo sé. Pero el intervalo de tiempo entre fallos se me antoja demasiado largo :-/
Como el driver de nvidia me dió ya trabajo durante la instalación, le tengo un poco de respeto, aunque creo que toca cambiarlo por el libre y más aún en un servidor.
¿Voy bien?
No te sabría decir una forma sencilla de cambiar los controladores (nvidia por nv). Quizá desde el /etc/sysconfig puedas determinar cuál quieres cargar al inicio :-? Pero antes de eso, yo probaría a iniciar el equipo sin entorno gráfico, desde init 3. ¿Necesitas tener cargado un entorno gráfico en ese servidor? :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El Monday 20 October 2008 22:50:03 Carlos E. R. escribió:
El 2008-10-20 a las 21:50 +0200, Josep M Solé Valls escribió:
Fabricante: nVidia Corporation Modelo: GeForce FX 5200 Controlador: nvidia
¿Usas el driver abierto o el cerrado?
*** Creo que es el cerrado NVidia (¿el libre era nv?). ¿Puede esto afectar a la los comandos en consola, en un init 5?
A los comandos, no, que yo sepa. A colgar el ordenador, sí.
Al instalar el driver, me dió un error la tarjeta gráfica y por ello instalé el cerrado.
Sin embargo, sí puedes ejecutar algunos comandos, imagino que en consola, y que algunos se paran. ¿Sabes cuales? Podrías intentar reinstalar esos que fallan, por si estuvieran corruptos.
***Que haya comprobado: No funcionan: man, ls, cd, mkdir, shutdown, halt, cat, tail, ... Funcionan: ps, top, poweroff...
Creo que los primeros tienen que acceder más al disco... Lo primero que he mirado es si unos están en /usr y otros no, pero están mezclados. Pero man tiene que buscar unas bases de datos en disco; cd cambiar de directorio, buscandolo; ls listar directorio; mkdir crear directorio... ps en cambio funciona contra la tabla de procesos. Eso huele a problema de disco duro, así que el siguiente paso son las pruebas SMART de disco: empieza por la corta y continua por la larga. ¿Dijiste que sistema de ficheros usas? Si es reiser, hazle un fsck desde el dvd de rescate. ¿Supongo que lo tienes actualizado?
***El jueves se volvió ha colgar, la anterior vez había sido el domingo o lunes. Pasé durante más de 13 horas el memtest y no sacó ningún error. Me inclino a pensar que tiene que ver con el driver gráfico, si es que éste puede afectar a los anteriores comandos.
Como el driver de nvidia me dió ya trabajo durante la instalación, le tengo un poco de respeto, aunque creo que toca cambiarlo por el libre y más aún en un servidor.
¿Voy bien?
Huele a disco. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkC9VYACgkQtTMYHG2NR9UaLgCfXQoKqC6Mj5I++laC3Vk7u9rf ZlYAn0UOzzdnmQTMAHSEixLPfYO13ulz =6LeU -----END PGP SIGNATURE-----
El Saturday 25 October 2008 12:30:38 Carlos E. R. escribió:
Content-ID:
Eso huele a problema de disco duro, así que el siguiente paso son las pruebas SMART de disco: empieza por la corta y continua por la larga.
**Vale.
¿Dijiste que sistema de ficheros usas? Si es reiser, hazle un fsck desde el dvd de rescate.
**No, es ext3.
¿Supongo que lo tienes actualizado?
**¿Te refieres al sitema? sí.
Huele a disco.
Me pongo con el SMART. -- ---- Josep M Solé
Josep M Solé Valls vàreu escriure:
El Saturday 25 October 2008 12:30:38 Carlos E. R. escribió:
Content-ID:
Eso huele a problema de disco duro, así que el siguiente paso son las pruebas SMART de disco: empieza por la corta y continua por la larga.
**Vale.
¿Dijiste que sistema de ficheros usas? Si es reiser, hazle un fsck desde el dvd de rescate.
**No, es ext3.
¿Supongo que lo tienes actualizado?
**¿Te refieres al sitema? sí.
Huele a disco.
Me pongo con el SMART.
¿Has probado a activar las sysrq? http://en.wikipedia.org/wiki/Magic_SysRq_key Si como dice Carlos parece algo de discos, quizás remontando las particiones en sólo-lectura debería funcionar. Salu2, -- Oscar Curero - Linux user: 306877 -- GPG keyID: 0xE0EA0B24 -- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Saturday 25 October 2008 12:30:38 Carlos E. R. escribió:
Content-ID:
Huele a disco.
**Buen olfato. El smart corto lo ha pasado bien. Durante el smart largo (smartctl -t long /dev/sda) ha vuelto a colgarse el ordenador, saltándose la pauta de los 3 y pico días. Cuando lo he pasado el (smartctl -l selftest -i /dev/sda) ha soltado lo siguiente: === START OF READ SMART DATA SECTION === SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 00% 21411 132185433 # 2 Short offline Completed without error 00% 21410 - Veo que el disco tiene un lifetime "curradito" 2 años y 162 días de trabajo. Entiendo que esto significa que el disco tiene un sector defectuoso. Intento corregirlo o cambio de disco. -- ---- Josep M Solé
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Josep M Solé Valls wrote:
El Saturday 25 October 2008 12:30:38 Carlos E. R. escribió:
Huele a disco.
**Buen olfato.
O:-)
El smart corto lo ha pasado bien. Durante el smart largo (smartctl -t long /dev/sda) ha vuelto a colgarse el ordenador, saltándose la pauta de los 3 y pico días.
Es posible que esperando se descuelgue: hay un error de lectura y se atasca. En realidad no se cuelga del todo, no es cuelgue. Y es posible que el disco te haga ruidos en ese momento.
Cuando lo he pasado el (smartctl -l selftest -i /dev/sda) ha soltado lo siguiente:
=== START OF READ SMART DATA SECTION === SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 00% 21411 132185433 # 2 Short offline Completed without error 00% 21410 -
Veo que el disco tiene un lifetime "curradito" 2 años y 162 días de trabajo.
Entiendo que esto significa que el disco tiene un sector defectuoso. Intento corregirlo o cambio de disco.
Primer paso: apagar. Segundo: comprar otro disco, para hacer un respaldo y trasvaso de datos. Es sábado, y tarde... Después ya haces las pruebas que quieras :-) Si el disco fuera más joven y no fuera un servidor, pues igual podrías jugar un poco más. Pruebas: Descargarte el programa de pruebas de disco del fabricante de ese disco: puede ser un disquete arrancable (msdos) o un CD arrancable. Por ejemplo, el de Seagate es bastante bueno. Lo que hace básicamente es la misma prueba que el SMART, pero bajo control de la CPU, en vez de bajo control del propio disco duro, lo que permite saber mejor qué es lo que falla. Pero dado que a ese disco parece que nunca se le han hecho pruebas... mira en la tabla de estado SMART (-a) cmo está la tabla de redireción de sectores. Si está llena, el disco está para el arrastre. Con --health te dirá algo enseguida. - -- Cheers / Saludos, Carlos E. R. (from 11.1-factory) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkkDeLIACgkQU92UU+smfQUccACdHwjnAEtcBmWMcLticUMMwx2l TWUAn2+blPUbDzCo39jyRQAElHEgi8gy =NJMA -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Saturday 25 October 2008 21:51:14 Carlos E. R. escribió:
Josep M Solé Valls wrote:
Primer paso: apagar. Segundo: comprar otro disco, para hacer un respaldo y trasvaso de datos. Es sábado, y tarde...
**Demasiado tarde. No me queda más que respaldar datos. De todas formas creo que debería clonar el disco sin errores (dd?) puesto que estoy en la 11.0 y las configuraciones són recientes del pasado verano.
Descargarte el programa de pruebas de disco del fabricante de ese disco: puede ser un disquete arrancable (msdos) o un CD arrancable. Por ejemplo, el de Seagate es bastante bueno. Lo que hace básicamente es la misma prueba que el SMART, pero bajo control de la CPU, en vez de bajo control del propio disco duro, lo que permite saber mejor qué es lo que falla.
Pero dado que a ese disco parece que nunca se le han hecho pruebas... mira en la tabla de estado SMART (-a) cmo está la tabla de redireción de sectores. Si está llena, el disco está para el arrastre. Con --health te dirá algo enseguida.
**Observo que el error viene de lejos. Hace tiempo que se produjo, creo entender que muestra los 5 últimos errores "(device log contains only the most recent five errors)". Esto me hace pensar que quizá sea una coincidencia y que el cuelgue se produzca por otros motivos concomitantes. Aquí va el smartctl -a /dev/sda Inicio -------------------------------------------------------------------------------------- server:~ # smartctl -a /dev/sda smartctl 5.39 2008-05-08 21:56 [i686-pc-linux-gnu] (local build) Copyright (C) 2002-8 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Device Model: SAMSUNG SV1203N Serial Number: S01CJ10W826459 Firmware Version: TQ100-23 User Capacity: 120,060,444,672 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: ATA/ATAPI-7 T13 1532D revision 0 Local Time is: Sun Oct 26 11:44:51 2008 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 112) The previous self-test completed having the read element of the test failed. Total time to complete Offline data collection: (3240) seconds. Offline data collection capabilities: (0x1b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. No Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. No General Purpose Logging support. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 54) minutes. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 071 059 000 Pre-fail Always - 5184 4 Start_Stop_Count 0x0032 094 094 000 Old_age Always - 6106 5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 253 253 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0024 253 253 000 Old_age Offline - 0 9 Power_On_Half_Minutes 0x0032 096 096 000 Old_age Always - 21414h+41m 10 Spin_Retry_Count 0x0013 253 253 049 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 097 097 000 Old_age Always - 3511 194 Temperature_Celsius 0x0022 163 100 000 Old_age Always - 25 195 Hardware_ECC_Recovered 0x000a 100 100 000 Old_age Always - 657980373 196 Reallocated_Event_Count 0x0012 100 100 000 Old_age Always - 1 197 Current_Pending_Sector 0x0033 100 100 010 Pre-fail Always - 1 198 Offline_Uncorrectable 0x0031 100 100 010 Pre-fail Offline - 1 199 UDMA_CRC_Error_Count 0x000a 100 100 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0 201 Soft_Read_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0 SMART Error Log Version: 1 ATA Error Count: 673 (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 673 occurred at disk power-on lifetime: 2510 hours (104 days + 14 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 04 51 00 75 c5 02 e0 Error: ABRT Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- ef 85 00 75 c5 02 e0 00 08:54:10.375 SET FEATURES [Disable APM] ef 02 00 00 00 00 e0 00 08:53:32.250 SET FEATURES [Enable write cache] c6 00 10 00 00 00 e0 00 08:53:32.250 SET MULTIPLE MODE 10 00 3f 00 00 00 e0 00 08:53:32.250 RECALIBRATE [OBS-4] 91 00 3f 3f ff 3f e0 00 08:53:32.250 INITIALIZE DEVICE PARAMETERS [OBS-6] Error 672 occurred at disk power-on lifetime: 2510 hours (104 days + 14 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 04 51 00 75 c5 02 e0 Error: ABRT Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- ef 85 00 75 c5 02 e0 00 08:26:25.125 SET FEATURES [Disable APM] ef 02 00 00 00 00 e0 00 08:25:47.375 SET FEATURES [Enable write cache] c6 00 10 00 00 00 e0 00 08:25:47.375 SET MULTIPLE MODE 10 00 3f 00 00 00 e0 00 08:25:47.375 RECALIBRATE [OBS-4] 91 00 3f 3f ff 3f e0 00 08:25:47.375 INITIALIZE DEVICE PARAMETERS [OBS-6] Error 671 occurred at disk power-on lifetime: 2502 hours (104 days + 6 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 04 51 00 55 1d a7 e0 Error: ABRT Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- ef 85 00 55 1d a7 e0 00 00:01:06.375 SET FEATURES [Disable APM] ef 02 00 00 00 00 e0 00 00:00:26.375 SET FEATURES [Enable write cache] c6 00 10 00 00 00 e0 00 00:00:26.375 SET MULTIPLE MODE 10 00 3f 00 00 00 e0 00 00:00:26.375 RECALIBRATE [OBS-4] 91 00 3f 3f ff 3f e0 00 00:00:26.375 INITIALIZE DEVICE PARAMETERS [OBS-6] Error 670 occurred at disk power-on lifetime: 2502 hours (104 days + 6 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 04 51 00 55 1d a7 e0 Error: ABRT Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- ef 85 00 55 1d a7 e0 00 00:01:04.875 SET FEATURES [Disable APM] ef 02 00 00 00 00 e0 00 00:00:25.125 SET FEATURES [Enable write cache] c6 00 10 00 00 00 e0 00 00:00:25.125 SET MULTIPLE MODE 10 00 3f 00 00 00 e0 00 00:00:25.125 RECALIBRATE [OBS-4] 91 00 3f 3f ff 3f e0 00 00:00:25.125 INITIALIZE DEVICE PARAMETERS [OBS-6] Error 669 occurred at disk power-on lifetime: 2502 hours (104 days + 6 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 04 51 00 75 c5 02 e0 Error: ABRT Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- ef 85 00 75 c5 02 e0 00 00:01:03.063 SET FEATURES [Disable APM] ef 02 00 00 00 00 e0 00 00:00:25.125 SET FEATURES [Enable write cache] c6 00 10 00 00 00 e0 00 00:00:25.125 SET MULTIPLE MODE 10 00 3f 00 00 00 e0 00 00:00:25.125 RECALIBRATE [OBS-4] 91 00 3f 3f ff 3f e0 00 00:00:25.125 INITIALIZE DEVICE PARAMETERS [OBS-6] SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 00% 21411 132185433 # 2 Short offline Completed without error 00% 21410 - Device does not support Selective Self Tests/Logging ----------------------------------------------------------------------------------------------- Fin
-- Cheers / Saludos,
Carlos E. R. (from 11.1-factory)
Saludos. -- ---- Josep M Solé
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Josep M Solé Valls wrote:
El Saturday 25 October 2008 21:51:14 Carlos E. R. escribió:
Josep M Solé Valls wrote:
Primer paso: apagar. Segundo: comprar otro disco, para hacer un respaldo y trasvaso de datos. Es sábado, y tarde...
**Demasiado tarde. No me queda más que respaldar datos. De todas formas creo que debería clonar el disco sin errores (dd?) puesto que estoy en la 11.0 y las configuraciones són recientes del pasado verano.
dd_rescue, no dd. Eso sirve para clonar imágenes de particiones o discos, siempre que tengas sitio en el destino. El dd_rescue no aborta si hay error.
Pero dado que a ese disco parece que nunca se le han hecho pruebas... mira en la tabla de estado SMART (-a) cmo está la tabla de redireción de sectores. Si está llena, el disco está para el arrastre. Con --health te dirá algo enseguida.
**Observo que el error viene de lejos. Hace tiempo que se produjo, creo entender que muestra los 5 últimos errores "(device log contains only the most recent five errors)". Esto me hace pensar que quizá sea una coincidencia y que el cuelgue se produzca por otros motivos concomitantes.
Esos errores son muy antiguos. En este momento el testeo se cuelga antes de poder registrar el error, aparentemente por un error de lectura.
Aquí va el smartctl -a /dev/sda
A ver si lo descifro.
SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 071 059 000 Pre-fail Always - 5184 4 Start_Stop_Count 0x0032 094 094 000 Old_age Always - 6106 5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 253 253 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0024 253 253 000 Old_age Offline - 0 9 Power_On_Half_Minutes 0x0032 096 096 000 Old_age Always - 21414h+41m 10 Spin_Retry_Count 0x0013 253 253 049 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 097 097 000 Old_age Always - 3511 194 Temperature_Celsius 0x0022 163 100 000 Old_age Always - 25 195 Hardware_ECC_Recovered 0x000a 100 100 000 Old_age Always - 657980373 196 Reallocated_Event_Count 0x0012 100 100 000 Old_age Always - 1 197 Current_Pending_Sector 0x0033 100 100 010 Pre-fail Always - 1 198 Offline_Uncorrectable 0x0031 100 100 010 Pre-fail Offline - 1 199 UDMA_CRC_Error_Count 0x000a 100 100 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0 201 Soft_Read_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0
No hay parámetros fallados, creo. El valor "Reallocated_Sector_Ct" es el que me preocupa, pero creo que no ha sido usado (cuenta hacia abajo). También está el "Reallocated_Event_Count". Creo que el Current_Pending_Sector indica que hay un error pendiente de corregir, y que no lo ha hecho o no ha podido (no lo se).
SMART Error Log Version: 1
Error 673 occurred at disk power-on lifetime: 2510 hours (104 days + 14 hours)
Eso fué hace mucho, así que no importa. Y pudo ser una trivialidad, no es facil de analizar sin un guiaburros, y no lo tengo. Algunos ponen texto descrifrable/adivinable, este no.
SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 00% 21411 132185433 # 2 Short offline Completed without error 00% 21410 -
Te dice el LBA del primer error de lectura, pero eso sirve de poco. Y puede tener más. - -- Cheers / Saludos, Carlos E. R. (from 11.1-factory) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkkEWq8ACgkQU92UU+smfQVS1QCfQVhBBn0ACySXn1jTfgldZacx Mq0AnjfpdobukdnLSONfJ5T4/2Hxcw14 =B87v -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Sunday 26 October 2008 12:55:27 Carlos E. R. escribió:
SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 00% 21411 132185433 # 2 Short offline Completed without error 00% 21410 -
Te dice el LBA del primer error de lectura, pero eso sirve de poco. Y puede tener más.
**Pues resulta que está en una partición no crucial, en xfs. Aquí es donde se encuentra el primer error de lectura. Es en la parte poco usada del disco. La intención era hacer ahí un backup de datos. Saludos -- ---- Josep M Solé
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Josep M Solé Valls wrote:
**Pues resulta que está en una partición no crucial, en xfs. Aquí es donde se encuentra el primer error de lectura. Es en la parte poco usada del disco. La intención era hacer ahí un backup de datos.
Ni se te ocurra, ni en esa partición ni en ninguna otra de ese disco. Apagalo, comprate otro disco el lunes, y cuando lo tengas lo vuelves a encender y copias todo en el nuevo disco. - -- Cheers / Saludos, Carlos E. R. (from 11.1-factory) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkkEifwACgkQU92UU+smfQVGhACfWJ5GpqFyPSpn4QqBAUhr4bc8 UAoAnA7DmI50eM9PQxwvFn+kLOBR8YYd =e0ki -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El lun, 20-10-2008 a las 21:50 +0200, Josep M Solé Valls escribió:
El Monday 20 October 2008 20:20:40 Camaleón escribió:
El 20/10/08, Josep M Solé Valls escribió:
Con estos síntomas ¿Por dónde puedo intentar buscar la solución?
Explica un poco qué tienes en ese equipo (en cuanto a software y hardware) qué carga de trabajo tiene, qué uso le das, etc...
**
Procesador (CPU): AMD Athlon(tm) XP 2800+ Velocidad: 2075,06 MHz Temperatura: 69°C
Solo un detalle, algunas placas madre vienen configuradas (como la mía)
para avisar de sobrecalentamiento del procesador en los 65º, cortando la
corriente en 70º, la tº que indicas para el procesador está bastante
cerca de esas tºs (me parece un poco alta). ¿Has visto en tu BIOS cuáles
son los valores de aviso y corte?
Saludos.
--
Mauricio J. Adonis C.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-20 a las 18:55 -0300, Mauricio J. Adonis C. escribió:
Procesador (CPU): AMD Athlon(tm) XP 2800+ Velocidad: 2075,06 MHz Temperatura: 69°C
Solo un detalle, algunas placas madre vienen configuradas (como la mía) para avisar de sobrecalentamiento del procesador en los 65º, cortando la corriente en 70º, la tº que indicas para el procesador está bastante cerca de esas tºs (me parece un poco alta). ¿Has visto en tu BIOS cuáles son los valores de aviso y corte?
Pero si fuera eso no le dejaría seguir ejecutando programas. Y le deja. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj9AAkACgkQtTMYHG2NR9WTHgCfQaRdiwlnzR+XQA6Bbo7ppOKX FTYAoIxX5Xuxidkvl0WZ07l+4cxG0k/R =PTzg -----END PGP SIGNATURE-----
El 20/10/08, Josep M Solé Valls escribió: Se me olvidó preguntarte... ¿desde cuándo te pasa ésto? :-?
** Es un cuelgue con mucho "delay" ( en un principio sospeché de la memoria, però después de un par de horas de memtest no dio nada)
La primera sospecha suele ser la acertada. Ataca por la memoria. Si tienes dos módulos de 512, prueba quitando uno de ellos o colócalo en otro zócalo. Si sólo tienes un módulo de 1 GB. prueba cambiándolo de zócalo y si puedes probar con otra pastilla, mejor.
** Si, parece que se reproduce entre 48 y 72 horas.
No has comentado qué uso le das al equipo, pero si es un servidor podrás "sobrevivir" sin entorno gráfico (esto es una malvada suposición mía) >:-). Prueba a iniciar en init 3, que no cargue kde ni xorg ni el controlador gráfico de la tarjeta... nada. Y observa si se vuelve a producir el cuelgue. Por los datos del equipo, diría que tiene unos 3 o 4 años y un fallo de algún componente de hardware no sería raro :-? En el cuelgue, ¿las luces del teclado funcionan, el ratón se mueve...? ¿Marca y modelo de la placa base? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Tuesday 21 October 2008 00:13:45 Camaleón escribió:
El 20/10/08, Josep M Solé Valls escribió:
Se me olvidó preguntarte... ¿desde cuándo te pasa ésto? :-?
** Es un cuelgue con mucho "delay" ( en un principio sospeché de la memoria, però después de un par de horas de memtest no dio nada)
La primera sospecha suele ser la acertada. Ataca por la memoria.
Si tienes dos módulos de 512, prueba quitando uno de ellos o colócalo en otro zócalo. Si sólo tienes un módulo de 1 GB. prueba cambiándolo de zócalo y si puedes probar con otra pastilla, mejor.
***Probaré esto cuando pueda
** Si, parece que se reproduce entre 48 y 72 horas.
No has comentado qué uso le das al equipo, pero si es un servidor podrás "sobrevivir" sin entorno gráfico (esto es una malvada suposición mía) >:-). Prueba a iniciar en init 3, que no cargue kde ni xorg ni el controlador gráfico de la tarjeta... nada. Y observa si se vuelve a producir el cuelgue.
***Probaré esto cuando pueda
Por los datos del equipo, diría que tiene unos 3 o 4 años y un fallo de algún componente de hardware no sería raro :-?
En el cuelgue, ¿las luces del teclado funcionan, el ratón se mueve...?
*** Funcionan
¿Marca y modelo de la placa base?
***MSI KM4M-L (MS-6734) Chipset VIA VT8378 Unichrome KM400
Saludos,
-- Camaleón
-- ---- Josep M Solé
No has comentado qué uso le das al equipo, pero si es un servidor podrás "sobrevivir" sin entorno gráfico (esto es una malvada suposición mía) >:-). Prueba a iniciar en init 3, que no cargue kde ni xorg ni el controlador gráfico de la tarjeta... nada. Y observa si se vuelve a producir el cuelgue.
***Probaré esto cuando pueda
Para hacer eso no necesitas reiniciar y la mayoría de servicios te funcionaran igual. Lo único que debes hacer es abrir una consola como root y ejecutar "init 3". Cuando quieras volver al entorno gráfico solo es necesario teclear en la misma cónsola "init 5". Lo ideal sería tenerlo en init 3 durante 4-5 días, es decir sobrepasando el tiempo medio que tarda en producirse la incidencia.
Por los datos del equipo, diría que tiene unos 3 o 4 años y un fallo de algún componente de hardware no sería raro :-?
En el cuelgue, ¿las luces del teclado funcionan, el ratón se mueve...?
*** Funcionan
¿Marca y modelo de la placa base?
***MSI KM4M-L (MS-6734) Chipset VIA VT8378 Unichrome KM400
Saludos,
-- Camaleón
-- ---- Josep M Solé
El 22/10/08, Josep M Solé Valls escribió:
El Tuesday 21 October 2008 00:13:45 Camaleón escribió:
En el cuelgue, ¿las luces del teclado funcionan, el ratón se mueve...?
*** Funcionan
Hum... Si fuera un problema de X deberían quedarse fritos...
¿Marca y modelo de la placa base?
***MSI KM4M-L (MS-6734) Chipset VIA VT8378 Unichrome KM400
http://www.msicomputer.com/product/detail_spec/product_detail.asp?model=km4m... Ponen un aviso para la memoria, no sólo para tu modelo concreto sino para versiones de la misma "gama"... no estaría de más que cotejaras los datos de la bios con las características del módulo de ram, aquí te ponen más info: Stability Problems http://www.msicomputer.com/support/sup_tshoot.asp#2_1 Y comprueba también la versión de bios que tienes para ver si es la última :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Wednesday 22 October 2008 11:59:28 Camaleón escribió:
El 22/10/08, Josep M Solé Valls escribió:
El Tuesday 21 October 2008 00:13:45 Camaleón escribió:
En el cuelgue, ¿las luces del teclado funcionan, el ratón se mueve...?
*** Funcionan
Hum... Si fuera un problema de X deberían quedarse fritos...
¿Marca y modelo de la placa base?
***MSI KM4M-L (MS-6734) Chipset VIA VT8378 Unichrome KM400
<http://www.msicomputer.com/product/detail_spec/product_detail.asp?model=km 4m-l>
Ponen un aviso para la memoria, no sólo para tu modelo concreto sino para versiones de la misma "gama"... no estaría de más que cotejaras los datos de la bios con las características del módulo de ram, aquí te ponen más info:
Stability Problems http://www.msicomputer.com/support/sup_tshoot.asp#2_1
***Muy interesante.
Y comprueba también la versión de bios que tienes para ver si es la última :-?
Saludos,
-- Camaleón
-- ---- Josep M Solé
El día 20 de octubre de 2008 17:50, Josep M Solé Valls
El Monday 20 October 2008 20:20:40 Camaleón escribió:
El 20/10/08, Josep M Solé Valls escribió:
Con estos síntomas ¿Por dónde puedo intentar buscar la solución?
Explica un poco qué tienes en ese equipo (en cuanto a software y hardware) qué carga de trabajo tiene, qué uso le das, etc...
**
Procesador (CPU): AMD Athlon(tm) XP 2800+ Velocidad: 2075,06 MHz Temperatura: 69°C
Esa temperatura está al borde del punto critico. Ante cualquier variación de temperatura ambiente o de carga en el servidor, se te pasa de temperatura. Deberias cambiar el cooler (ventilador y disipador), si están mal, o al menos quitarle la suciedad que puede estar tapando las ranuras de ventilación, y ver que el resto de los coolers del gabinete funcionen correctamente (incluido el de la fuente) de manera que no exista un sobrecalentamiento del aire dentro del mismo. Amen de eso, hay que ver que el equipo no esté mal ensablado, y el cooler del micro esté detras de la fuente de alimentación a menos de 2 cm de distancia de esta, que obstruye el paso de aire, y hace que el micro tome el aire caliente de la citada fuente. Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón escribió:
El 20/10/08, Josep M Solé Valls escribió:
Con estos síntomas ¿Por dónde puedo intentar buscar la solución?
Explica un poco qué tienes en ese equipo (en cuanto a software y hardware) qué carga de trabajo tiene, qué uso le das, etc...
En alguna ocasión ha salido este tema de los cuelgues aleatorios y que no dejan rastro y por lo general, los culpables suelen ser:
a) ¡¡ReiserFS, ReiserFS!! :-P b) Calor (pero si no pita, descartado) c) Algún componente crítico que falla (procesador, módulo de memoria o fuente de alimentación) d) Algún bug del kernel que te esté mordiendo
¿Has intentado iniciar una sesión vía ssh cuando se cuelga para descartar cualquier problema relacionado con el entono gráfico? :-?
¿Te saca algo "dmesg" en el momento del cuelgue inminente? ¿hay algún patrón de cuelgue (por ejemplo, a la misma hora del día)?
Saludos,
Mi experiencia con ResierFS es nefasta. Ya no salgo de ext3 y con ext3 encontré la Paz. :) -- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-20 a las 22:24 +0200, csalinux escribió:
Mi experiencia con ResierFS es nefasta. Ya no salgo de ext3 y con ext3 encontré la Paz. :)
Pues la miea es bastante buena. De hecho, he conseguido petar todos. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj873IACgkQtTMYHG2NR9WlyQCfUOZE2qkziVrwtDosb6eRCOXh SIAAn0bj739e6hlDVL1mVWx03Rad5tUV =aU+2 -----END PGP SIGNATURE-----
Hola. El Lunes 20 Octubre 2008, Josep M Solé Valls escribió:
Hola,
Desde un tiempo para acá estoy experimentando cuelgues de mi servidor doméstico. Hasta ahora no he encuentrado el motivo. Se puede volver a arrancar y puede pasarse varios días funcionando correctamente hasta que se
Tuve unos problemas parecidos con un server en el trabajo. Al final se soluciono al actualizar el kernel. Lo que hice para saber mas o menos lo que fallaba era dejar las siguientes consolas abiertas. 1. top ordenado por procesado 2. top ordenado por memoria 3. tail -f /var/log/messages 4. sesion iniciada (por si necesito revisar algo ahorrarme el login) Otro tema es anotar la hora del cuelgue y dar un tiempo antes del reinicio anotando tambien esa hora, y luego revisar cuidadosamente todos los logs. Tambien tuve un problema con el imap que me dejaba pillado el sistema, por culpa de un problema con la gestion de los buzones (se empezaban a crear procesos zombi y se caia el rendimiento de todo el sistema, incluso el acceso a disco se llegaba a quedar colgado). Tambien se soluciono con una actualizacion de kernel. Suerte. -- Un Saludo. Carlos Lorenzo Matés. clmates AT mundo-r.com
El Monday 20 October 2008 22:28:32 Carlos Lorenzo Matés escribió:
Hola.
El Lunes 20 Octubre 2008, Josep M Solé Valls escribió:
Hola,
Desde un tiempo para acá estoy experimentando cuelgues de mi servidor doméstico. Hasta ahora no he encuentrado el motivo. Se puede volver a arrancar y puede pasarse varios días funcionando correctamente hasta que se
Tuve unos problemas parecidos con un server en el trabajo. Al final se soluciono al actualizar el kernel.
Lo que hice para saber mas o menos lo que fallaba era dejar las siguientes consolas abiertas.
1. top ordenado por procesado
2. top ordenado por memoria
3. tail -f /var/log/messages
4. sesion iniciada (por si necesito revisar algo ahorrarme el login)
**Lo intentaré.
Otro tema es anotar la hora del cuelgue y dar un tiempo antes del reinicio anotando tambien esa hora, y luego revisar cuidadosamente todos los logs.
Tambien tuve un problema con el imap que me dejaba pillado el sistema, por culpa de un problema con la gestion de los buzones (se empezaban a crear procesos zombi y se caia el rendimiento de todo el sistema, incluso el acceso a disco se llegaba a quedar colgado). Tambien se soluciono con una actualizacion de kernel.
**Está actualizado.
Suerte.
-- ---- Josep M Solé
participants (9)
-
Camaleón -
Carlos E. R. -
Carlos Lorenzo Matés -
csalinux -
J.M.Queralt -
Josep M Solé Valls -
Juan Erbes -
Mauricio J. Adonis C. -
Oscar Curero