PCMCIA Como 3

Página siguiente Página anterior Índice general

---

3. Resolución de problemas de instalación y configuración

Esta sección describe algunos de los errores más comunes del subsistema PCMCIA. Compare sus síntomas con los ejemplos. Esta sección sólo describe fallos generales que no son específicas de un controlador o tipo de tarjeta en particular.

Antes de diagnosticar un problema, debe saber dónde se almacena el registro del sistema (revise la sección Notas acerca de distribuciones de Linux específicas). Debe estar familiarizado con las herramientas básicas de diagnóstico como dmesg y lsmod. Preste especial atención al hecho de que muchos componentes de los controladores (incluyendo todos los módulos del kernel) tienen sus propias páginas individuales en el manual.

Intente definir su problema lo más ampliamente posible. Si tiene varias tarjetas, pruebe cada tarjeta de forma aislada, y en diferentes combinaciones. Intente arranques de Linux en frío y arranques en caliente de Windows. Compare el arrancar con tarjetas insertadas, o insertar las tarjetas después de iniciar. Si normalmente usa su portátil ensamblado con una dockstation, prúebelo aparte. Algunas veces, dos bahías se comportarán de forma diferente.

Es casi imposible depurar problemas de un controlador cuando se intenta instalar Linux por medio de un dispositivo PCMCIA. En lugar de eso, si puede identificar el problema basándose en los síntomas, los discos de instalación son difíciles de modificar, especialmente sin tener acceso a un sistema Linux ya funcionando. La personalización e instalación de los discos de instalación es completamente dependiente de la distribución de Linux que elija, y más allá del enfoque de este documento. En general, el mejor curso de acción es instalar Linux usando otros medios, obteniendo los controladores más recientes, y depurando el problema entonces, si es que persiste.

3.1 No se cargan los módulos básicos de PCMCIA.

Síntomas:

• Aparecen errores acerca de que la versión del kernel difiere cuando se ejecuta el script de inicio de PCMCIA.
• Después de iniciar, lsmod no muestra algún módulo PCMCIA.
• cardmgr informa no pcmcia driver in /proc/devices en el registro del sistema.

Los módulos del kernel contienen información de la versión, la cual se comprueba con el kernel actual cuando se carga un módulo. El tipo de chequeo depende de la opción del kernel CONFIG_MODVERSIONS. Si es falso, entonces el número de versión del kernel se compila dentro de cada módulo y el programa insmod comprueba esto para compararlo con el kernel actual. Si CONFIG_MODVERSIONS es verdadero, entonces cada símbolo exportado por el kernel tiene un «checksum». Esos códigos se comparan con los códigos correspondientes compilados dentro de un módulo.

La idea de esto fue crear módulos menos dependientes de la versión, porque los checksums sólo pueden cambiar si la interface del kernel cambia, y podría generalmente permanecer a lo largo de actualizaciones menores del kernel. En esencia, los «checksums» se han desactivado para ser mas restrictivos, porque muchas interfaces del kernel dependen de las opciones pasadas al momento de compilarse. También, los checksums han resultado ser jueces excesivamente pesimistas respecto a compatibilidad.

El enfoque práctico de esto es que los módulos del kernel están muy atados a tanto la versión del kernel, como a muchas opciones de configuración del mismo. Generalmente, un grupo de módulos compilados para un kernel 2.0.31 no cargará con otros kernels 2.0.31 a menos que se tome un cuidado especial asegurándose que los dos fueron compilados con configuraciones similares. Esto resulta ser un asunto difícil para la distribución de módulos precompilados del kernel.

Tiene Vd. varias opciones:

• Si obtuvo controladores precompilados como parte de una distribución de Linux, verifique que esté usando el mismo kernel que venía con su distribución, sin modificaciones. Si pretende usar los módulos precompilados que venían con su distribución, deberá permanecer con el mismo kernel que trajera ésta.
• Si ha reconfigurado o actualizado su kernel, probablemente necesitará compilar e instalar el paquete PCMCIA desde cero. Esto se hace fácilmente si ya tiene instalada la estructura fuente del kernel. Revise la sección Compilación e instalación para instrucciones más detalladas.
• En algunos casos, las incompatibilidades en otros componentes del sistema pueden prevenir la carga correcta de los módulos del kernel. Si ha actualizado su propio kernel, ponga atención a la sección Requisitos acerca de utilidades para módulos y binutils que se listan en el archivo Documentation/Changes del árbol de directorios de los fuentes del kernel.

