Capítulo 4. Problemas

Los discos SCSI deberían ser capaces de marcar estos bloques erróneos automaticamente para que no presenten problemas. Algunos discos, por alguna razón desconocida, se venden con esta característica desactivada.

Para activar esta opción, tendrás que editar una de las opciones del dispositivo, lo que puede ser hecho con FreeBSD tecleando el siguiente comando (como root):

        
scsi -f /dev/rsd0c -m 1 -e -P 3
          

y cambiando los valores de AWRE y ARRE de 0 a 1:-

        
AWRE (Auto Write Reallocation Enbld):  1
ARRE (Auto Read Reallocation Enbld):  1
          

Para otros tipos de discos, dependes de las características de los sistemas operativos. Desafortunadamente, el comando "bad144" que se incluye en FreeBSD, necesita ser desarrollado más en profundidad.

Se supone que los discos IDE incluyen de serie la posibilidad de "remapear" los bloques dañados; si tienes documentación de tu disco, podrás ver si esta opción está activada o desactivada.

Esta información es específica para la tarjeta 742a, pero puede ser aplicable a otras tarjetas Buslogic. (Bustek = Buslogic)

Existen dos versiones de la tarjeta 742a. Son revisiones de hardware A-G y H. La letra de revisión está situada después del número de ensamblaje. La 742a tiene 2 ROMs, una es el BIOS y la otra es el Firmware. FreeBSD no se fija en la versión de BIOS de la tarjeta, pero si en la de Firmware. Buslogic te enviará una actualización de de las ROMs si te pones en contacto con su departamento técnico. La BIOS y el Firmware son distribuidas de manera inseparable. Deberías tener la versión de Firmware más actualizada para la revisión de hardware de tu tarjeta.

Las tarjetas con revisión A-G solo pueden aceptar BIOS/Firmware 2.41/2.21. La revisión H y superiores pueden aceptar las versiones más actuales 4.70/3.37. La diferencia entre las versiones de Firmware es que la 3.38 soporta "round robin".

Las tarjetas Buslogic tienen un número de serie serigrafiado en ellas. Si tienes una revisión de hardware antigua, puedes llamar al departamento de RMA de Buslogic y darles el número de serie de la tarjeta para intentar cambiarla por una revisión superior del hardware.

FreeBSD 2.1 solo soporta revisiones de Firmware 2.21 o superiores. Si tienes una versión inferior, tu tarjeta no será reconocida como Buslogic. Quizás sea reconocida como una Adaptec 1540. Las primeras versiones de Firmware de Buslogic contienen una modo de emulación de la AHA1540.

Si tienes una revisión de hardware antigua y consigues una más actual (2.21), necesitarás chequear la posición del jumper W1 y asegurarte que está en la posición B-C (por defecto esta en B-C).

Este es un problema ya conocido. Las controladoras SCSI EISA integradas en la placa base en las máquinas HP Netserver, ocupan el slot numero 11. El espacio de direcciones para los slots EISA >=10 colisionan con los espacios de direcciones asignados para los dispositivos PCI, y la autoconfiguración de FreeBSD no maneja esta situación demasiado bien.

Lo mejor que puedes hacer es pretender que no existan clases de rangos de direcciones :), cambiando el valor de la opción del kernel EISA_SLOTS a un valor de 12. Configura y compila un nuevo kernel como se describe en la entrada correspondiente del manual.

Por supuesto, esto presenta un pequeño problema. Para poder solucionarlo, es necesario un truco en la utilidad de configuración. No uses el interface "visual", simplemente teclea lo siguiente en la línea de comando de la utilidad

eisa 12
quit
          

Esperamos que en las próximas versiones tengamos solucionados estos temas.

No funciona. No puede manejar comandos en los dos canales simultáneamente.

Hay una solución posible y se activa automáticamente si tu sistema usa este chip. Para más detalles, referirse al man del driver de discos (man 4 wd).

