diff --git a/es/FAQ/troubleshoot.sgml b/es/FAQ/troubleshoot.sgml index 5e3524d550..41dbaeeb68 100644 --- a/es/FAQ/troubleshoot.sgml +++ b/es/FAQ/troubleshoot.sgml @@ -1,4 +1,4 @@ - + Problemas @@ -388,5 +388,31 @@ Lanza las X y haz el login en la máquina remota desde xterm. + + + Aparece el mensaje de error "calcru: negative time..." +

Esto puede ser causado por varios problemas de hardware o software + relacionados con las interrupciones. Utilizar TCP/IP sobre el puerto + paralelo con un MTU muy grande es una buena manera de provocar este error. + Las tarjetas gráficas aceleradoras también lo pueden + provocar, teniendo que revisar la interrupción utilizada + por la tarjeta. + +

El efecto de este error es que los procesos mueren con el mensaje + "SIGXCPU exceeded cpu time limit". + +

Para FreeBSD 3.0 y posteriores desde el 29 de Noviembre de 1998: si + el problema no puede fijarse de otra manera, la solución es + poner la variable sysctl a: + + sysctl -w kern.timecounter.method=1 + +

Esto puede significar un impacto en el rendimiento del sistema, pero + considerando la causa del problema, probablemente no lo notarás. Si + el problema persiste, mantén la variable sysctl a uno y + añade la opción "NTIMECOUNTER" en tu kernel para aumentar + su valor. Si finalmente llegas a un valor de "NTIMECOUNTER=20" el problema + no está resuelto, y las interrupciones están demasiado + saturadas para ofrecer un buén rendimiento. diff --git a/es_ES.ISO8859-1/FAQ/troubleshoot.sgml b/es_ES.ISO8859-1/FAQ/troubleshoot.sgml index 5e3524d550..41dbaeeb68 100644 --- a/es_ES.ISO8859-1/FAQ/troubleshoot.sgml +++ b/es_ES.ISO8859-1/FAQ/troubleshoot.sgml @@ -1,4 +1,4 @@ - + Problemas @@ -388,5 +388,31 @@ Lanza las X y haz el login en la máquina remota desde xterm. + + + Aparece el mensaje de error "calcru: negative time..." +

Esto puede ser causado por varios problemas de hardware o software + relacionados con las interrupciones. Utilizar TCP/IP sobre el puerto + paralelo con un MTU muy grande es una buena manera de provocar este error. + Las tarjetas gráficas aceleradoras también lo pueden + provocar, teniendo que revisar la interrupción utilizada + por la tarjeta. + +

El efecto de este error es que los procesos mueren con el mensaje + "SIGXCPU exceeded cpu time limit". + +

Para FreeBSD 3.0 y posteriores desde el 29 de Noviembre de 1998: si + el problema no puede fijarse de otra manera, la solución es + poner la variable sysctl a: + + sysctl -w kern.timecounter.method=1 + +

Esto puede significar un impacto en el rendimiento del sistema, pero + considerando la causa del problema, probablemente no lo notarás. Si + el problema persiste, mantén la variable sysctl a uno y + añade la opción "NTIMECOUNTER" en tu kernel para aumentar + su valor. Si finalmente llegas a un valor de "NTIMECOUNTER=20" el problema + no está resuelto, y las interrupciones están demasiado + saturadas para ofrecer un buén rendimiento. diff --git a/es_ES.ISO_8859-1/FAQ/troubleshoot.sgml b/es_ES.ISO_8859-1/FAQ/troubleshoot.sgml index 5e3524d550..41dbaeeb68 100644 --- a/es_ES.ISO_8859-1/FAQ/troubleshoot.sgml +++ b/es_ES.ISO_8859-1/FAQ/troubleshoot.sgml @@ -1,4 +1,4 @@ - + Problemas @@ -388,5 +388,31 @@ Lanza las X y haz el login en la máquina remota desde xterm. + + + Aparece el mensaje de error "calcru: negative time..." +

Esto puede ser causado por varios problemas de hardware o software + relacionados con las interrupciones. Utilizar TCP/IP sobre el puerto + paralelo con un MTU muy grande es una buena manera de provocar este error. + Las tarjetas gráficas aceleradoras también lo pueden + provocar, teniendo que revisar la interrupción utilizada + por la tarjeta. + +

El efecto de este error es que los procesos mueren con el mensaje + "SIGXCPU exceeded cpu time limit". + +

Para FreeBSD 3.0 y posteriores desde el 29 de Noviembre de 1998: si + el problema no puede fijarse de otra manera, la solución es + poner la variable sysctl a: + + sysctl -w kern.timecounter.method=1 + +

Esto puede significar un impacto en el rendimiento del sistema, pero + considerando la causa del problema, probablemente no lo notarás. Si + el problema persiste, mantén la variable sysctl a uno y + añade la opción "NTIMECOUNTER" en tu kernel para aumentar + su valor. Si finalmente llegas a un valor de "NTIMECOUNTER=20" el problema + no está resuelto, y las interrupciones están demasiado + saturadas para ofrecer un buén rendimiento.