3.2 Algunos módulos controladores no cargan

Síntomas:

• Los módulos base (pcmcia_core, ds, i82365) cargan correctamente.
• Al insertar una tarjeta, emite un pitido agudo + un pitido grave.
• cardmgr informa de errores de versiones diferentes en el registro del sistema.

Algunos de los módulos controladores requieren servicios del kernel que pueden o no estar presentes, dependiendo de la configuración del kernel. Por ejemplo, los controladores de tarjetas SCSI requieren que el kernel sea compilado con soporte SCSI, y los controladores de red requieren un kernel de red. Si a un kernel le falta una característica necesaria, insmod puede avisar acerca de símbolos indefinidos y rechazar la carga de un módulo en particular. Note que los mensajes de error de insmod no distinguen entre errores por diferencias de versiones y errores por falta de símbolos.

Específicamente:

• El controlador serie serial_cs requiere que el soporte en el kernel esté activado con CONFIG_SERIAL. Este controlador se debe compilar como módulo.
• El soporte para tarjetas serie multipuerto o tarjetas multifunción que incluyen dispositivos serie o módems, requieren que se active CONFIG_SERIAL_SHARE_IRQ.
• Los clientes SCSI requieren que CONFIG_SCSI esté activada, junto con las opciones apropiadas para los controladores de alto nivel (CONFIG_BLK_DEV_SD, CONFIG_BLK_DEV_SR etc. para kernels 2.1) que pueden ser compilados como módulos.
• Los controladores de red requieren que se habilite CONFIG_INET El soporte para red del kernel no se puede compilar como módulo.
• El cliente token-ring requiere que el kernel se compile con la opción CONFIG_TR activada.

Hay dos formas de proceder:

• Recompile el kernel con las características necesarias activadas.
• Si las características han sido compiladas como módulos, entonces modifique /etc/pcmcia/config para precargar esos módulos.

El archivo /etc/pcmcia/config puede especificar qué módulos adicionales necesitan cargarse para un cliente en particular. Por ejemplo, para el controlador serial, uno puede ser:

       device "serial_cs"
         class "serial" module "misc/serial", "serial_cs"

Las rutas hacia los módulos se especifican relativas al nivel más alto del directorio de módulos para la versión actual del kernel; si no se especifica la ruta relativa, entonces la ruta por omisión será hacia el subdirectorio pcmcia.

3.3 fallos en la búsqueda de interrupciones

Síntomas:

• El sistema se congela cuando se cargan los controladores PCMCIA, incluso cuando no hay tarjetas presentes.
• El registro del sistema muestra que el sondeo tuvo éxito, justo antes de que se congele, pero no muestra resultados de las pruebas de interrupciones.

Después de identificar el tipo de controlador, el controlador del socket sondea las interrupciones libres. Este «sondeo» o «tanteo» consiste en programar el controlador para cada interrupción aparentemente libre, generando una interrupción soft (suave), para ver si la interrupción puede ser detectada correctamente. En algunos casos, el sondear una interrupción en particular puede interferir con otro dispositivo del sistema.

La razón de este «tanteo» es identificar interrupciones que parezcan estar libres (es decir, aquellas que no están reservadas por otro controlador de dispositivo), ya sea porque no esté conectado físicamente a la controladora, o que esté conectado a otro dispositivo que no tiene un controlador.

En el registro del sistema, un sondeo realizado con éxito tiene este aspecto:

       Intel PCIC probe:
         TI 1130 CardBus at mem 0x10211000, 2 sockets
         ...
         ISA irqs (scanned) = 5,7,9,10 status change on irq 10

Hay dos formas de proceder:

• El sondeo de interrupciones puede estar restringida a una lista de interrupciones utilizando el parámetro irq_list para los controladores. Por ejemplo, irq_list=5,9,10 limitará la búsqueda a tres interrupciones. Todos los dispositivos PCMCIA estarán restringidos a usar esas interrupciones (asumiendo que pasen el tanteo). Puede ser que necesite determinar qué interrupciones son tanteables de forma segura a base de ensayo y error.
• El sondeo de interrupciones puede desactivarse completamente al cargar el controlador del socket con la opción do_scan=0. En este caso, se usará una interrupción por omisión, la cual evita interrupciones ya utilizadas por otros dispositivos.

En cualquier caso, las opciones de tanteo pueden especificarse en el script de inicio de PCMCIA utilizando la definición PCIC_OPTS, por ejemplo:

        PCIC_OPTS="irq_list=5,9,10"

Como podrá notar, /proc/interrupts es absolutamente inútil cuando se van a diagnosticar problemas en el sondeo de interrupciones. El tanteo es lo suficientemente sensible como para nunca intentar usar una interrupción que ya está en uso por otro controlador de Linux. Los controladores PCMCIA están ya teniendo en cuenta toda la información de /proc/interrupts. Dependiendo del diseño del sistema, un dispositivo inactivo puede todavía ocupar una interrupción y causar problemas si es probado por PCMCIA.

3.4 Fallos en la búsqueda de puertos de E/S

Síntomas:

• El sistema se congela cuando cardmgr se inicia por primera vez, incluso cuando no hay tarjetas presentes.
• El registro del sistema muestra un tanteo positivo del controlador del host, incluyendo resultados de sondeos de interrupción, pero no muestra resultados de sondeos de E/S.
• En algunos casos, el tanteo de E/S será positivo, pero avisa de un gran número de de exclusiones aleatorias.

Cuando cardmgr procesa los rangos de puertos de E/S listados en /etc/pcmcia/config.opts, el kernel tantea esos rangos para detectar los dispositivos latentes que ocupan espacio de E/S pero que no están asociados con un controlador de Linux. El tanteo es de sólo lectura, pero en algunos casos extraños, leer desde un dispositivo puede interferir con una función importante del sistema, resultando en «congelamiento».

La guía de usuario de su sistema debe traer un mapa de los dispositivos del sistema, mostrando sus rangos de E/S y de memoria. Esos pueden ser excluidos explícitamente en config.opts.

Por otra parte, si el sondeo no resulta fiable en su sistema, puede ser desactivado estableciendo CORE_OPTS a probe_io=0. En este caso, deberá ser muy cuidadoso al especificar solamente rangos de puertos genuinamente disponibles en config.opts, en lugar de usar las configuraciones por omisión.

3.5 Fallos durante la comprobación de la memoria

Síntomas:

• Los controladores principales cargan correctamente cuando no hay tarjetas presentes, sin errores en el registro del sistema.
• El sistema se congela y/o reinicia tan pronto como se inserte una tarjeta antes de que se escuche algún pitido.

O alternativamente:

• Todas las inserciones de tarjetas generan un pitido agudo seguido de un pitido grave.
• Todas las tarjetas son identificadas como anonymous memory cards
• El registro del sistema avisa que varios rangos de memoria han sido excluidos.

Los módulos principales realizan un chequeo de los primeros 16 bits de memoria en el momento en que se inserta la tarjeta. Esta exploración puede interferir potencialmente con otros dispositivos de memoria mapeados. Así mismo, los paquetes de controladores pre-3.0.0 realizan una exploración más agresiva que los controladores más recientes. La ventana de memoria se define en /etc/pcmcia/config.opts. La ventana por omisión es grande, así que puede ayudar a restringir la exploración a un rango más reducido. Los rangos razonables para incluir son: 0xd0000-0xdffff, 0xc0000-0xcffff, 0xc8000-0xcffff, o 0xd8000-0xdffff.

Si tiene controladores PCMCIA DOS o Windows, puede deducir que región de memoria usan esos controladores. Tenga en cuenta que las direcciones de memoria de DOS se especifican normalmente en forma de «segmentos», los cuales dejan el último dígito hexadecimal (así una dirección absoluta de 0xd0000 puede darse como 0xd000). Asegúrese de añadir el dígito extra de cuando haga los cambios a config.opts.