Si todavía estás usando FreeBSD 2.2.1 o 2.2.2 con una controladora IDE CMD640 y quieres usar el segundo canal, crea un nuevo kernel con options "CMD640" activada. Esta es la opción por defecto en la versión 2.2.5 y superiores.

Esto, normalmente es causado por conflictos de interrupciones (por ejemplo, dos tarjetas usando la misma IRQ). Las versiones anteriores a la 2.0.5R eran tolerantes con los problemas de conflictos de IRQ. A partir de esa versión, los conflictos de IRQ ya no son tolerados. Arranca con la opción -c y cambia la entrada correspondiente a tu tarjeta.

Si estás usando conectores BCN en tu tarjeta de red, el mensaje de error puede ser debido a una mala terminación de la red. Para chequear esto, conecta un terminador directamente a la salida BNC de la tarjeta (sin cable) y mira si el mensaje desaparece.

Tienes que indicar el tipo de dispositivo que quieres montar. Por defecto mount asumirá que el dispositivo que quieres montar es ``ufs''. Si quieres montar un CDROM, tienes que especificar -t cd9660. Esto hace que el sistema asuma que tiene que montar un sistema de archivos con formato ISO 9660 que es lo que los CDROM deben tener.

Como ejemplo, si quieres montar una unidad CDROM, /dev/cd0c, bajo /mnt, tienes que ejecutar

mount -t cd9660 /dev/cd0c /mnt
          

Ten en cuenta que el nombre de tu dispositivo (/dev/cd0c en este ejemplo) puede ser diferente dependiendo del interface que estés usando. El comando anterior puede ser acortado tecleando:

mount_cd9660 /dev/cd0c /mnt
          

Esto, generalmente, significa que no hay ningún disco en el lector de CDROM. También puede significar que el lector no es visible para el bus. Chequea que está bién configurado en lo referente a master/slave si es IDE (ATAPI).

Algunas veces un CDROM SCSI puede "desaparecer" por que no ha tenido tiempo suficiente para responder a un reset del bus. Si tienes un CDROM SCSI, añade la siguiente línea en el archivo de configuración del kernel y recompílalo.

options "SCSI_DELAY=15"
          

Si es paralelo, y el único problema es la lentitud, intenta configurar el puero de impresora en modo "polled":

lptcontrol -p
          

Algunas impresoras nuevas de HP son conocidas por no trabajar correctamente en modo de interrupción, aparentemente debido (y todavía no exactamente entendido), a un problema de "timing".

Esto puede ser por hardware erróneo (memoria, placa base, etc). Intenta ejecutar algún programa de test de memoria. Ten en cuenta que es posible que tu memoria pase el test del programa que uses, pero que falle en algunas condiciones de uso, como en compilación de kernel.

La FAQ SIG11 (listada más abajo) apunta a problemas de lentitud de memoria. Incrementa el número de "wait states" en tu BIOS o instala una memoria más rápida.

También puedes intentar desactivar el caché de placa base en el BIOS y comprueba si se resuelve el problema.

Hay una extensa FAQ en the SIG11 problem FAQ

Este es un problema conocido con las tarjetas de vídeo ATI Mach 64. El problema es que esta tarjeta usa la dirección 2e8, también usada por el puerto serie 4. Debido a un bug (feature?) en el driver sio.c , éste "tocará" este puerto aunque no esté instalado o esté desactivado.

Hasta que el problema sea fijado, puedes hacer esto:

1. Teclea -c en el prompt de arranque. Esto te llevará a la sección de configuración del kernel.

2. Desactiva sio0, sio1, sio2 y sio3 (todos ellos). De esta manera, el driver sio no se activa.

3. Teclea exit para seguir arrancando.

Si quieres ser capaz de usar tus puertos serie, tendrás que compilar un nuevo kernel con la siguiente modificación: /usr/src/sys/i386/isa/sio.c. Busca la cadena 0x2e8 y borra esta cadena y la coma anterior (mantén la coma siguiente). Ahora, compila un nuevo kernel de la manera habitual.

