5.1. | ¿Porque FreeBSD encuentra la cantidad incorrecta de memoria en hardware i386™? |
La razón más probable es la diferencia entre direcciones de memoria física y direcciones virtuales. La convención para la mayoría del hardware de PC hardware es usar el área de memoria entre 3.5 GB y 4 GB para un propósito especial (usualmente para PCI). Este espacio de direcciones se usa para acceder a hardware PCI. Como resultado, la memoria real (física) no puede ser accedida en ese espacio de direcciones. Lo que sucede con la memoria que debería aparecer en ese espacio es dependiente del hardware. Desafortunadamente, algunos equipos no hacen nada y la habilidad de usar los últimos 500 MB de RAM se pierde por completo. Por suerte, la mayoría de los equipos de hardware remapean la memoria a una locación más alta de manera que pueda seguir siendo usada. No obstante, esto puede causar confusión al ver los mensajes de arranque. En una versión de 32 bits de FreeBSD, la memoria parece perdida, dado que sera remapeado por encima de los 4 GB, que son imposibles de acceder para un kernel de 32 bits. En este caso, la solución es construir un kernel con PAE habilitado. Vea la entrada acerca de límites de memoria para más información. En una versión de 64 bits de FreeBSD, o al correr un kernel con PAE habilitado, FreeBSD detectara y remapeara la memoria de manera correcta para que sea usable. Durante el arranque, sin embargo, puede parecer que FreeBSD este detectando más memoria de la que tiene realmente el sistema, debido al remapeo descrito anteriormente. Esto es normal y la memoria disponible sera corregida cuando el proceso de arranque termine. | |
5.2. | ¿Por que mis programas ocasionalmente terminan con errores Signal 11? |
Los errores Signal 11 son causados cuando un proceso intento acceder a una región de memoria cuyo acceso no fue concedido por el sistema operativo. Si algo como esto pasa a intervalos aparentemente aleatorios, comience a investigar la causa. Estos problemas suele deberse a:
Probablemente no se trate de un error en FreeBSD si el problema ocurre al compilar un programa, pero la actividad que el compilador realiza cambia en cada iteración. Por ejemplo, si En el primer caso, use un debugger, tal como gdb(1) para encontrar el punto en el que el programa este intentando acceder a una dirección falsa y arreglarlo. En el segundo caso, verifique la pieza de hardware que este fallando. Causas comunes de esto incluyen:
Lea la sección acerca de Signal 11 para más explicaciones y una discusión acerca de como el software o hardware que verifica la memoria puede no detectar memoria defectuosa. Hay un extenso FAQ acerca de esto en el problema SIG11FAQ. Finalmente, si nada de esto ayuda, es posible que sea un error en FreeBSD. Siga estas instrucciones para enviar un reporte de errores. | |
5.3. | Mi sistema falla con Fatal trap 12: page fault in kernel mode, o panic:, y escupe un monton de información. ¿Qué debo hacer? |
Los desarrolladores de FreeBSD están interesados en estos errores, pero necesitan mas información que solo el mensaje de error. Copie el mensaje de fallo entero. Luego consulte la sección del FAQ acerca de fallos de kernel, compile un kernel de depuración y obtenga un backtrace. Esto puede sonar difícil, pero no requiere habilidades de programación. Tan solo siga las instrucciones. | |
5.4. | ¿Cual es el significado del error maxproc limit exceeded by uid %i, please see tuning(7) and login.conf(5)? |
El kernel de FreeBSD solo permite que exista un cierto número de procesos en un punto determinado del tiempo. El número esta basado en la variable de sysctl(8) Para ajustar el valor de Si la máquina tiene una carga ligera pero esta corriendo número muy alto de proceso, ajuste la variable | |
5.5. | ¿Por qué las aplicaciónes de pantalla completa en máquinas remotas se comportan mal? |
La máquina remota puede estar ajustando el tipo de la terminal a un valor que no sea Verifique que el valor de la variable de entorno Corra Alternativamente, si la máquina del cliente tiene x11/xterm instalado, entonces correr | |
5.6. | ¿Porque le lleva tanto tiempo a mi computadora conectarse via |
El síntoma: hay un largo retraso entre el tiempo en que se establece la conexión TCP y el tiempo en el que el software del cliente pide una contraseña (o, en el caso de telnet(1), cuando aparece una pantalla de autenticación). El problema: lo más probable, es que el retraso haya sido causado por el software del servidor intentando resolver la dirección IP del cliente a un nombre de host. Muchos servidores, incluyendo los servidores Telnet y SSH que vienen con FreeBSD, hacen esto para guardar el hostname en un archivo de log para referencias futuras del administrador. La solución: si el problema ocurre siempre que se conecta la computadora cliente a cualquier servidor, el problema esta en el cliente. Si el problema ocurre solo cuando alguien se conecta a la computadora servidor, el problema esta en el servidor. Si el problema esta en el cliente, la única solución es reparar el DNS de manera que el servidor pueda resolverla. Si esto ocurre en una red local, considerelo un problema del servidor y siga leyendo. Si esto ocurre en Internet, contacte a su ISP. Si el problema es con el servidor en una red local, configure el servidor para resolver consultas de dirección a hostname para el rango de direcciones local. Vea hosts(5) y named(8) para más información. Si esto ocurre en la Internet, el problema puede ser que el resolver local del servidor no esta funcionando correctamente. Para verificar, intente buscar otro host tal como Luego de una instalación de cero de FreeBSD, también es posible que la información del dominio y servidor de nombres no exista en | |
5.7. | ¿Por qué file: table is full aparece repetidamente en dmesg(8)? |
Este mensaje de error indica que el número de descriptores de archivo disponibles en el sistema se agoto. Vea la subsección kern.maxfiles de la sección Ajustando límites del kernel del manual para una discusión y una solución. | |
5.8. | ¿Por qué el reloj de mi computadora tiene el tiempo incorrecto? |
La computadora tiene dos o más relojes, y FreeBSD eligió usar el incorrecto. Corra dmesg(8), y verifique las líneas que contengan
Confirme esto verificando el sysctl(3)
Puede tratarse de un timer ACPI roto. La solución más simple es deshabilitar el timer ACPI en debug.acpi.disabled="timer" O el BIOS puede modificar el reloj TSC quizás para cambiar la velocidad del procesador cuando se agonten las baterías, o al cambiar al modo de ahorro de engería, pero FreeBSD no sabe nada de estos ajustes y parece estar perdiendo o ganando tiempo. En este ejemplo, el reloj
La computadora debería empezar a medir el tiempo de manera más correcta a partir de ahora. Para que este cambio corra automáticamente en tiempo de arranque, agregue la siguiente línea a kern.timecounter.hardware=i8254 | |
5.9. | ¿Qué significa el error swap_pager: indefinite wait buffer:? |
Esto significa que un proceso esta intentando paginar memoria al disco, y el intento de paginación se colgó intentando acceder al disco por más de 20 segundos. Puede estar causado por bloques defectuosos en el disco rígido, cableado del disco, cables, o cualquier otro tipo de hardware de E/S relacionado. Si el disco en si mismo esta defectuoso, los errores de disco aparecerán en | |
5.10. | ¿Qué es un lock order reversal? |
El kernel de FreeBSD usa un número de primitivas de sincronización para manejar la contención de ciertos recursos. Cuando múltiples hilos de kernel intentan obtener múltiples primitivas de sincronización, existe el potencial para un interbloqueo, en donde dos hilos obtuvieron cada uno una primitiva y se bloquean eternamente esperando que el otro hilo libere la otra. Este tipo de problema de bloqueo puede evitarse si todos los hilos obtienen las primitivas en el mismo orden. Un sistema diagnóstico en tiempo de ejecución llamado witness(4), habilitado en FreeBSD-CURRENT y deshabilitado por defecto para ramas stable y lanzamientos, detecta el potencial para interbloques debido a errores de bloque, incluyendo errores causados por la obtención de múltiples primitivas de sincronización con un orden diferente de distintas partes del kernel. El framework witness(4) intenta detectar este problema mientras ocurre y lo reporta imprimiendo un mensaje en la consola del sistema acerca de un lock order reversal (también conocido como LOR). Es posible obtener falsos positivos, dado que witness(4) es conservativo. Un reporte que realmente sea positivo no significa que el sistema sufrió un interbloqueo; en su lugar, debería ser entendido como una advertencia que un interbloqueo podría haber ocurrido en ese lugar. Nota:Los LOR problemáticos tienden a arreglarse rápidamente, asi que verifique la lista de correo de FreeBSD-CURRENT antes de postear allí. | |
5.11. | ¿Qué significa Called ... with the following non-sleepable locks held? |
Significa que una función que puede dormirse fue llamada mientras un mutex (u otra primitiva de sincronización que no duerme) estaba bloqueado. La razón por la que esto es un error es que los mutexes no fueron concebidos para ser tenidos por largos períodos de tiempo; se supone que solo se tengan para mantener durante períodos cortos de sincronización. Este contrato de programación permite que los controladores de dispositivo usen mutexes para sincronizarse con el resto del kernel durante las interrupciones. Las interrupciones (bajo FreeBSD) pueden no dormirse. Luego es imperativo que ningún subsistema en el kernel se bloquee por un período extendido de tiempo al mantener un mutex. Para atrapar tales errores, pueden agregarse aserciones al kernel para interactuar con el subsitema witness(4) y emitir una alerta o un error fatal (dependiendo de la configuración del sistema) cuando una llamada potencialmente bloqueante es hecha mientras que se mantiene un mutex. En resumen, estas alertas no son fatales, no obstante errores de coordinación pueden causar efectos indeseables variando desde un mínimo retraso en la respuesta del sistema a un completo bloqueo del mismo. Para información adicional acerca de los bloqueos en FreeBSD vea locking(9). | |
5.12. | ¿Porque |
Este error no significa que la utilidad touch(1) este faltante. En su lugar el error probablemente se debe a que las fechas de los archivos están ajustadas a una fecha futura. Si el reloj CMOS esta ajustado a tiempo local, corra |
Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Si tiene dudas sobre FreeBSD consulte la
documentación antes de escribir a la lista
<questions@FreeBSD.org>.
Envíe sus preguntas sobre la documentación a
<doc@FreeBSD.org>.