En casos no muy usuales, un fallo en el sondeo de memoria puede indicar un problema de configuración en la sincronización con el controlador. Revise la sección Opciones de inicio para más información acerca de cómo combatir los problemas comunes de sincronización.

• cs: warning: no high memory space available!

Los puentes CardBus pueden reservar ventanas de memoria fuera del «agujero de memoria» de 640KB-1MB en la arquitectura de bus ISA. Generalmente es buena idea el configurar puentes CardBus para usar ventanas de memoria alta, porque es muy difícil que existan conflictos con otros dispositivos. También, las tarjetas CardBus pueden requerir grandes ventanas de memoria, las cuales puede ser difícil o imposible que coincidan en memoria baja. Los servicios de tarjetas preferentemente localizarán las ventanas en memoria alta para puentes CardBus, si ambas ventanas de memoria (alta y baja) se definen en config.opts. El archivo config.opts por omisión ahora incluye una ventana de memoria alta de 0xa0000000-0xa0ffffff. Si tiene un puente CardBus y ha actualizado de una versión de PCMCIA anterior, añada esta ventana de memoria si no está ya definido.

En algunos casos, la ventana de memoria alta por omisión no se utiliza.

En algunos modelos IBM Thinkpad, una ventana de 0x60000000-0x60ffffff funcionará en lugar de la ventana por omisión.

3.6 Fallo al detectar cuando se inserta o se extrae la tarjeta

Síntomas:

• Las tarjetas se detectan y configuran apropiadamente si están presentes al momento de iniciar.
• Los controladores no responden a los eventos de inserción y extracción, ya sea registrando los eventos en el registro del sistema, o emitiendo pitidos.

En muchos casos, el controlador del socket (i82365 o tcic) probará automáticamente y seleccionará la interrupción apropiada para señalar cambios en el estado de la tarjeta. El tanteo automático de interrupciones no funciona con algunos controladores compatibles con Intel, incluyendo los chips Cirrus y los chips usados en IBM Thinkpads. Si un dispositivo está inactivo en el momento del sondeo, su interrupción puede parecer estar disponible. En esos casos, el controlador del socket puede usar una interrupción que es usada por otro dispositivo.

Con los controladores i82365 y tcic la opción list_irq puede usarse para limitar las interrupciones que serán tanteadas. Esta lista limita el conjunto de interrupciones que pueden ser utilizadas por las tarjetas PCMCIA así como para monitorizar los cambios en el estado de la tarjeta. La opción cs_irq puede usarse también para establecer explícitamente la interrupción que será utilizada para monitorizar dichos cambios.

Si no puede encontrar un número de interrupción que funcione, hay también un estado en modo de búsqueda: ambos, i82365 y tcic aceptarán una opción poll_interval=100, para buscar cambios en el estado de la tarjeta una vez por segundo. Esta opción puede usarse también si su sistema tiene un rango corto de interrupciones disponibles para utilizarse con tarjetas PCMCIA. Especialmente para sistemas con más de un controlador de host, hay un pequeño punto para dedicar interrupciones para monitorizar cambios de estado de la tarjeta.

Todas esas opciones deberían establecerse en la línea PCIC_OPTS= ya sea en /etc/rc.d/rc.pcmcia o en /etc/sysconfig/pcmcia, dependiendo de la configuración de su sistema.

3.7 Faltan recursos del sistema

Síntomas:

• Cuando se inserta una tarjeta, es identificada correctamente, pero no puede ser configurada (secuencia de pitidos agudos/graves).
• Aparecen en el registro del sistema alguno de los siguientes mensajes:

         RequestIO: Resource in use
         RequestIRQ: Resource in use
         RequestWindow: Resource in use
         GetNextTuple: No more items
         could not allocate nn IO ports for CardBus socket n
         could not allocate nnK memory for CardBus socket n
         could not allocate interrupt for CardBus socket n
  