Después de realizar estos cambios, puedes encontrarte aun que las X Window no funcionan correctamente. Algunas tarjetas de vídeo modernas ATI Mach 64 (especialmente la ATI Mach Xpression) no funcionan con la versión actual de XFree86; la pantalla se queda negra cuando arrancas las X o ocurren cosas extrañas en su funcionamiento. Puedes instalar una versión beta del nuevo servidor X que trabaja mejor, situada en el servidor XFree86 y seguir los links hasta el download. Coge los siguientes archivos:

AccelCards, BetaReport, Cards, Devices, FILES, README.ati, README.FreeBSD, README.Mach64, RELNOTES, VGADriver.Doc, X312BMa64.tgz

Reemplaza los viejos archivos por las nuevas versiones y asegúrate de ejecutar de nuevo xf86config.

Debido a la forma que tiene FreeBSD de "ver" el tamaño de memoria en el BIOS, solo puede detectar 16 bits (65535 Kbytes = 64MB) (o menos... algunas BIOS fijan el tamaño de la memoria a 16MB).

Para solucionar este problema, tienes que usar la opción del kernel indicada más adelante. Hay una manera de ver la información completa sobre memoria en el BIOS, pero no tenemos espacio en los bloques de arranque (bootblocks) para hacerlo. Por ahora, tenemos que trabajar con la opción del kernel.

options "MAXMEM=<n>"

Donde n es tu memoria en Kilobytes. Para 128MB, tendrías que usar 131072.

Nota El mensaje debería ser ``mb_map too small!''

La parada indica que el sistema no tiene memoria virtual suficiente para los buffers de red (específicamente, clusters mbuf). Puedes incrementar la cantidad de memoria virtual disponible para los clusters mbuf añadiendo:

options "NMBCLUSTERS=<n>"

al archivo de configuración del kernel, donde <n> es un número en el rango 512-4096, dependiendo del número de conexiones tcp simultáneas que necesites soportar. Te recomendamos intentar con 2048. Puedes monitorizar el número de clusters mbuf en uso con la orden netstat -m.

El programa que intenta detectar archivos /var/db/kvm_*.db puede fallar y provocar el "panic" en el arranque.

Si esto ocurre, arranca en mono-usuario y haz:

rm /var/db/kvm_*.db
          

Esto significa un conflicto con una controladora Ultrastor SCSI.

Durante el proceso de arranque, entra en el menú de configuración del kernel y desactiva el dispositivo uha0.

Esto está contestado en la FAQ de sendmail de la siguiente manera:

            * Tengo el error "Local configuration error" :

            553 relay.domain.net config error: mail loops back to myself
            554 <user@domain.net>... Local configuration error

            Cómo puedo solventar el problema?

            Has intentado enviar un mail al dominio domain.net y que sea
            reenviado a un host específico (en este caso relay.domain.net)
            usando un registro MX, pero la máquina que tiene que aceptar
            ese mail, no reconoce el domimio como propio. Añade
            domain.net al archivo /etc/sendmail.cw (si estás usando
            FEATURE(use_cw_file) o añade "Cw domain.net" al archivo
            sendmail.cf
          

La versión actual de la FAQ de sendmail puede ser encontrada en comp.mail.sendmail, comp.mail.misc, comp.mail.smail, comp.answers, y news.answers. Tambien puedes recibir una copia enviando un mail a mail-server@rtfm.mit.edu con el comando "send usenet/news.answers/mail/sendmail-faq" en el cuerpo del mensaje.

Quizás la máquina remota tiene el tipo de terminal diferente de cons25 que es el usado por la consola de FreeBSD.

Hay diferentes maneras de solucionar este problema:

• Después de hacer el login en la máquina remota, configura la variable SHELL como ANSI o sco.

• Usa el emulador VT100 como screen local. screen te permite la posibilidad de ejecutar múltiples y concurrentes sesiones desde un terminal.

• Instala la base de datos del terminal cons25 en la máquina remota.

• Lanza las X y haz el login en la máquina remota desde xterm.

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.