La reserva de interrupciones indica generalmente un problema con el sondeo de interrupciones, véase la sección Fallos en la búsqueda de interrupciones.

En algunos casos, el tanteo parece funcionar, pero únicamente aparecen una o dos interrupciones disponibles. Revise el registro de su sistema para ver si los resultados de la exploración son plausibles. Desactivar el tanteo y seleccionar las interrupciones manualmente puede ayudar.

Si el sondeo de interrupciones no está funcionando adecuadamente, el controlador del socket puede reservar una interrupción para monitorizar inserciones de tarjetas, incluso cuando las interrupciones sean demasiado escasas para esto, constituye una buena idea. En este caso, puede Vd. cambiar el controlador a modo de búsqueda estableciendo PCIC_OPTS a poll_interval=100. O, si tiene un controlador CardBus, intente con pci_csc=1, el cual selecciona una interrupción PCI (si está disponible) para cambios de estado en la tarjeta.

La reserva de puertos de E/S no es muy común, pero algunas veces tiene lugar con tarjetas que requieren regiones de espacio de E/S grandes, contiguas y alineadas, o que sólo reconocen pocas posiciones específicas de puertos. Los rangos de puertos de E/S por omisión en /etc/pcmcia/config.opts normalmente son suficientes, pero pueden ser extendidos. En casos extraños, la reserva puede indicar que falló el sondeo de puertos de E/S; revise la sección fallos en la búsqueda de puertos de E/S.

La reserva de memoria no es común tampoco con las configuraciones de la ventana de memoria que vienen por omisión en config.opts. Las tarjetas CardBus pueden requerir regiones de memoria más grandes que las tarjetas típicas de 16-bits. Dado que de que las ventanas de memoria de las tarjetas CardBus pueden ser mapeadas a cualquier parte del espacio de la dirección PCI del host (en lugar de sólo mapearlo al «agujero» de 640K-1MB en sistemas PC), es de utilidad especificar ventanas de memoria amplias en la memoria alta, tales como 0xa0000000-0xa0ffffff.

3.8 Conflicto de recursos entre dos tarjetas

Síntomas:

• Dos tarjetas funcionan bien cuando se usan separadamente.
• Cuando ambas tarjetas se insertan, sólo funciona una.

Esto usualmente indica un conflicto de recursos con un dispositivo del sistema que Linux no conoce. Los dispositivos PCMCIA son configurados dinámicamente, así, por ejemplo, las interrupciones son reservadas conforme se vayan necesitando, en lugar de ser asignadas específicamente a tarjetas o sockets en particular. Dada una lista de recursos que parecen estar disponibles, las tarjetas son recursos asignados en el orden en que son configurados. En este caso, a la tarjeta configurada en último lugar se le está asignando un recurso que en efecto, no está libre.

Revise el registro del sistema para ver qué recursos están usados por la tarjeta que no funciona. Exclúyalos de /etc/pcmcia/config.opts, y reinicie el demonio cardmgr para recargar la base de datos de recursos.

3.9 No se completa la configuración de dispositivos

Síntomas:

• Cuando se inserta una tarjeta, se escucha un pitido agudo.
• Las inserciones y extracciones posteriores de tarjetas son ignoradas.

Esto indica que la tarjeta fue identificada con éxito, sin embargo, cardmgr fue incapaz de completar el proceso de configuración por alguna razón. La más común es que un paso en el script de configuración se ha bloqueado. Un buen ejemplo podría ser el script de red bloqueándose si una tarjeta de red se inserta sin tener presente una conexión a la red.

Para verificar el problema, puede ejecutar manualmente un script de configuración para ver dónde se está bloqueando. Los scripts están en el directorio /etc/pcmcia. Toman dos parámetros: un nombre de dispositivo, y una acción. El demonio cardmgr graba los comandos de configuración en el registro del sistema. Por ejemplo, si el registro del sistema muestra que el comando ./network start eth0 fue el último comando ejecutado por cardmgr, el siguiente comando puede rastrear el script:

       sh -x /etc/pcmcia/network start eth0

---

Página siguiente Página anterior Índice general