<!-- 0,1 -->
<!-- PCMCIA,0 -->
<!-- David,Hinds,dhinds@hyper.stanford.edu -->
<!-- 2.40,1999-09-10 -->
<!-- PCMCIA -->
<!-- David,Limón Romero,dlr@cuates.pue.upaep.mx -->
<!-- 2.40,1999-09-10 --> 
<!-- PCMCIA,CardBus,Laptop,Portátil,ToPic,PCIC,TCIC,pcmcia-cs,cardctl,cardinfo,i82365,config.opts,cardmgr,serial_cs,pcmcia_core,stab,aha152x_cs,network.opts,pcnet_cs,serial.opts,config.opts,parport_cs,parport_pc,parport.opts,qlogic_cs,toaster_cs,fdomain_cs,scsi.opts,memory_cs,memory.opts,CIS,ftl.opts,FTL,ftl_format,ftl_cs,ide_cs,ide.opts,ide_info,pcinitrd,dump_tcic,dump_cis,dump_i365,dump_tuples,dump_cisreg,memory_cb,pccard -->
<!-- Hardware,PCMCIA -->

<!-- Revisión gramatical y sgml v0.6  991003              	-->
<!-- Fco. J. Montilla, pacopepe@insflug.org			-->

<!doctype linuxdoc system>

<article>

<title>Linux PCMCIA COMO <author>David Hinds, <tt><htmlurl
url="mailto:dhinds@hyper.stanford.edu" 
name="dhinds@hyper.stanford.edu"></tt>&nl; Traducido por David Limón
Romero, <tt><htmlurl url="mailto:dlr@cuates.pue.upaep.mx" 
name="dlr@cuates.pue.upaep.mx"></tt>

<date>Original: v2.40, 10 Septiembre 1999

<abstract> 

Este documento describe cómo instalar y usar los servicios de las tarjetas
PCMCIA con Linux. Las últimas versiones de este documento puede
encontrarlas siempre en <tt><htmlurl
url="ftp://hyper.stanford.edu/pub/pcmcia/doc" 
name="ftp://hyper.stanford.edu/pub/pcmcia/doc"></tt>. La versión en HTML
está en <tt><htmlurl
url="http://hyper.stanford.edu/HyperNews/get/pcmcia/home.html" 
name="http://hyper.stanford.edu/HyperNews/get/pcmcia/home.html"></tt>

</abstract>

<toc>

<sect>Información general y requerimientos de hardware 
<label id="general">
<p>

<sect1>Introducción 
<label id="introduccion">
<p>

Los Servicios de Tarjeta para Linux son un paquete de soporte completo
para PCMCIA o <it/PC Card/. Incluye un conjunto de módulos cargables en el
kernel que implementan una versión de la interface del programa de
aplicación de Servicios de Tarjetas, un conjunto de controladores de
clientes para tarjetas específicas, y un demonio controlador de tarjetas
que responde a los eventos de inserción y extracción de tarjetas, el cual
carga y descarga los controladores según sea necesario. Soporta
«extracción en caliente» de la mayoría de tarjetas, por lo que pueden ser
insertadas y extraídas de forma segura en cualquier momento.

Este software está en continuo desarrollo. Probablemente contenga
<it/bugs/, y debe ser usado con precaución. Haré lo que esté en mi mano
para resolver los problemas que me son comunicados, pero si no me los
dice, nunca lo sabré. Si usa este código, espero que me envíe sus
experiencias, ¡buenas o malas!

Si tiene sugerencias de cómo puede mejorarse este documento, por favor
hágamelo saber (<tt><htmlurl url="mailto:dhinds@hyper.stanford.edu" 
name="dhinds@hyper.stanford.edu"></tt>).

<sect1>Licencia y renuncia de responsabilidad 
<label id="licencia">
<p>

Derechos Reservados &copy; 1998 David A. Hinds 

Este documento puede ser reproducido o distribuido en cualquier forma sin
mi permiso previo. Las versiones modificadas de este documento, incluyendo
traducciones a otros idiomas, pueden ser distribuidos libremente, si son
claramente identificados como tales, y siempre que este copyright se
incluya intacto.

Este documento puede ser incluído en distribuciones comerciales sin mi
previo consentimiento. Aunque no suponga requisito, me gustaría estar
informado de su uso. Si pretende incorporar este documento en un trabajo
para ser publicado, por favor contacte conmigo para asegurarme que tiene
la última versión disponible. 

Este documento se proporciona «TAL CUAL», sin garantías expresas o
implícitas. Utilice la información en este documento bajo su propio
riesgo. 

<sect1>¿Cuál es la última versión, y dónde puedo obtenerla? 
<label id= "ultima">
<p>

La versión actual de los Servicios de Tarjetas es la <tt/3.0/, y las
actualizaciones menores o reparaciones de <it/bugs/ se numeran <tt/3.0.1/,
<tt/3.0.2/, y así sucesivamente.

El código fuente de la última versión está disponible en <tt><htmlurl
url="ftp://hyper.stanford.edu"  name="ftp://hyper.stanford.edu"></tt> en
el directorio <tt>/pub/pcmcia</tt> como <tt>pcmcia-cs-3.0.?.tar.gz.</tt>
Habrá usualmente varias versiones ahí.  Por lo general, solo conservo la
última versión menor para dar origen a una versión mayor. 
  
Las nuevas versiones pueden contener código relativamente sin probar, así
que también conservo la última versión de la última mayor como «colchón»
relativamente estable; el retraso actual es <tt/2.9.12/. Vd. decide qué
versión es más apropiada, el archivo <tt/CHANGES/ mostrará las diferencias
más importantes. 

<tt><htmlurl url="ftp://hyper.stanford.edu" 
name="ftp://hyper.stanford.edu"></tt> es replicado en <tt><htmlurl
url="ftp://sunsite.unc.edu" name="ftp://sunsite.unc.edu"></tt> (y todos
los servidores réplica de <it/Sunsite/) en
<tt>/pub/Linux/kernel/pcmcia</tt>. 

Si no se siente Vd. a gusto compilando controladores, hay controladores
precompilados incluidos con las versiones actuales de la mayoría de las
distribuciones principales de Linux, incluyendo <it/Slackware/,
<it/Debian/, <it/Red Hat/, <it/Caldera/, <it/SuSE/, e <it/Yggdrasil/,
entre otros. 

<sect1>¿Qué sistemas están soportados? 
<label id="sistemas">
<p>

Este paquete debería correr en la mayoría de portátiles basados en Intel y
que sean «Linuxizables». También corre en plataformas basadas en Alpha
(<it/DEC Multia/, por ejemplo). Se programa para hacer al paquete
completamente <it/dual-endian/, así que también soporta plataformas
basadas en <it/PowerPC/ (<it/Apple Powerbooks/, por ejemplo). Los
controladores de <it/sockets/ más comunes están soportados. Las bahías de
tarjetas PCMCIA para sistemas de escritorio deben funcionar si usan un
controlador soportado, y se conectan directamente al bus ISA o PCI, lo
opuesto a los adaptadores SCSI-a-PCMCIA o IDE-a-PCMCIA.

Están soportados los siguientes controladores:

<itemize>

<item>Cirrus Logic PD6710, PD6720, PD6722, PD6729, PD6730, PD6732, PD6832

<item>Intel i82365sl B, C, y secuencias DF, 82092AA

<item>O2Micro OZ6729, OZ6730, OZ6832, OZ6833, OZ6836, OZ6860

<item>Omega Micro 82C092G

<item>Ricoh RF5C296, RF5C396, RL5C465, RL5C466, RL5C475, RL5C476, RL5C478

<item>SMC 34C90

<item>Texas Instruments PCI1130, PCI1131, PCI1210, PCI1220, PCI1221,
PCI1250A, PCI1251A, PCI1251B, PCI1450

<item>Toshiba ToPIC95, ToPIC97 (experimental)

<item>Vadem VG465, VG468, VG469

<item>VLSI Technologies 82C146, VCF94365

<item>VIA VT83C469

<item>Databook DB86082, DB86082A, DB86084, DB86084A, DB86072, DB86082B

</itemize>

Otros controladores que están registrados como compatibles con el Intel
<it/i82365sl/, funcionarán también como norma general.

El soporte para tarjetas <it/CardBus/ de 32 bits es todavía experimental. 
Los manejadores previos a la versión <tt/3.0/ sólo soportan tarjetas de 16
bits en sockets <it/CardBus/. Debido al paso tan rápido en el cambio de la
tecnología para el hardware de portátiles, aparecen nuevos controladores
frecuentemente, y puede producirse cierto estancamiento entre el momento
en que aparece un nuevo modelo en el mercado, y el que haya soporte para
ese controlador.

Toshiba ha dispuesto parcialmente documentación sobre sus chipsets
<it/ToPIC95/ y <it/ToPIC97/, sin embargo, la información que han liberado
no ha sido la realmente adecuada. A pesar de los informes de conflictos,
Toshiba no ha hecho algún esfuerzo efectivo para remediar esta situación. 
Hay problemas serios en el soporte de Linux para los chipsets ToPIC, que
no pueden ser resueltos hasta que esté disponible una documentación mejor,
o la ayuda adecuada por parte de Toshiba. No recomiendo el uso de
portátiles Toshiba por el momento. Para el uso de tarjetas de 16 bits,
recomiendo establecer el modo de puente a <it/PCIC/ en la configuración de
la BIOS; para tarjetas <it/CardBus/, la decisión es suya. 

El controlador Motorola <it/6AHC05GA/ usado en portátiles Hyundai, no
está soportado. El controlador en la <it/HP Omnibook 600/ tampoco. 

<sect1>¿Qué tarjetas están soportadas? 
<label id="tarjetas">
<p>

La versión actual incluye controladores para una variedad de tarjetas
ethernet, para tarjetas módem y puertos serie, varios controladores para
adaptadores SCSI, un controlador para tarjetas de unidades ATA/IDE, y
controladores para tarjetas de memoria que sólo soportan la mayoría de
tarjetas SRAM y algunas tarjetas flash. El archivo <tt/SUPPORTED.CARDS/
incluído en cada versión de Servicios de Tarjetas lista todas las tarjetas
que se sabe que funcionan al menos en un sistema. 

La probabilidad de que funcione una tarjeta que no está en la lista de
soportados depende del tipo. Esencialmente todos los módems deberían
funcionar con el controlador provisto. Algunas tarjetas de red pueden
funcionar si hay versiones OEM de las tarjetas soportadas. Otro tipo de
tarjetas de E/S (<it/frame buffers/, tarjetas de sonido, etc) no
funcionarán hasta que alguien escriba los controladores apropiados. 

<sect1>¿Cuándo estará soportada mi tarjeta favorita (no soportada)? 
<label id="cuando">
<p>

Desafortunadamente, no me pagan por escribir controladores para
dispositivos, así que si quiere tener un controlador para su tarjeta
favorita, probablemente tendrá trabajar un poco.  Idealmente, me gustaría
trabajar hacia un modelo como el del kernel de Linux, donde yo sea el
responsable principalmente del código del núcleo y otros autores puedan
contribuir y mantener los controladores para tarjetas específicas. El
archivo <tt>SUPPORTED.CARDS</tt> menciona algunas tarjetas para las cuales
los controladores están actualmente en progreso. Trataré de ayudar donde
pueda, pero tenga en cuenta que depurar controladores de dispositivo del
kernel por email no es particularmente efectivo.

Los fabricantes interesados en ayudar a proveer soporte Linux para sus
productos pueden contactar conmigo a fin de acordar consultorías.

<sect1>Listas de correo y otras fuentes de información 
<label id="listas">
<p>

Solía mantener una base de datos y una lista de correo de usuarios de
Linux PCMCIA. Recientemente he convertido mi página web para información
de Linux PCMCIA en un sitio <it/HyperNews/, con un conjunto de listas de
mensajes de temas de Linux PCMCIA. Hay listas para instalación y
configuración, para diferentes tipos de tarjetas, para programar y
depurar. La página de información de Linux PCMCIA está en <tt><htmlurl
url="http://hyper.stanford.edu/HyperNews/get/pcmcia/home.html"
name="http://hyper.stanford.edu/HyperNews/get/pcmcia/home.html"></tt>. Los
usuarios pueden solicitar otificación por email de nuevas respuestas a
preguntas particulares, o notificación para todos los mensajes nuevos en
una categoría dada. Espero que esto sea un repositorio útil de
información, para cuestiones que van más allá del enfoque del COMO.

Hay una lista de Linux dedicada a asuntos de portátiles, la lista
<tt/linux-laptop/. Para más información, envíe un mensaje con la palabra
<tt/help/ a <tt><htmlurl
url="mailto:majordomo@vger.rutgers.edu?subject=help" 
name="majordomo@vger.rutgers.edu"></tt>. Para suscribirse, envíe un email
que contenga el mensaje <tt/subscribe linux-laptop/ a la misma dirección.
Esta lista de correo puede ser un buen foro de discusión de asuntos de
Linux PCMCIA. 
 
La página de Linux Laptop está en <tt><htmlurl
url="http://www.cs.utexas.edu/users/kharker/linux-laptop" 
name="http://www.cs.utexas.edu/users/kharker/linux-laptop"></tt> tiene
enlaces a muchos sitios que tienen información acerca de la configuración
de tipos específicos de portátiles para Linux. Hay también una base de
datos para buscar información acerca de configuración de sistemas. 

<sect1>¿Por qué no distribuyen binarios? 
<label id="porqueno">
<p>

Para mi, distribuir los binarios puede suponer una molestia importante.
Esto es complicado porque algunas características solo pueden ser
seleccionadas al momento de compilar, y porque los módulos dependen mucho
de contar con una configuración «correcta» del kernel. Así, probablemente
necesite distribuir módulos precompilados junto con los kernels
correspondientes.  Más que esto, la necesidad más grande de los módulos
precompilados es cuando se instala Linux en un sistema limpio. Esto
típicamente requiere configurar los controladores para que puedan ser
utilizados en el proceso de instalación, para una distribución de Linux en
particular. Cada distribución de Linux tiene su propia idiosincrasia, y no
me resulta factible el proveer discos <tt/boot/ y <tt/root/ para cada una
de las combinaciones de controladores y distribuciones. 

PCMCIA forma parte ahora de las principales distribuciones de Linux,
incluyendo <it/RedHat/, <it/Caldera/, <it/Slackware/, <it/Yggdrasil/,
<it/Craftworks/ y <it/Nascent Technology/. 


<sect1>¿Por qué el paquete es tan grande? 
<label id="tangrande">
<p>

Bueno, no es realmente tan grande al fin y al cabo. Todos los módulos
controladores ocupan alrededor de 500K de espacio en disco. Los programas
de utilidades añaden unos 70K, y los scripts en <tt>/etc/pcmcia</tt> son
de 50K. Los controladores principales ocupan unos 55K de la memoria del
sistema. El demonio <tt/cardmgr/ será generalmente intercambiado excepto
cuando cuando las tarjetas sean insertadas o extraídas. El tamaño total
del paquete es comparable a las implementaciones de servicios de tarjetas
de DOS/Windows.


<sect>Compilación e instalación
<label id="compilacion">
<p> 

<sect1>Prerequisitos y configuración del kernel 
<label id="requisitos">
<p>

Antes de empezar, debería pensar si realmente necesita compilar el paquete
por sí mismo. Todas las distribuciones comunes de Linux vienen con
paquetes de controladores precompilados. Generalmente, sólo necesita
instalar los controladores si necesita una característica nueva de los más
actuales, o si ha actualizado y/o reconfigurado su kernel de forma que es
incompatible con los incluidos en su distribución de Linux. A pesar de que
compilar el paquete no es técnicamente difícil, requiere algo de
familiaridad general con Linux. 

Las siguientes cosas deben estar instaladas en su sistema antes de
comenzar: 

<itemize>

<item>El árbol de fuentes del kernel, serie <tt/2.0.*/,
<tt/2.1.*/, o <tt/2.2.*/

<item>Un conjunto apropiado de utilidades de módulos.

<item>La interface de utilidades <tt/XForms/ para X11 (Opcional).

</itemize>

Necesita tener la estructura completa del código fuente del kernel, no
sólo una imagen actualizada del kernel. Los módulos de los controladores
contienen algunas referencias a los archivos fuentes del kernel. Mientras
que Vd. busca compilar un kernel nuevo para eliminar manejadores
innecesarios, instalar PCMCIA no requiere que lo haga así. 

Los fuentes y parches «estables» actuales del kernel están disponibles en
&nl;  <tt><htmlurl url="ftp://sunsite.unc.edu/pub/Linux/kernel/v2.0" 
name="ftp://sunsite.unc.edu/pub/Linux/kernel/v2.0"></tt>, o en &nl;
<tt><htmlurl url=" ftp://tsx-11.mit.edu/pub/linux/sources/system/v2.0"
name="ftp://tsx-11.mit.edu/pub/linux/sources/system/v2.0"></tt> Los
kernels en desarrollo los puede encontrar en los subdirectorios <tt/v2.1/. 
las utilidades de módulos actuales puede encontrarlas en la misma
ubicación.

En los fuentes del kernel de Linux, el archivo
<tt>Documentation/Changes</tt> describe las versiones de todas las clases
de otros componentes del sistema que son requeridas por esa versión del
kernel. Probablemente quiera revisarlo y verificar que su sistema está
actualizado, especialmente si tiene actualizado el kernel. Si está usando
un kernel en desarrollo, asegúrese de estar usando la combinación correcta
de bibliotecas compartidas y herramientas de módulos. 

Cuando configure su kernel, si planea usar una tarjeta ethernet PCMCIA,
debe activar el soporte para red, y desactivar los controladores normales
de tarjetas de red de Linux, incluyendo <tt/pocket and portable adapters/. 
Todos los controladores para tarjetas de red PCMCIA están compilados como
módulos cargables. Cualquiera de los controladores compilados dentro de su
kernel sólo desperdiciará espacio. 

Si quiere usar SLIP, PPP o PLIP, necesitará ya sea configurar el kernel
con ese soporte activado, o usar la versión de los módulos cargables de
esos controladores. Hay una desafortunada deficiencia en el proceso de
configuración de los kernels <tt/1.2.X/, en el que no es posible
establecer opciones de configuración (como compresión SLIP) para un módulo
cargable, así que es probablemente mejor enlazar SLIP dentro del kernel si
es que lo necesita. 

Para usar un adaptador token ring PCMCIA, el kernel debe estar configurado
con la opción <tt/Token Ring driver support/ (<tt/CONFIG_TR/) activada,
aunque debe dejar <tt/CONFIG_IBMTR/ desactivado.

Si requiere usar un adaptador IDE PCMCIA, su kernel debe estar configurado
con la opción <tt/CONFIG_BLK_DEV_IDE_PCMCIA/ activada, para los kernels
desde <tt/2.0.*/ hasta <tt/2.1.*/. Los kernels antiguos no soportan
dispositivos IDE extraíbles; los nuevos no requieren una configuración
especial.

Si va a usar un adaptador SCSI PCMCIA, debe habilitar <tt/CONFIG_SCSI/
cuando configure el kernel. Debe activar también cualquier controlador de
alto nivel (disco SCSI, cinta, cdrom, genérico) que espere usar. Debe
desactivar todos los controladores de bajo nivel para adaptadores en
particular, porque sólo le quitarán espacio. 

Si busca modularizar un controlador que se necesita para un dispositivo
PCMCIA, debe modificar <tt>/etc/pcmcia/config</tt> para especificar qué
módulos necesitan ser cargados para qué tipos de tarjetas. Por ejemplo, si
el controlador serie está modularizado, entonces la definición del
dispositivo serie debería ser: 

<tscreen><verb>
       device "serial_cs"
         class "serial" module "misc/serial", "serial_cs"  
</verb></tscreen>

Este paquete incluye una utilidad llamada <tt/cardinfo/ que está basada en
X para monitorizar el estado de la tarjeta. Está basada en un <it/toolkit/
de libre distribución, la biblioteca <it/XForms/. Esta librería está
disponible como un paquete separado de la mayoría de distribuciones de
Linux. Si desea compilar <tt/cardinfo/, deberá instalar <tt/XForms/ y
todas las cabeceras y bibliotecas de desarrollo habituales para X antes de
configurar el paquete PCMCIA. 

<sect1>Instalación 
<label id="instalacion">
<p>

He aquí una sinopsis del proceso de instalación: 

<itemize>

<item>Descomprima <tt/pcmcia-cs-3.0.?.tar.gz/ en <tt>/usr/src</tt>

<item>Ejecute <tt>make config</tt> en el nuevo directorio 
<tt/pcmcia-cs-3.0.?/

<item>Ejecute <tt/make all/, y luego <tt/make install/.

<item>Configure el script de inicio y los archivos de opciones en <tt>
/etc/pcmcia</tt> para su sistema.

</itemize>

Si planea instalar cualquier controlador que sea una contribución y que no
esté incluído en la distribución principal de PCMCIA, descomprima cada uno
de ellos en el directorio raíz del árbol PCMCIA. Luego siga las
instrucciones normales de compilación. Los controladores extras se
compilarán e instalarán automáticamente.

Cuando ejecute <tt/make config/, se le preguntarán algunas opciones de
configuración y se comprobará su sistema para verificar que se satisfagan
todos los prerequisitos para instalar soporte PCMCIA. En la mayoría de los
casos, sólo tendrá que aceptar todas las opciones de configuración que
vienen por omisión. Asegúrese de comprobar cuidadosamente la salida de
éste comando en caso de que hubiera problemas. Están disponibles las
siguientes opciones: 

<descrip>

<tag/¿Hay un directorio de instalación alternativo?/Si está compilando el
paquete para instalarlo en otro equipo, especifique un directorio destino
alternativo cuando se le pregunte. Debe ser una ruta absoluta. Todos los
archivos serán instalados relativos a este directorio. Entonces estará
listo para aplicar <tt/tar/ a este directorio y copiarlo a su equipo
destino, y desempaquetarlo relativo a su directorio raíz para instalar
todo en los lugares apropiados.

<tag/¿Necesita indicadores de compilación para depurar?/Vea la sección
<ref id="aux" name="Primeros auxilios al depurar a bajo nivel"> para mayor
información acerca de esta opción. 

<tag/¿Necesita compilar versiones «trusting» de las utilidades de
tarjetas?/Algunas de las utilidades de soporte (<tt/cardctl/ y
<tt/cardinfo/) pueden ser compiladas ya sea de forma <tt>safe</tt> o
<tt>trusting</tt>. La forma <tt/safe/ previene a los usuarios no-root de
modificar configuraciones de tarjetas. La forma <tt/trusting/ permite a
los usuarios ordinarios ejecutar comandos para suspender y reactivar
tarjetas, resetear tarjetas, y cambiar el esquema de configuración actual. 
La forma configurada por omisión es <tt/safe/. 

<tag/¿Necesita incluir soporte para tarjetas de 32-bits (<it/CardBus/)?/
Deberá seleccionar esta opción si desea usar tarjetas <it/CardBus/ de
32-bits.  No se requiere para tener soporte con puentes <it/CardBus/ si
sólo planea usar tarjetas PC de 16-bits.

<tag/¿Necesita incluir chequeo de recursos para BIOS PnP?/Esto compila
código adicional en el módulo principal PCMCIA para comunicarse con el
BIOS PnP de un sistema para obtener información de los recursos que están
incluidos en la «placa madre» (puertos serie y paralelos, sonido, etc),
para ayudar a prevenir conflictos de recursos. Si se habilita, se crearán
algunos archivos extra de recursos bajo <tt>/proc/bus/pccard</tt>, y las
herramientas <tt/lspnp/ y <tt/setpnp/ se pueden usar para visualizar y
manipular los dispositivos PnP del BIOS. 

<tag/¿Cómo configurar opciones específicas del kernel?/Hay algunas
opciones de configuración del kernel que afectan a las herramientas
PCMCIA. El script de configuración puede deducirlo desde el kernel actual
(el caso por omisión y más común).  Alternativamente, si está compilando
para instalar en otro equipo, puede leer la configuración del árbol de los
fuentes del kernel, o cada opción se puede establecer interactivamente.

</descrip>

El script de configuración se puede ejecutar de forma no-interactiva, para
compilar automáticamente o para reconfigurar rápidamente después de una
actualización del kernel. Algunas opciones adicionales no utilizadas con
frecuencia sólo pueden ser establecidas desde la línea de comandos.
Ejecutando: <tt>Configure --help</tt> se listarán todas las opciones
disponibles. 

Al ejecutar <tt/make all/ seguido de <tt/make install/ compilará y luego
instalará los módulos del kernel y los programas de utilidades.  Los
módulos del kernel serán instalados en
<tt>/lib/modules/&lt;version&gt;/pcmcia</tt>. Los programas <tt/cardctl/ y
<tt/cardmgr/ serán instalados en <tt>/sbin</tt>. Si <tt/cardinfo/ se
compila, será instalado en <tt>/usr/bin/X11</tt>.

Los archivos de configuración serán instalados en el directorio
<tt>/etc/pcmcia</tt>. Si está instalando sobre una versión antigua, sus
scripts de configuración anteriores se respaldarán antes de ser
reemplazados. Los scripts guardados tendrán la extensión de tipo <tt/*.O/. 

Si no sabe qué tipo de controlador usa su sistema, puede utilizar la
utilidad <tt/probe/ en el subdirectorio <tt>cardmgr/</tt> para
determinarlo.  Hay dos tipos principales: el tipo <it/Databook TCIC-2/ y
el tipo compatible con Intel <it/i82365SL/.

En raras ocasiones, el comando <tt/probe/ será incapaz de determinar su
tipo de controlador automáticamente. Si tiene un sistema <it/Halikan NBD
486/, tiene un controlador <it/TCIC-2/ en una localización inusual:
necesitará editar <tt/rc.pcmcia/ para cargar el módulo <tt/tcic/, y
también especificar el parámetro <tt/PCIC_OPTS/ a <tt/tcic_base=0x02c0/. 

En algunos sistemas que usan controladores Cirrus, incluyendo el <it/Nec
Versa M/, la bios pone el controlador en un estado especial de suspensión
al iniciar el sistema. En esos sistemas, el comando <tt/probe/ fallará al
encontrar cualquier controlador conocido. Si esto pasa, edite <tt/
rc.pcmcia/ y especifica <tt/PCIC/ a <tt/i82365/, y <tt/PCIC_OPTS/ a
<tt/wakeup=1/. 
 
<sect1>Opciones de inicio
<label id="inicio">
<p>

El script de inicio de PCMCIA reconoce varios grupos de opciones de
inicio, establecidas por medio de variables de entorno. Se pueden separar
múltiples opciones por medio de espacios y encerradas en comillas. La
colocación de las opciones de inicio depende de la distribución de Linux
que se esté usando. Pueden ser colocados directamente en el script de
inicio, o pueden mantenerse en un archivo de opciones separado. Revise la
sección <ref id="distribuciones" name="Notas acerca de distribuciones de
Linux específicas"> para más detalles. Se pueden establecer las siguientes
variables: 

<descrip>

<tag/PCMCIA/Esta variable especifica si el soporte PCMCIA debe ser
iniciado o no. Si está especificado de forma diferente a <tt/yes/, el
script de inicio será desactivado. 

<tag/PCIC/Esto identifica el módulo controlador de <it/PC Card Interface
Controller/. Hay dos opciones: <tt/tcic/ o <tt/i82365/. Virtualmente todos
los controladores actuales están en el grupo <it/i82365/. Esta es la única
opción obligatoria a establecer. 

<tag/PCIC_OPTS/Esto especifica las opciones para el módulo PCIC. Algunos
controladores tienen características opcionales que pueden o no ser
implementadas en un sistema en particular. En algunos casos, es imposible
para el socket controlador detectar si esas características están
implementadas. Revise la página del manual correspondiente para una
descripción completa de las opciones disponibles. 

<tag/CORE_OPTS/Esto especifica las opciones para el módulo
<tt>pcmcia_core</tt>, el cual implementa los servicios principales del
controlador PC Card. Es conveniente echar un vistazo a <tt/man
pcmcia_core/ para más información.

<tag/CARDMGR_OPTS/Esto especifica las opciones que se pasarán al demonio
<tt/cardmgr/. Revise <tt/man cardmgr/ para más información. 

<tag/SCHEME/Si está activado, el esquema de configuración de PC Card será
inicializado a este modo en el momento de arrancar. Revise la sección <ref
id="configuracion" name="Un vistazo a los scripts de configuración de
PCMCIA"> para ver la discusión de esquemas. 

</descrip>

Los controladores de sockets de bajo nivel, <tt/tcic/ e <tt/i82365/,
tienen varios parámetros de sincronización de bus que pueden necesitar ser
ajustados para sistemas con velocidades de bus no muy usuales. Los
síntomas de los problemas de sincronización incluyen problemas al
reconocer las tarjetas, congelamiento bajo carga pesada, tasas de error
altas, o rendimiento pobre de dispositivos. Sólo ciertos puentes tienen
parámetros de sincronización ajustables, revise la página correspondiente
del manual para ver qué opciones existen para su controlador. He aquí un
pequeño resumen:

<itemize>

<item>Los controladores Cirrus tienen muchos parámetros de sincronización. 
Lo más importante parece ser el indicador <tt/cmd_time/, la cual determina
la longitud de los ciclos de bus PCMCIA. En los sistemas rápidos 486
(DX4-100, por ejemplo) parece ser beneficioso el incrementar esto de
<tt/6/ (por omisión) a <tt/12/ o <tt/16/. 

<item>El controlador Cirrus <it/PD6729 PCI/ tiene el indicador
<tt/fast_pci/, la cual debe establecerse si la velocidad del bus PCI es
mayor a 25 Mhz.

<item>Para controladores <it/Vadem VG-468/ y <it/Databook TCIC-2/, el
indicador <tt/async_clock/ cambia la velocidad relativa del bus PCMCIA y
los ciclos de bus del equipo. Activar este indicador añade estados de
espera extra a algunas operaciones. Sin embargo, todavía no he sabido de
ningún portátil que necesite esto.
  
<item>El módulo <tt/pcmcia_core/ tiene el parámetro <tt/cis_speed/ para
cambiar la velocidad de la memoria, la cual se usa para acceder a la
<it/Estructura de Información de Tarjeta/ (<it/Card Information
Structure/) (<it/CIS/) de una tarjeta. En algunos sistemas con pulsos de
bus rápidos, incrementar este parámetro (por ejemplo, reducir la velocidad
de los accesos a tarjeta) puede resultar beneficioso para quien tenga
problemas al reconocerlas.

<item>Esto no es cuestión de sincronización, pero si Vd. tiene más de un
controlador ISA-a-PCMCIA en su sistema o tiene bahías extra en una
estación, el módulo <tt/i82365/ debe ser cargado con el parámetro
<tt/extra_sockets/ establecido a <tt/1/. Esto no deberá ser necesario para
detección de puentes PCI-a-PCMCIA y PCI-a-CardBus.

</itemize>

He aquí algunas configuraciones de sincronización para algunos sistemas
específicos:

<itemize>

<item>En un <it/ARM Pentium-90/ o en un <it/Midwest Micro Soundbook Plus/,
use <tt>freq_bypass=1 cmd_time=8</tt>. 

<item>En un <it/Midwest Micro Soundbook Elite/, use <tt>cmd_time=12</tt>.

<item>En un <it/Gateway Liberty/, pruebe con <tt>cmd_time=16</tt>.

<item>En un <it/Samsung SENS 810/, use <tt>fast_pci=1</tt>.

</itemize>

<sect1>Configuración de recursos del sistema 
<label id="confrec">
<p>

Los servicios de tarjetas deben evitar automáticamente el ocupar puertos e
interrupciones que ya estén en uso por otros dispositivos estándar. 
Intentará así mismo detectar conflictos con dispositivos desconocidos,
pero esto no es del todo fiable, y en algunos casos puede que necesite
excluir explícitamente recursos para un dispositivo en
<tt>/etc/pcmcia/config.opts.</tt>

He aquí algunas configuraciones de recursos para tipos específicos de
portátiles. Revíselas con cuidado: pueden darle información necesaria para
resolver problemas, pero algunas están (inevitablemente) obsoletas y
ciertamente contienen errores. Las correcciones y adiciones serán
bienvenidas.

<itemize>

<item>En un <it/AMS SoundPro/, excluya la irq 10.

<item>En algunos modelos <it/AMS TravelPro 5300/, use el rango de memoria
<tt/0xc8000-0xcffff/. 

<item>En un <it/BMX 486DX2-66/, excluya irq 5, irq 9.

<item>En un <it/Chicony NB5/, use el rango de memoria <tt/0xda000-0xdffff/.

<item>En un <it/Compaq Presario 1020/, excluya el puerto <tt/0x2f8-0x2ff/,
irq 3, irq 5. 

<item>En un <it/HP Omnibook 4000C/, excluya el puerto <tt/0x300-0x30f/.

<item>En un <it/IBM ThinkPad 380/, y posiblemente en las series 385 y 600,
excluya el puerto <tt/0x230-0x233/, e irq 5. 

<item>En un <it/IBM ThinkPad 600/, excluya el puerto <tt/0x2f8-0x2ff/.

<item>En un <it/Micron Millenia Transport/, excluya irq 5, irq 9.

<item>En un <it/NEC Versa M/, excluya irq 9, y el puerto <tt/0x2e0-2ff/.

<item>En un <it>NEC Versa P/75</it>, excluya irq 5, irq 9.

<item>En un <it/NEC Versa S/, excluya irq 9, irq 12.

<item>En las series <it/NEC Versa 6000/, excluya el puerto
<tt/0x2f8-0x33f/, irq 9, irq 10

<item>En un <it/ProStar 9200/, <it/Altima Virage/, y <it/Acquiline
Hurricane DX4-100/, excluya irq 5, y el puerto <tt/0x330-0x35f/.  Puede
usar el rango de memoria <tt/0xd8000-0xdffff/. 

<item>En un <it/Siemens Nixdorf SIMATIC PG 720C/, use el rango de memoria
<tt/0xc0000-0xcffff/, y el puerto <tt/0x300-0x3bf/. 

<item>En un <it/TI TravelMate 5000/, use el rango de memoria
<tt/0xd4000-0xdffff/. 

<item>En un <it/Toshiba T4900 CT/, excluya irq 5, y los puertos
<tt/0x2e0-0x2e8/, <tt/0x330-0x338/.

<item>En un <it/Twinhead 5100/, HP 4000, <it/Sharp PC-8700/ and PC-8900,
excluya irq 9 (sonido), irq 12. 

<item>En un <it/MPC 800 Series/, excluya irq 5, y el puerto
<tt/0x300-0x30f/ para el CD-ROM. 

</itemize>

<sect1>Notas acerca de distribuciones de Linux específicas
<label id="distribuciones">
<p>

Esta sección está incompleta. Todas las correcciones y adiciones serán
bienvenidas. 

<sect2>Debian 
<label id="debian">
<p>

Debian usa el conjunto de scripts de arranque de tipo System V. El script
de inicio PCMCIA está instalado en <tt>/etc/init.d/pcmcia</tt>, y las
opciones de inicio se especifican en <tt>/etc/pcmcia.conf</tt>. La
configuración de <tt/syslog/ de Debian colocará los mensajes del kernel en
<tt>/var/log/messages</tt> y los mensajes del demonio <tt/cardmgr/ en
<tt>/var/log/daemon.log</tt>. 

Debian distribuye el sistema PCMCIA en dos paquetes: el paquete
<tt/pcmcia-cs/ que contiene <tt/cardmgr/ y otras herramientas, páginas del
manual, y los scripts de configuración; y el paquete <tt/pcmcia-modules/
que contiene los módulos controladores del kernel. 

<sect2>Red Hat, Caldera, Mandrake 
<label id="rh">
<p>

Estas distribuciones usan la organización de scripts System V. El script
de inicio de PCMCIA está instalado en <tt>/etc/rc.d/init.d/pcmcia</tt>, y
las opciones de arranque se guardan en <tt>/etc/sysconfig/pcmcia</tt>. 
Observe que al instalar el paquete de Red Hat puede instalar un archivo de
opciones de inicio por omisión que tiene PCMCIA desactivado.  Para
habilitar PCMCIA, la variable <tt/PCMCIA/ debe establecerse en <tt/yes/.
La configuración por omisión del <tt/syslogd/ de Red Hat grabará todos los
mensajes interesantes en <tt>/var/log/messages</tt>. 

El paquete PCMCIA de Red Hat contiene un reemplazo para el script de
inicio de red, <tt>/etc/pcmcia/network</tt>, el cual se acopla al panel de
control de red de Red Hat. Esto es conveniente para el caso donde sólo se
usa un adaptador de red, con un conjunto de parámetros de red, pero no
tiene la flexibilidad completa del script regular de red PCMCIA. Compilar
e instalar una distribución fuente de PCMCIA nueva, sobreescribirá el
script de red, rompiendo el enlace con el panel de control. Si prefiere el
script de Red Hat, puede evitarlo bien usando únicamente RPMS de Red Hat,
o creando <tt>/etc/pcmcia/network.opts</tt> que contenga lo siguiente: 

<tscreen><verb>
       if [ -f /etc/sysconfig/network-scripts/ifcfg-eth0 ] ; then
           start_fn () {
               /sbin/ifup $1
           }
           stop_fn () {
               /sbin/ifdown $1
           }
       fi
</verb></tscreen>

Red Hat maneja su distribución de los fuentes de PCMCIA con pocas
modificaciones dentro de su SRPM del kernel, en lugar de gestionarlo como
un paquete separado. 

<sect2>Slackware 
<label id="slack">
<p>

Slackware usa el conjunto de scripts de inicio de BSD. El script de inicio
de PCMCIA está instalado en <tt>/etc/rc.d/rc.pcmcia</tt>, y las opciones
de inicio se especifican en el mismo <tt/rc.pcmcia/. El script de inicio
de PCMCIA se invoca desde <tt>/etc/rc.d/rc.S.</tt>

<sect2>SuSE 
<label id="suse">
<p>

SuSE usa el conjunto de scripts System V, con los scripts de inicio
almacenados en <tt>/sbin/init.d</tt>. El script de inicio de PCMCIA está
instalado en <tt>/sbin/init.d/pcmcia</tt>, y las opciones de arranque se
guardan en <tt>/etc/rc.config</tt>. El script de inicio de SuSE está algo
limitado y no permite que las variables de inicio de PCMCIA sean
invalidados desde el prompt de inicio de <tt>lilo</tt>.

<sect>Resolución de problemas de instalación y configuración 
<label id="problemas">
<p>

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 <ref id="distribuciones"
name="Notas acerca de distribuciones de Linux específicas">). Debe estar
familiarizado con las herramientas básicas de diagnóstico como <tt/dmesg/
y <tt/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 <it/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.

<sect1>No se cargan los módulos básicos de PCMCIA.
<label id="modbase">
<p>

Síntomas:

<itemize>

<item>Aparecen errores acerca de que la versión del kernel difiere cuando
se ejecuta el script de inicio de PCMCIA.

<item>Después de iniciar, <tt/lsmod/ no muestra algún módulo PCMCIA.

<item><tt/cardmgr/ informa <tt>no pcmcia driver in /proc/devices</tt>
en el registro del sistema.

</itemize>

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 <tt/CONFIG_MODVERSIONS/. Si es
falso, entonces el número de versión del kernel se compila dentro de cada
módulo y el programa <tt/insmod/ comprueba esto para compararlo con el
kernel actual. Si <tt/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
<tt/2.0.31/ no cargará con otros kernels <tt/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:

<itemize>

<item>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. 

<item>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 <ref id="compilacion" name="Compilación e instalación"> para
instrucciones más detalladas. 

<item>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 <ref
id="requisitos" name="Requisitos"> acerca de utilidades para módulos y
<tt/binutils/ que se listan en el archivo <tt>Documentation/Changes</tt>
del árbol de directorios de los fuentes del kernel. 

</itemize>

<sect1>Algunos módulos controladores no cargan 
<label id="nocargan">
<p>

Síntomas:

<itemize>

<item>Los módulos base (<tt/pcmcia_core/, <tt/ds/, <tt/i82365/) cargan
correctamente. 

<item>Al insertar una tarjeta, emite un pitido agudo + un pitido grave.

<item><tt/cardmgr/ informa de errores de versiones diferentes en el
registro del sistema. 

</itemize>

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,
<tt/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
<tt/insmod/ no distinguen entre errores por diferencias de versiones y
errores por falta de símbolos. 

Específicamente:

<itemize>

<item>El controlador serie <tt/serial_cs/ requiere que el soporte en el
kernel esté activado con <tt/CONFIG_SERIAL/. Este controlador se debe
compilar como módulo. 

<item>El soporte para tarjetas serie multipuerto o tarjetas multifunción
que incluyen dispositivos serie o módems, requieren que se active
<tt/CONFIG_SERIAL_SHARE_IRQ/. 

<item>Los clientes SCSI requieren que <tt/CONFIG_SCSI/ esté activada,
junto con las opciones apropiadas para los controladores de alto nivel
(<tt>CONFIG_BLK_DEV_SD, CONFIG_BLK_DEV_SR</tt> etc. para kernels <tt/2.1/) 
que pueden ser compilados como módulos. 

<item>Los controladores de red requieren que se habilite <tt/CONFIG_INET/
El soporte para red del kernel no se puede compilar como módulo. 

<item>El cliente token-ring requiere que el kernel se compile con la
opción <tt/CONFIG_TR/ activada.

</itemize>

Hay dos formas de proceder:

<itemize>

<item>Recompile el kernel con las características necesarias activadas.

<item>Si las características han sido compiladas como módulos, entonces
modifique <tt>/etc/pcmcia/config</tt> para precargar esos módulos. 

</itemize>

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

<tscreen><verb>
       device "serial_cs"
         class "serial" module "misc/serial", "serial_cs"
</verb></tscreen>

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 <tt/pcmcia/. 

<sect1>fallos en la búsqueda de interrupciones
<label id="irqscan">
<p>

Síntomas:

<itemize>

<item>El sistema se congela cuando se cargan los controladores PCMCIA,
incluso cuando no hay tarjetas presentes. 

<item>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. 

</itemize>

<!-- David: to probe es «sondear» o «tantear», traducirlo por «probar»   --> 
<!-- es producir un «falso amigo», es decir, traducir algo a un          -->
<!-- término en castellano por su similitud fonética, que no implica     -->
<!-- necesariamente similitud semántica.                                 -->
<!-- En contextos técnicos, la precisión es muy importante.              -->                                    

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 <it/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: 

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

Hay dos formas de proceder:

<itemize>

<item>El sondeo de interrupciones puede estar restringida a una lista de
interrupciones utilizando el parámetro <tt/irq_list/ para los
controladores. Por ejemplo, <tt/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. 

<item>El sondeo de interrupciones puede desactivarse completamente al
cargar el controlador del socket con la opción <tt/do_scan=0/. En este
caso, se usará una interrupción por omisión, la cual evita interrupciones
ya utilizadas por otros dispositivos.

</itemize>

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

<tscreen><verb>
	PCIC_OPTS="irq_list=5,9,10"
</verb></tscreen>

Como podrá notar, <tt>/proc/interrupts</tt> 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
<tt>/proc/interrupts</tt>. Dependiendo del diseño del sistema, un
dispositivo inactivo puede todavía ocupar una interrupción y causar
problemas si es probado por PCMCIA.

<sect1>Fallos en la búsqueda de puertos de E/S
<label id="ioscan">
<p>

Síntomas:

<itemize>

<item>El sistema se congela cuando <tt/cardmgr/ se inicia por primera vez,
incluso cuando no hay tarjetas presentes.

<item>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.

<item>En algunos casos, el tanteo de E/S será positivo, pero avisa de un
gran número de de exclusiones aleatorias. 

</itemize>

Cuando <tt/cardmgr/ procesa los rangos de puertos de E/S listados en
<tt>/etc/pcmcia/config.opts</tt>, 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 <tt/config.opts/. 

Por otra parte, si el sondeo no resulta fiable en su sistema, puede ser
desactivado estableciendo <tt/CORE_OPTS/ a <tt/probe_io=0/. En este caso,
deberá ser muy cuidadoso al especificar solamente rangos de puertos
genuinamente disponibles en <tt/config.opts/, en lugar de usar las
configuraciones por omisión.
  
<sect1>Fallos durante la comprobación de la memoria 
<label id="memscan">
<p>

Síntomas:

<itemize>

<item>Los controladores principales cargan correctamente cuando no hay
tarjetas presentes, sin errores en el registro del sistema.

<item>El sistema se congela y/o reinicia tan pronto como se inserte una
tarjeta antes de que se escuche algún pitido.

</itemize>

O alternativamente:

<itemize>

<item>Todas las inserciones de tarjetas generan un pitido agudo seguido de
un pitido grave.

<item>Todas las tarjetas son identificadas como <it>anonymous memory
cards</it>

<item>El registro del sistema avisa que varios rangos de memoria han
sido excluidos.

</itemize>

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 <tt>/etc/pcmcia/config.opts</tt>. 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: <tt/0xd0000-0xdffff/,
<tt/0xc0000-0xcffff/, <tt/0xc8000-0xcffff/, o <tt/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
<tt/0xd0000/ puede darse como <tt/0xd000/). Asegúrese de añadir el dígito
extra de cuando haga los cambios a <tt/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 <ref id="inicio" name="Opciones de inicio"> para más
información acerca de cómo combatir los problemas comunes de
sincronización. 

<itemize>

<item><tt>cs: warning: no high memory space available!</tt>

</itemize>

Los puentes <it/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 <it/CardBus/ para usar
ventanas de memoria alta, porque es muy difícil que existan conflictos con
otros dispositivos.  También, las tarjetas <it/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 <it/CardBus/, si
ambas ventanas de memoria (alta y baja) se definen en <tt/config.opts/. El
archivo <tt/config.opts/ por omisión ahora incluye una ventana de memoria
alta de <tt/0xa0000000-0xa0ffffff/. Si tiene un puente <it/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 <it/IBM Thinkpad/, una ventana de
<tt/0x60000000-0x60ffffff/ funcionará en lugar de la ventana por omisión.

<sect1>Fallo al detectar cuando se inserta o se extrae la tarjeta
<p>

Síntomas:

<itemize>

<item>Las tarjetas se detectan y configuran apropiadamente si están
presentes al momento de iniciar. 

<item>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. 

</itemize>

En muchos casos, el controlador del socket (<tt/i82365/ o <tt/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.

<!-- David: ¿suena muy raro «monitorizar» allá? sé que allí es usual -->
<!-- «monitorear», pero aquí suena raro...                           -->

Con los controladores <tt/i82365/ y <tt/tcic/ la opción <tt/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 <tt/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, <tt/i82365/ y <tt/tcic/ aceptarán
una opción <tt/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 <tt/PCIC_OPTS=/ ya
sea en <tt>/etc/rc.d/rc.pcmcia</tt> o en <tt>/etc/sysconfig/pcmcia</tt>,
dependiendo de la configuración de su sistema. 

<sect1>Faltan recursos del sistema 
<label id="faltan">
<p>

Síntomas:

<itemize>

<item>Cuando se inserta una tarjeta, es identificada correctamente, pero
no puede ser configurada (secuencia de pitidos agudos/graves).

<item>Aparecen en el registro del sistema alguno de los siguientes
mensajes:

<tscreen><verb>
       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
</verb></tscreen>

</itemize>

La reserva de interrupciones indica generalmente un problema con el sondeo
de interrupciones, véase la sección <ref id="irqscan" name="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 <tt/PCIC_OPTS/ a
<tt/poll_interval=100/. O, si tiene un controlador <it/CardBus/, intente
con <tt/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
<tt>/etc/pcmcia/config.opts</tt> 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 <ref id="ioscan" name="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 <tt/config.opts/. Las
tarjetas <it/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 <it/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
<tt/0xa0000000-0xa0ffffff/. 

<sect1>Conflicto de recursos entre dos tarjetas 
<label id="conflicto">
<p>

Síntomas:

<itemize>

<item>Dos tarjetas funcionan bien cuando se usan separadamente.

<item>Cuando ambas tarjetas se insertan, sólo funciona una.

</itemize>

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 <tt>/etc/pcmcia/config.opts</tt>, y
reinicie el demonio <tt/cardmgr/ para recargar la base de datos de
recursos.

<sect1>No se completa la configuración de dispositivos 
<label id="noconf">
<p>

Síntomas:

<itemize>

<item>Cuando se inserta una tarjeta, se escucha un pitido agudo.

<item>Las inserciones y extracciones posteriores de tarjetas son
ignoradas. 

</itemize>

Esto indica que la tarjeta fue identificada con éxito, sin embargo,
<tt/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 <tt>/etc/pcmcia</tt>. Toman dos parámetros: un nombre de
dispositivo, y una acción. El demonio <tt/cardmgr/ graba los comandos de
configuración en el registro del sistema. Por ejemplo, si el registro del
sistema muestra que el comando <tt>./network start eth0</tt> fue el último
comando ejecutado por <tt/cardmgr/, el siguiente comando puede rastrear el
script: 

<tscreen><verb>
       sh -x /etc/pcmcia/network start eth0
</verb></tscreen>

 
<sect>Uso y características 
<label id="usoycar">
<p>

<sect1>Herramientas para configurar y monitorizar dispositivos PCMCIA
<p>

Si los módulos son todos cargados correctamente, la salida del comando
<tt/lsmod/ debería verse como sigue, cuando no hay tarjetas insertadas:

<tscreen><verb>
  Module                  Size  Used by
  ds                      5640   2
  i82365                 15452   2
  pcmcia_core            30012   3  [ds i82365]
</verb></tscreen>

El registro del sistema deberá también incluir la salida del controlador
del socket, describiendo el(los) controlador(es) del host encontrado(s) y
el número de sockets detectados. 

<sect2>El demonio de configuración <tt>cardmgr</tt> 
<label id="cardmgr">
<p>

El demonio <tt/cardmgr/ es responsable de monitorizar los sockets PCMCIA,
cargando los controladores cuando se necesita, y corriendo scripts a nivel
de usuario en respuesta a las inserciones y extracciones de tarjetas. 
Graba sus acciones en el registro del sistema, y también usa pitidos para
señalar cambios en el estado de las tarjetas.  Los tonos de los pitidos
indican el éxito o fracaso de un paso de la configuración en particular.
Dos pitidos agudos indican que la tarjeta fue identificada y configurada
correctamente. Un pitido agudo seguido de un pitido grave indica que la
tarjeta fue identificada, pero no pudo ser configurada por alguna razón.
Un pitido grave indica que la tarjeta no pudo ser identificada. 

<tt/cardmgr/ registra información del dispositivo para cada socket en <tt>
/var/run/stab</tt>

He aquí el contenido de un ejemplo de <tt>/var/run/stab:</tt>

<tscreen><verb>
       Socket 0: Adaptec APA-1460 SlimSCSI
       0       scsi    aha152x_cs      0       sda     8       0
       0       scsi    aha152x_cs      1       scd0    11      0
       Socket 1: Serial or Modem Card
       1       serial  serial_cs       0       ttyS1   5       65
</verb></tscreen>

Para las líneas que describen dispositivos, el primer campo es el socket,
el segundo es la clase del dispositivo, el tercero es nombre del
controlador, el cuarto se usa para numerar múltiples dispositivos
asociados con el mismo controlador, el quinto es el nombre del
dispositivo, y los dos campos finales son los números mayor y menor para
este dispositivo (si es aplicable). 

El demonio <tt/cardmgr/ configura tarjetas basadas en una base de datos de
tipos de tarjetas conocidas almacenadas en <tt>/etc/pcmcia/config</tt>. 
Este archivo describe una variedad de controladores, describe cómo
identificar esas tarjetas, y cual(es) controlador(es) pertenecen a cada
tarjeta. El formato de este archivo se describe en la página del manual de
<tt/pcmcia(5)/.

<sect2>Las utilidades <tt>cardctl</tt> y <tt>cardinfo</tt>
<label id="cc">
<p>

El comando <tt/cardctl/ puede ser usado para comprobar el estado de un
socket, o para ver cómo está configurado. También puede ser usado para
alterar el estado de configuración de una tarjeta. He aquí un ejemplo de
la salida del comando <tt/cardctl config/:

<tscreen><verb>
  Socket 0:
    not configured
  Socket 1:
    Vcc = 5.0, Vpp1 = 0.0, Vpp2 = 0.0
    Card type is memory and I/O
    IRQ 3 is dynamic shared, level mode, enabled
    Speaker output is enabled
    Function 0:
      Config register base = 0x0800
        Option = 0x63, status = 0x08
      I/O window 1: 0x0280 to 0x02bf, auto sized
      I/O window 2: 0x02f8 to 0x02ff, 8 bit
</verb></tscreen>

O <tt/cardctl ident/, para obtener información de la identificación de la
tarjeta: 

<tscreen><verb>
       Socket 0:
         no product info available
       Socket 1:
         product info: "LINKSYS", "PCMLM336", "A", "0040052D6400"
         manfid: 0x0143, 0xc0ab
         function: 0 (multifunction)
</verb></tscreen>


Los comandos <tt/cardctl suspend/ y <tt/cardctl resume/ pueden usarse para
desactivar una tarjeta sin descargar sus controladores asociados. El
comando <tt/cardctl reset/ intenta resetear y reconfigurar una tarjeta.
<tt/cardctl insert/ y <tt/cardctl eject/ emulan las acciones realizadas
cuando una tarjeta es insertada o expulsada, incluyendo la carga y
descarga de los controladores, y configurando o desactivando los
dispositivos. 

Si está Vd. corriendo X, <tt/cardinfo/ produce de forma gráfica el estado
actual de todos los sockets PCMCIA, similar en contenido a <tt/cardctl
config/. También proporciona una interfaz gráfica para la mayoría de las
otras funciones de <tt/cardctl/. 

<sect2>Inserción y extracción de tarjetas 
<label id="insexp">
<p>

En teoría, puede insertar y extraer tarjetas PCMCIA en cualquier momento. 
Sin embargo, es una buena idea no expulsar una tarjeta que está siendo
utilizada por algún programa de aplicación. Los kernels anteriores al
<tt/1.1.77/ solían congelarse cuando las tarjetas serie/módem eran
expulsadas, aunque esto parece estar ya solucionado.

<sect2>Servicios de Tarjetas y Administración Avanzada de Energía
<label id="aae">
<p>

Los servicios de tarjetas pueden ser compilados con soporte para APM
(<it/Advanced Power Management/) (En castellano: <it/Administración
Avanzada de Energía/), si configuró su kernel con soporte APM. APM está
actualmente a cargo de Stephen Rothwell, <tt><htmlurl
url="mailto:Stephen.Rothwell@canb.auug.org.au" 
name="Stephen.Rothwell@canb.auug.org.au"></tt>. El demonio <tt/apmd/ es
mantenido por Avery Pennarun, <tt><htmlurl
url="mailto:apenwarr@worldvisions.ca" 
name="apenwarr@worldvisions.ca"></tt>), con más información disponible en
<tt><htmlurl url="http://www.worldvisions.ca/~apenwarr/apmd/" 
name="http://www.worldvisions.ca/~apenwarr/apmd/"></tt>. Los módulos
PCMCIA serán configurados automáticamente para APM si es detectada una
versión compatible en el sistema. 

Esté APM configurado o no, puede usar <tt/cardctl suspend/ antes de
suspender su portátil, y <tt/cardctl resume/ después de «despertarlo»,
para apagar y reactivar sus tarjetas PCMCIA. No funcionará con un módem
que esté en uso, porque el controlador serie no puede guardar y
restablecer los parámetros operativos del módem.

APM parece ser inestable en algunos sistemas. Si experimenta problemas con
APM y PCMCIA en su sistema, intente localizar el problema en un paquete u
otro antes de informar de un <it/bug/. 

Algunos controladores, notablemente los controladores PCMCIA SCSI, no
pueden recuperarse de un ciclo de suspender/despertar. Cuando se usa una
tarjeta PCMCIA SCSI, use siempre <tt/cardctl eject/ antes de suspender el
sistema.

<sect2>Apagado del sistema PCMCIA 
<label id="apagar">
<p>

Para descargar el paquete PCMCIA completo, invoque <tt>rc.pcmcia</tt> con:

<tscreen><verb>
	/etc/rc.d/rc.pcmcia stop
</verb></tscreen>

Este script tomará algunos segundos para ejecutarse, para darle tiempo a
todos los controladores a desactivarse correctamente. Si un dispositivo
está en uso actualmente, el proceso de desactivación será incompleto, y
puede que algunos módulos del kernel no sean descargados. Para prevenir
esto, use <tt/cardctl eject/ para desactivar todos los sockets antes de
invocar <tt/rc.pcmcia/. El estado de salida del comando <tt>cardctl</tt>
indicará si alguno de los sockets no pudo ser desactivado.

<sect1>Un vistazo a los scripts de configuración de PCMCIA 
<label id="configuracion">
<p>

Cada dispositivo PCMCIA tiene una «clase» asociada que describe cómo debe
ser configurado y manejado. Las clases están asociadas con los
controladores de dispositivos en <tt>/etc/pcmcia/config</tt>. Actualmente
hay cinco clases de dispositivos de E/S (red, SCSI, cdrom, disco, y serie) 
y dos clases de dispositivos de memoria (memoria y FTL).  Para cada clase,
hay dos scripts en <tt>/etc/pcmcia</tt>: un script principal de
configuración (por ejemplo, <tt>/etc/pcmcia/scsi</tt> para dispositivos
SCSI), y un script de opciones (por ejemplo,
<tt>/etc/pcmcia/scsi.options</tt>). El script principal de un dispositivo
será invocado para configurarlo cuando se inserte una tarjeta, y para
desactivar el dispositivo cuando sea extraída.  Para tarjetas con varios
dispositivos asociados, el script será invocado para cada dispositivo.

Los scripts de configuración inician al extraer algo de información acerca
del dispositivo de <tt>/var/run/stab</tt>. Cada script construye una
«dirección de dispositivo», que únicamente describe el dispositivo que ha
sido solicitado para configurar, en la variable de shell ADDRESS. Esto es
pasado al script <tt>*.opts</tt>, el cual debe proporcionar información
acerca de cómo debe ser configurado un dispositivo en esta dirección. Para
algunos, la dirección del dispositivo es sólo el número de socket. Para
otros, se incluye información extra que puede ser útil para decidir cómo
configurar el dispositivo. Por ejemplo, los dispositivos de red pasan su
dirección ethernet de hardware como parte de la dirección del dispositivo,
así, el script <tt>network.opts</tt> puede usar esto para seleccionar
diversas configuraciones.

La primera parte de todas las direcciones de dispositivos es el «esquema»
PCMCIA actual. Ese parámetro es usado para soportar múltiples conjuntos de
configuraciones de dispositivos basadas en una simple variable externa
definida por el usuario. Una uso de los esquemas puede ser el tener un
esquema de «casa», y un esquema de «trabajo», el cual puede incluir
diferentes conjuntos de parámetros de configuración de red.  El esquema
actual se selecciona usando el comando <tt>cardctl scheme</tt>. Si no se
define un esquema, por omisión se establece el esquema <tt/default/.

Como regla general, cuando se configura Linux para un equipo portátil, los
dispositivos PCMCIA deben ser configurados desde los scripts para
dispositivos PCMCIA. No intente configurar un dispositivo PCMCIA de la
misma forma en que configuraría un dispositivo conectado de forma
permanente. No obstante, algunas distribuciones de Linux suministran
paquetes PCMCIA que están relacionadas con las herramientas de
configuración de dispositivos propios de la misma distribución. En ese
caso, alguna de las siguientes secciones puede o no aplicar; idealmente,
esto sería documentado por los encargados de la distribución.

<sect1>Adaptadores de red PCMCIA 
<label id="net">
<p>

Las interfaces de red tipo ethernet normalmente tienen nombres como
<tt/eth0/, <tt/eth1/, y así sucesivamente. Los adaptadores Token-Ring se
manejan de forma similar, sin embargo, son llamadas comúnmente
<tt>tr0</tt>, <tt>tr1</tt> y así sucesivamente. El comando
<tt>ifconfig</tt> se usa para ver o modificar el estado de una interface
de red. Una peculiaridad de Linux es que las interfaces de red no tienen
archivos de dispositivo correspondientes en <tt>/dev/</tt>, así que no se
sorprenda si no los encuentra. 

Cuando se detecta una tarjeta ethernet, le será asignado el primer nombre
de interface que esté libre, normalmente <tt/eth0/. <tt/cardmgr/ ejecutará
el script <tt>/etc/pcmcia/network</tt> para configurar la interface, la
cual normalmente lee las configuraciones de red de
<tt>/etc/pcmcia/network.opts</tt>. Los scripts <tt>network</tt>, y
<tt>network.opts</tt> serán ejecutados sólo cuando su tarjeta ethernet
esté presente. Si su sistema tiene la facilidad de configuración de red
automática, puede o no ser PCMCIA. Consulte la documentación de su
distribución de Linux y la sección <ref id="distribuciones"  name=" Notas
acerca de distribuciones de Linux específicas"> para determinar si los
dispositivos de red PCMCIA deben ser configurados con herramientas
automáticas, o editando <tt>network.opts</tt>. 

La dirección de dispositivo pasada a <tt>network.opts</tt> consiste en
cuatro campos separados por comas: el esquema, el número de socket, la
instancia de dispositivo, y la dirección ethernet de hardware de la
tarjeta, La instancia de dispositivo es usada para numerar dispositivos
para tarjetas que tienen varias interfaces de red, así que normalmente
será <tt/0/.  Si tiene varias tarjetas de red usadas para propósitos
diferentes, una opción puede ser el configurar las tarjetas basadas en la
posición del socket, como en:

<tscreen><verb>
       case "$ADDRESS" in
       *,0,*,*)
           # definiciones para tarjeta de red en el socket 0
           ;;
       *,1,*,*)
           # definiciones para tarjeta de red en el socket 1
           ;;
       esac
</verb></tscreen>

Alternatívamente, pueden ser configuradas usando su dirección de hardware,
como en:

<tscreen><verb>
  case "$ADDRESS" in
  *,*,*,00:80:C8:76:00:B1)
      # definiciones para una tarjeta D-Link
      ;;
  *,*,*,08:00:5A:44:80:01)
      # definiciones para una tarjeta IBM
  esac
</verb></tscreen>

<sect2>Parámetros de dispositivos de red 
<label id="netpar">
<p>

Los siguientes parámetros se pueden definir en <tt>network.opts</tt>:

<descrip>

<tag/IF_PORT/Especifica el tipo de transceptor ethernet, para tarjetas que
no sean autodetectadas. Consulte <tt>man ifport</tt> para ver los nombres
de los transceptores. 

<tag/PUMP/Una opción booleana (y/n): indica si la dirección IP e
información de rutado del host se puede obtener ya sea por BOOTP o DHCP,
con el demonio <tt/pump/. 

<tag/BOOTP/Una opción booleana (y/n): indica si la dirección IP del host y
su información de rutado se obtendrán usando el protocolo BOOTP, con <tt/
bootpc/. 

<tag/DHCP/Un opción booleana (y/n): indica si la dirección IP del host y
su información de rutado se obtendrán de un servidor DHCP, con
<tt/dhcpcd/.

<tag/IPADDR/La dirección IP para esta interface.

<tag/NETMASK, BROADCAST, NETWORK/Parámetros básicos de red: revise el COMO
de red para más información.

<tag/GATEWAY/La dirección IP de una máquina pasarela para la subred de
este host.  Los paquetes con destinos hacia afuera de esta subred serán
destinados a dicha pasarela. 

<tag/DOMAIN/El nombre de dominio de la red local para este host, es usado
al crear <tt>/etc/resolv.conf</tt>. 

<tag/SEARCH/Una lista de búsqueda para búsqueda de nombres, es añadida a
<tt>/etc/resolv.conf</tt>. DOMAIN y SEARCH son mutuamente exclusivos:
revise <tt/man resolver/ para más información. 

<tag/DNS_1,DNS_2,DNS_3/Nombres de host o direcciones IP para servidores de
nombres para esta interface, para ser añadidos a <tt>/etc/resolv.conf</tt>

<tag/MOUNTS/Una lista de puntos de montaje NFS para ser montados por esta
interface. 

<tag/IPX_FRAME, IPX_NETNUM/Para redes IPX: el tipo de <it/frame/ y número
de red, pasado al comando <tt>ipx_interface</tt>. 

</descrip>

Por ejemplo:

<tscreen><verb>
  case "$ADDRESS" in
  *,*,*,*)
      IF_PORT="10base2"
      BOOTP="n"
      IPADDR="10.0.0.1"
      NETMASK="255.255.255.0"
      NETWORK="10.0.0.0"
      BROADCAST="10.0.0.255"
      GATEWAY="10.0.0.1"
      DOMAIN="dominio.org"
      DNS_1="dns1.dominio.org"
      ;;
  esac
</verb></tscreen>

Para montar y desmontar automáticamente sistemas de archivos NFS, primero
añada todos esos sistemas de archivos a <tt>/etc/fstab</tt>, incluyendo
<tt>noauto</tt> en las opciones de montaje. En <tt>network.opts</tt>,
liste los puntos de montaje de los sistemas de archivos en la variable
MOUNTS. Es especialmente importante usar ya sea <tt>cardctl</tt> o
<tt>cardinfo</tt> para apagar una tarjeta de red cuando NFS se encuentre
activo. No es posible desmontar limpiamente los sistemas de archivos NFS
si una tarjeta de red es símplemente expulsada sin precaución. 

En adición a los parámetros usuales de configuración de red, el script
<tt>network.opts</tt> puede especificar acciones extra a tomar después de
que una interface es configurada, o antes de que se apague la interface. 
Si <tt>network.opts</tt> define una función de shell llamada
<tt>start_fn</tt>, será invocada por el script de red después de que la
interface sea configurada, y el nombre de interface se pasará a la función
como su primer (y único)  argumento. Similarmente, si es definido,
<tt/stop_fn/ se invocará antes de apagar una interfaz. 

El tipo de transceptor se puede seleccionar usando la configuración
<tt>IF_PORT</tt>. Esto puede ser, ya sea un valor numérico como en las
versiones anteriores de PCMCIA, o una palabra clave que identifique el
tipo de transceptor. Todos los controladores de red están configurados por
omisión para autodetectar la interface si es posible, o bien, utilizar
10baseT. El comando <tt/ifport/ se puede utilizar para comprobar el tipo
de transceptor actual. Por ejemplo: 

<tscreen><verb>
       # ifport eth0 10base2
       #
       # ifport eth0
       eth0    2 (10base2)
</verb></tscreen>

El controlador actual (<tt/3.0.10/ o posterior) de <tt/3c589/ debe
autodetectar rápidamente los cambios de transceptor en cualquier momento. 
Las primeras versiones del controlador 3x589 tenían un algoritmo de
autodetección de transceptores algo lento y no muy amistoso. Para esas
versiones, el cable de red apropiado debe ser conectado a la tarjeta
cuando la tarjeta es configurada, o se puede forzar la autodetección con:

<tscreen><verb>
       ifconfig eth0 down up
</verb></tscreen>

<sect2>Comentarios acerca de tarjetas específicas 
<label id="netcom">
<p>

<itemize>

<item>Con las tarjetas <it/IBM CCAE/ y <it/Socket EA/, el tipo de
transceptor (10base2, 10baseT, AUI), necesita configurarse cuando el
dispositivo de red está configurado. Asegúrese de que el tipo de
transceptor que aparece en el registro del sistema concuerda con su
conexión.

<item>Los controladores para tarjetas SMC, Megahertz, Ositech, y 3Com
deben autodetectar el tipo de red conectada (10base2 o 10baseT). 
Establecer el tipo de transceptor cuando se carga el controlador sirve
para definir la «primera búsqueda» de la tarjeta. 

<item>La <it/Farallon EtherWave/ actualmente está basada en la <it/3Com
3c589/, con un transceptor especial. Aunque la EtherWave usa conexiones al
estilo 10baseT, su transceptor requiere que la 3c589 sea configurada en
modo 10base2.

<item>Si tiene problemas con un adaptador <it/IBM CCAE/, <it/NE4100/,
<it/Thomas Conrad/, o Kingston, pruebe a incrementar el tiempo de acceso
con la opción <tt/mem_speed=&num;/ al módulo <tt/pcnet_cs/. Un ejemplo de
cómo hacer esto se muestra en el archivo <tt/config.opts/. Pruebe con
velocidades por encima de <tt/1000/ (en nanosegundos).

<item>Para el adaptador <it/New Media Ethernet/, en algunos sistemas,
puede ser necesario incrementar el tiempo de acceso al puerto de E/S con
la opción <tt/io_speed=&num;/ cuando se cargue el módulo <tt/pcmcia_core/.
Edite <tt/CORE_OPTS/ en el script de inicio para activar esta opción.

<item>El soporte multicast en el controlador <it/New Media Ethernet/ está
incompleto. El último controlador funcionará con kernels multicast, pero
ignorará los paquetes multicast. El modo promiscuo debe funcionar
apropiadamente. 

<item>El controlador usado por los controladores token ring IBM y 3Com
parecen comportarse bastante mal si las tarjetas no están conectadas
cuando son inicializadas. Conecte siempre esas tarjetas a la red antes de
activarlas. Si <tt/ifconfig/ informa que la dirección de harware como todo
<tt/0/, esto debe ser debido a un problema de configuración de la ventana
de memoria. 

<item>Algunas tarjetas Linksys, D-Link, e IC-Card 10baseT/10base2 tienen
una forma única de seleccionar el tipo de transceptor que no es manejado
por los controladores de Linux. Una solución es arrancar DOS y utilizar la
utilidad proporcionada por el fabricante para seleccionar el transceptor,
haciendo entonces un arranque «en caliente» de Linux. Alternativamente,
hay una utilidad Linux para realizar esta función, que está disponible en
<tt> <htmlurl url="ftp://hyper.stanford.edu/pub/pcmcia/extras/dlport.c" 
name="ftp://hyper.stanford.edu/pub/pcmcia/extras/dlport.c"></tt>.

<item>Para adaptadores de red inalámbricos WaveLAN, Jean Tourrilhes,
<tt><htmlurl url="mailto:jt@hpl.hp.com" name="jt@hpl.hp.com"></tt>)  tiene
disponible el <it/Wireless HOWTO/ (Cómo inalámbrico) en <tt><htmlurl
url="http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/"
name="http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/"></tt>

</itemize>

<sect2>Diagnóstico de problemas con adaptadores de red 
<label id="diagnet">
<p>

<itemize>

<item>¿Es reconocida su tarjeta como una tarjeta ethernet? Revise el
registro del sistema y asegúrese de que <tt/cardmgr/ identifique la
tarjeta correctamente e inicia uno de los controladores de red. Si no lo
hace, su tarjeta puede ser utilizable todavía si es compatible con una
tarjeta soportada. Esto es posible hacerlo fácilmente si la tarjeta dice
ser <it/NE2000 compatible/. 

<item>¿Está configurada la tarjeta apropiadamente? Si está usando una
tarjeta soportada, y fue reconocida por <tt/cardmgr/, pero todavía no
funciona, pudo ser un conflicto de interrupción o puerto con otro
dispositivo. Determine qué recursos está utilizando la tarjeta (en el
registro del sistema), e intente de nuevo excluyéndolos en
<tt>/etc/pcmcia/config.opts</tt> para forzar a la tarjeta a usar otros. 

<item>Si su tarjeta parece estar configurada adecuadamente, pero a veces
se congela, particularmente bajo carga alta, puede ser que necesite
intentar cambiar los parámetros de sincronización de su controlador del
socket. Revise la sección <ref id="inicio" name="Opciones de Inicio"> para
más información.

<item>Si obtiene mensajes de <tt>network unreachable</tt> cuando intenta
acceder a la red, la información especificada en
<tt>/etc/pcmcia/network.opts</tt> es incorrecta. Este mensaje es una
indicación absolutamente a prueba de tontos de que hay un error de rutado.
Por otra parte, las tarjetas mal configuradas normalmente fallarán
silenciosamente. 

<item>Para diagnosticar problemas en <tt>/etc/pcmcia/network.opts</tt>,
empiece tratando de hacer <tt/ping/ a otros sistemas en la misma subred
usando sus direcciones IP. Trate entonces de hacer <tt/ping/ a su puerta
de enlace o «pasarela» (<it/gateway/), y a máquinas en otras subredes.
Debe ser posible hacer <tt/ping/ a las máquinas por su nombre si lleva a
cabo dichas pruebas con éxito. 

<item>Asegúrese que su problema sea PCMCIA. Puede ser muy útil comprobar
si la tarjeta funciona correctamente bajo DOS con los controladores del
fabricante.  Verifique bien sus modificaciones al script
<tt>/etc/pcmcia/network.opts</tt>. Asegúrese que su cable, conector «T»,
terminador, etc. estén funcionando. 

</itemize>

<sect1>Dispositivos serie PCMCIA y módems 
<label id="serie">
<p>

Los dispositivos serie de Linux son gestionados por medio de los archivos
de dispositivo especiales <tt>/dev/ttyS*</tt> y <tt>/dev/cua*</tt>. En los
kernels <tt/pre-2.2/ los dispositivos <tt>ttyS*</tt> eran para conexiones
entrantes, como módems. El uso de dispositivos <tt>cua*</tt> se desaprueba
en los kernels actuales, y se puede usar <tt>ttyS*</tt> para todas las
aplicaciones. La configuración de un dispositivo serie se puede examinar y
modificar con el comando <tt/setserial/.

Cuando se detecta una tarjeta serie o módem, se le asignará el primer slot
de dispositivo serie que se encuentre disponible. Este será usualmente
<tt>/dev/ttyS1 (cua1)</tt> o <tt>/dev/ttyS2 (cua2)</tt>, dependiendo del
número de puertos serie que tenga. El dispositivo <tt/ttyS*/ es el que
aparecerá en <tt>/var/run/stab</tt>. El script de opciones por omisión
para dispositivos serie, <tt>/etc/pcmcia/serial.opts</tt>, enlazará el
dispositivo a <tt>/dev/modem</tt> por conveniencia. Para los kernels
<tt/pre-2.2/, el enlace se hace al dispositivo <tt/cua*/.

No intente usar <tt>/etc/rc.d/rc.serial</tt> para configurar un módem
PCMCIA. Este script sólo debería ser utilizado para configurar
dispositivos no extraíbles. Modifique <tt>/etc/pcmcia/serial.opts</tt> si
quiere hacer algo especial para configurar su módem. No intente tampoco
cambiar las configuraciones de E/S y puerto de un dispositivo serie
utilizando <tt/setserial/. Esto podría decir al controlador serie que
busque al dispositivo en un lugar diferente, pero no cambiar cómo el
hardware de la tarjeta está configurado actualmente. El script de
configuración serie le permite especificar otras opciones para
<tt/setserial/, así como si se debe añadir una línea a
<tt>/etc/inittab</tt> para este puerto. 

La dirección del dispositivo pasada a <tt/serial.opts/ tiene tres campos
separados por comas: el primero es el esquema, el segundo es el número de
socket, y el tercero es la instancia del dispositivo. La instancia del
dispositivo puede tomar varios valores para tarjetas que soporten
múltiples puertos serie, pero para tarjetas de un sólo puerto, siempre
será <tt/0/. Si comunmente usa más de un módem, puede especificar
diferentes configuraciones basadas en la posición del socket, como en:

<tscreen><verb>
       case "$ADDRESS" in
       *,0,*)
           # Opciones para un modem en el socket 0
           LINK=/dev/modem0
           ;;
       *,1,*)
           # Opciones para un modem en el socket 1
           LINK=/dev/modem1
           ;;
       esac
</verb></tscreen>

Si un módem PCMCIA ya está configurado cuando Linux arranca, puede ser
identificado incorrectamente como un puerto serie ordinario. Esto es
inofensivo, sin embargo, cuando los controladores PCMCIA toman el control
del módem, se le asignará un slot de dispositivo diferente.  Por ello es
mejor, ya sea analizar <tt> /var/run/stab</tt> o usar <tt>/dev/modem</tt>,
en lugar de indicar que este módulo debe recargarse. Edite la entrada del
dispositivo serie, de modo que se lea:

<tscreen><verb>
       device "serial_cs"
         class "serial" module "misc/serial", "serial_cs"
</verb></tscreen>

<sect2>Parámetros de dispositivos serie 
<label id="seriepar">
<p>

Los siguientes parámetros se pueden definir en <tt/serial.opts/:

<descrip>

<tag/LINK/Especifica una ruta para un enlace simbólico a crear al
dispositivo <it>callout</it> (para llamar hacia el exterior) (ejemplo,
<tt>/dev/cua*</tt> para kernels pre-2.2 o <tt>/dev/ttyS*</tt> para kernels
<tt/2.2.x/). 

<tag/SERIAL_OPTS/Especifica las opciones que se pasan al comando
<tt/setserial/. 

<tag/INITTAB/Si se especifica, se usará para añadir una entrada
<tt/inittab/ para el dispositivo.

</descrip>

Por ejemplo:

<tscreen><verb>
       case "$ADDRESS" in
       *,*,*,*)
           LINK="/dev/modem"
           SERIAL_OPTS=""
           INITTAB="/sbin/getty"
</verb></tscreen>

<sect2>Diagnóstico de problemas con dispositivos serie 
<label id="seriediag">
<p>

<itemize>

<item>¿Se reconoce su tarjeta como un módem? Revise el registro del
sistema y asegúrese que <tt/cardmgr/ identifica la tarjeta correctamente e
inicia el controlador <tt/serial_cs/. Si no, necesitará añadir una nueva
entrada en el fichero <tt>/etc/pcmcia/config</tt> para que pueda ser
identificado apropiadamente. Consulte la sección <ref id="configurando" 
name="Configuración de tarjetas no reconocidas"> para más detalles. 

<item>¿Es el módem configurado satisfactoriamente por <tt/serial_cs/? 
Nuevamente, revise el registro del sistema y busque los mensajes del
controlador <tt/serial_cs/. Si ve mensajes como <tt/register_serial() 
failed/ debe tener un conflicto de puerto de E/S con otro dispositivo.
Otra causa de conflictos tiene lugar cuando el dispositivo es reconocido
como una <it/UART 8250/;  la mayoría de módems modernos deben
identificarse como UART 16550A. Si piensa que está viendo un conflicto de
puertos, edite <tt>/etc/pcmcia/config.opts</tt> y excluya el rango de
puertos que fue reservado para el módem. 

<item>¿Hay un conflicto de interrupciones? Si el registro del sistema se
parece normal, pero el módem no funciona, pruebe a cambiar la irq a <tt/0/
usando <tt/setserial/ y comprobar si el módem funciona. Esto causa que el
controlador serie use un modo de búsqueda más bajo en lugar de usar
interrupciones. Si esto parece solucionar el problema, es probable que
otro dispositivo del sistema esté usando la interrupción seleccionada por
<tt/serial_cs/. Deberá añadir una línea a <tt>/etc/pcmcia/config.opts</tt>
para excluir esta interrupción. 

<item>Si el módem parece funcionar muy, muy lento, esto es casi un
indicador seguro de un conflicto de interrupciones. Asegúrese que su
problema sea realmente PCMCIA. Puede ayudarle comprobar si la tarjeta
funciona bajo DOS con los controladores del fabricante. Así mismo, evite
probar la tarjeta con algo complicado como SLIP o PPP hasta que esté
seguro que haga conexiones simples. Si es capaz de establecer «conexiones
simples», pero no con SLIP, su problema es más probable que tenga que ver
con SLIP, y no con PCMCIA.

<item>Si obtiene mensajes del kernel indicando que el módulo
<tt/serial_cs/ no puede cargarse, significa que su kernel no tiene soporte
para dispositivo serie. Si ha compilado el controlador serie como módulo,
debe modificar <tt>/etc/pcmcia/config</tt> para indicar que el módulo
serie debe cargarse antes de <tt/serial_cs/. 

</itemize>

<sect1>Dispositivos PCMCIA de puerto paralelo 
<label id="parport">
<p>

El controlador de puerto paralelo de Linux está estructurado por capas,
así que varios tipos de dispositivos de alto nivel pueden compartir el
mismo controlador de puerto de bajo nivel. Los dispositivos se gestionan a
través de los archivos especiales de dispositivo <tt>/dev/lp*</tt>. La
configuración de un dispositivo de impresora puede examinarse y
modificarse con el comando <tt/tunelp/.

El módulo <tt/parport_cs/ depende de los controladores <tt/parport/ y
<tt/parport_pc/, los cuales pueden ser compilados dentro del kernel o bien
compilados como módulos. La estructura del controlador por capas significa
que cualquiera de los controladores paralelos de alto nivel (tales como el
controlador <tt/plip/, el controlador de impresora, etc.) deben ser
compilados como módulos. Estos controladores sólo reconocen dispositivos
de puerto paralelo en el momento de iniciar el módulo, así que pueden
cargarse después de que cualquier dispositivo paralelo PC Card sea
configurado.

La dirección del dispositivo pasada a <tt/parport.opts/ tiene tres campos
separados por comas: el primero es el esquema, el segundo es el número de
socket, y el tercero es la instancia del dispositivo. La instancia del
dispositivo puede tomar varios valores para tarjetas que soportan
múltiples puertos paralelos, pero para tarjetas de un solo puerto, siempre
será <tt/0/. Si usa habitualmente más de una tarjeta, necesitará
especificar diferentes configuraciones basadas en la posición del socket,
como en: 

<tscreen><verb>
       case "$ADDRESS" in
       *,0,*)
           # Opciones para una tarjeta en el socket 0
           LINK=/dev/printer0
           ;;
       *,1,*)
           # Opciones para una tarjeta en el socket 1
           LINK=/dev/printer1
           ;;
       esac
</verb></tscreen>

Si configura el kernel para cargar el controlador básico de puerto
paralelo como módulo, debe editar <tt>/etc/pcmcia/config</tt> para indicar
qué módulos necesitan cargarse. Edite la entrada para el dispositivo
paralelo de modo que se lea: 

<tscreen><verb>
       device "parport_cs"
         class "parport" module "misc/parport", "misc/parport_pc", "parport_cs"
</verb></tscreen>

<sect2>Parámetros de dispositivos paralelos 
<label id="parportpar">
<p>

Los siguientes parámetros pueden especificarse en <tt/parport.opts/:

<descrip>

<tag/LINK/Especifica la ruta del enlace simbólico a crear hacia el puerto
de impresora. 

<tag/LP_OPTS/Especifica las opciones a pasar al comando <tt/tunelp/.

</descrip>

Por ejemplo:

<tscreen><verb>
       case "$ADDRESS" in
       *,*,*,*)
           LINK="/dev/printer"
           LP_OPTS=""
</verb></tscreen>

<sect2>Diagnóstico de problemas con dispositivos de puertos paralelos  
<label id="parportdiag">
<p>

<itemize>

<item>¿Hay un conflicto de interrupciones? Si el registro del sistema
parece estar bien, pero el puerto no funciona, cambie la irq a <tt/0/
usando <tt/tunelp/, y compruebe si las cosas mejoran.  Esto cambia el
controlador a modo de búsqueda. Si parece solucionar el problema, es
probable que otro dispositivo en su sistema esté utilizando la
interrupción seleccionada por <tt/parport_cs/. Deberá añadir una línea a
<tt>/etc/pcmcia/config.opts</tt> para excluir esta interrupción. 

<item>Si su kernel genera mensajes indicando que el módulo <tt/parport_cs/
no puede cargarse, significa que el kernel no tiene soporte para
dispositivos paralelos. Si tiene compilado el controlador paralelo como
módulo, necesita modificar <tt>/etc/pcmcia/config</tt> para indicar que
los módulos <tt/parport/ y <tt/parport_pc/ deben cargarse antes que
<tt/parport_cs/.

</itemize>

<sect1>Adaptadores SCSI PCMCIA 
<label id="scsi">
<p>

Todos los controladores que dan soporte actualmente a tarjetas SCSI PCMCIA
son trabajos basados en alguna de las siguientes tarjetas bus ISA:
<it/Qlogic/, <it/Adaptec AHA-152X/, o <it/Future Domain TMC-16x0/. Los
controladores PCMCIA son compilados enlazando parcialmente código
específico PCMCIA (en <tt/qlogic_cs.c/, <tt/toaster_cs.c/, o
<tt/fdomain_cs.c/) con el controlador SCSI normal de Linux. Debido a las
limitaciones en el modelo del controlador SCSI de Linux, sólo se soporta
una tarjeta extraíble por controlador.

Cuando se detecta un nuevo adaptador SCSI, los controladores SCSI
sondearán la presencia de dispositivos. Revise el registro del sistema
para asegurar que los dispositivos sean detectado apropiadamente. Los
nuevos dispositivos SCSI se asignarán a los primeros archivos de
dispositivo SCSI disponibles. El primer disco SCSI será <tt>/dev/sda</tt>,
la primera cinta SCSI será <tt>/dev/st0</tt>, y el primer CD-ROM será
<tt>/dev/scd0</tt>. 

En <tt>/var/run/stab</tt> se muestra una lista de los dispositivos
conectados a este adaptador, y el script de configuración
<tt>/etc/pcmcia/scsi</tt> se llamará una vez para cada dispositivo
conectado, ya sea para configurar o apagar ese dispositivo. El script por
omisión no toma ninguna acción para configurar dispositivos SCSI, pero
desmontará apropiadamente los sistemas de archivos en dispositivos SCSI
cuando se extraiga la tarjeta. 

Las direcciones de dispositivo que se pasan a <tt/scsi.opts/ son
complicadas, debido a la variedad de cosas que pueden conectarse a un
adaptador SCSI. Las direcciones consisten de de seis o siete campos
separados por comas: el esquema actual, el tipo de dispositivo, el número
de socket, el canal SCSI, ID, y el número lógico de unidad, y
opcionalmente, el número de partición. El tipo de dispositivo será <tt/sd/
para discos, <tt/st/ para cintas, <tt/sr/ para unidades de CD-ROM, y
<tt/sg/ para dispositivos SCSI genéricos. Para la mayoría de
configuraciones, la unidad lógica y el canal SCSI serán <tt/0/. Para
unidades de disco con varias particiones, <tt/scsi.opts/ se llamará
primero para toda la unidad, con direcciones de cinco campos. El script
deberá establecer la variable PARTS una lista de particiones.  Entonces,
<tt/scsi.opts/ será llamado para cada partición, con las direcciones más
largas, de siete campos. 

Si su kernel no tiene un controlador de alto nivel (disco, cinta, etc) 
para un dispositivo SCSI en particular, entonces no será configurado por
los controladores PCMCIA. Como efecto lateral, el nombre del dispositivo
en <tt>/var/run/stab</tt> será algo como <tt/sd&num;nnnn/ donde <tt/nnnn/
es un número hexadecimal de cuatro dígitos. Esto pasa cuando <tt/cardmgr/
no puede traducir una ID de un dispositivo SCSI a su nombre de dispositivo
correspondiente en Linux.

Es posible modularizar los controladores SCSI de alto nivel para que
puedan cargarse según demanda. Para hacerlo, necesita editar
<tt>/etc/pcmcia/config</tt> para decirle a <tt/cardmgr/ qué módulos extra
necesitan ser cargados cuando sea configurado su adaptador. Por ejemplo:

<tscreen><verb>
       device "aha152x_cs"
         class "scsi" module "scsi/scsi_mod", "scsi/sd_mod", "aha152x_cs"
</verb></tscreen>

Especificaría que se cargase el módulo principal SCSI y el módulo
controlador de disco antes de cargar el módulo controlador PCMCIA normal.
El script <tt/Configure/ de PCMCIA no detectará automáticamente módulos
SCSI modularizados, así que necesitará usar la opción de configuración
manual para habilitar el soporte SCSI. 

Encienda siempre los dispositivos SCSI antes de encender su portátil, o
antes de insertar la tarjeta adaptadora, para que el bus SCSI esté listo
cuando el adaptador se configure. También hay que ser muy cuidadoso al
expulsar un adaptador SCSI. Asegúrese que todos los dispositivos SCSI
asociados sean desmontados y cerrados antes de expulsar la tarjeta. La
mejor forma de asegurar esto es usar <tt/cardctl/ o <tt/cardinfo/ para
solicitar que se desactive la tarjeta antes de expulsarla físicamente. Por
ahora, todos los dispositivos SCSI deberán encenderse antes de conectar un
adaptador SCSI, y deberán permanecer conectados hasta que desconecte el
adaptador y/o apague su portátil. 

Hay una complicación potencial cuando se usan tarjetas que no se presentan
con adaptadores de bus ISA ordinarios. El bus SCSI transporta una señal
<it/termination power/ (corriente de terminación) que se necesita para que
los terminadores pasivos SCSI ordinarios funcionen apropiadamente. Los
adaptadores PCMCIA SCSI no suministran corriente de terminación, así que
si se requiere, deberá proporcionarlo el dispositivo externo. Algunos
dispositivos externos SCSI deben configurarse para suministrarlo. Otros,
como el <it/Iomega Zip/ y el <it/Syquest EZ/, usan terminadores activos
que no dependen de ello. En algunos casos, puede ser necesario usar un
bloque terminador especial como el <it/APS SCSI Sentry 2/, el cual tiene
una fuente de alimentación externa. Cuando configure la entrada para el
dispositivo SCSI, hágalo teniendo en cuenta si alguno de sus dispositivos
requieren o pueden suministrar corriente de terminación o no.

<sect2>Parámetros de dispositivos SCSI 
<label id="scsipar">
<p>

Los siguientes parámetros pueden ser especificados en <tt/scsi.opts/:

<descrip>

<tag/DO_FSTAB/Es una opción booleana (y/n): Especifica si se debe añadir
una entrada <tt>/etc/fstab</tt> para este dispositivo. 

<tag/DO_FSCK/Es una opción booleana (y/n): Especifica si se debe comprobar
este dispositivo antes de ser montado, con <tt>fsck -Ta</tt>.

<tag/DO_MOUNT/Es una opción booleana (y/n): Especifica si este dispositivo
debe montarse automáticamente al momento de insertar la tarjeta. 

<tag/FSTYPE, OPTS, MOUNTPT/El tipo de sistema de archivos, opciones de
montaje, y punto de montaje que se utilizarán para la entrada en
<tt/fstab/ y/o para montar el dispositivo. 

</descrip>

Por ejemplo, un script para configurar una unidad de disco en SCSI ID 3,
con dos particiones, y un CD-ROM en SCSI ID 6:

<tscreen><verb>
  case "$ADDRESS" in
  *,sd,*,0,3,0)
      # Este dispositivo tiene dos particiones...
      PARTS="1 2"
      ;;
  *,sd,*,0,3,0,1)
      # Opciones para la particion 1:
      #  actualizar /etc/fstab, y montar un sistema de archivos ext2 en /usr1
      DO_FSTAB="y" ; DO_FSCK="y" ; DO_MOUNT="y"
      FSTYPE="ext2"
      OPTS=""
      MOUNTPT="/usr1"
      ;;
  *,sd,*,0,3,0,2)
      # Opciones para la partición 2:
      #  actualizar /etc/fstab, y montar un sistema de archivos MS-DOS en /usr2
      DO_FSTAB="y" ; DO_FSCK="y" ; DO_MOUNT="y"
      FSTYPE="msdos"
      OPTS=""
      MOUNTPT="/usr2"
      ;;
  *,sr,*,0,6,0)
      # Opciones para un CD-ROM en SCSI ID 6
      PARTS=""
      DO_FSTAB="y" ; DO_FSCK="n" ; DO_MOUNT="y"
      FSTYPE="iso9660"
      OPTS="ro"
      MOUNTPT="/cdrom"
      ;;
  esac
</verb></tscreen>


<sect2>Comentarios acerca de tarjetas específicas 
<label id="scsicom">
<p>

<itemize>

<item>La tarjeta <it/Adaptec APA-1480 CardBus/ necesita una ventana de
puerto de E/S grande (256 puertos contiguos alineados en un límite de 256
puertos). Puede que sea necesario incluir las regiones de los puertos de
E/S en <tt>/etc/pcmcia/config.opts</tt> para garantizar que cada ventana
pueda encontrarse.

<item>No está soportado el adaptador <it/Adaptec APA-460 SlimSCSI/. Esta
tarjeta se vendió originalmente bajo el nombre de Trantor, y cuando
Adaptec se unió a Trantor, continuaron vendiendo la tarjeta Trantor con
etiqueta Adaptec. La <it/APA-460/ no es compatible con ningún controlador
de Linux existente.

<item>He sido informado de la mala interacción entre la tarjeta <it/New
Media Bus Toaster/ y un scanner <it/UMAX Astra 1200s/. Debido a la
complejidad del protocolo SCSI, cuando se diagnostican problemas con
dispositivos SCSI, es digno de considerar que combinaciones incompatibles
como esta pueden existir y no pueden documentarse. 

</itemize>


<sect2>Diagnóstico de problemas con adaptadores SCSI 
<label id="scsidiag">
<p>

<itemize>

<item>Con el controlador <tt/aha152x_cs/ (usado por Adaptec, New Media, y
algunos más), parece que el soporte SCSI de conexión/reconexión constituye
una fuente de problemas frecuentes con dispositivos de cinta. Para
desactivar esta «característica», añada lo siguiente a
<tt>/etc/pcmcia/config.opts</tt>: 

<tscreen><verb>
  module "aha152x_cs" opts "reconnect=0"
</verb></tscreen>

<item>Con el controlador <tt/aha152x_cs/, ciertos dispositivos parecen
requerir un tiempo de espera de inicio más grande, controlado con el
parámetro <tt/reset_delay/ del módulo. La unidad CDR <it/Yamaha 4416S/ es
uno de esos dispositivos. El resultado es que el dispositivo es
identificado sin problemas, y luego se congela el sistema. En esos casos,
pruebe:

<tscreen><verb>
       module "aha152x_cs" opts "reset_delay=500"
</verb></tscreen>

<item>Otra fuente potencial de problemas en el sondeo de dispositivos SCSI
es el tanteo de LUNs múltiples. Si ve que la detección de un dispositivo
es realizada sin problemas, seguida de «timeouts» del bus SCSI cuando se
sondea el LUN 1 para ese dispositivo, debe desactivar la opción
<tt/CONFIG_SCSI_MULTI_LUN/ del kernel. 

<item>Si tiene compilado el soporte SCSI modularmente (<tt/CONFIG_SCSI/ es
<tt/m/), debe modificar <tt>/etc/pcmcia/config</tt> para cargar los
módulos SCSI antes de que se cargue el controlador <tt/*_cs/ apropiado. 

<item>Si obtiene mensajes de tipo <tt/aborting command due to timeout/
(abortando el comando debido a timeout), cuando se sondea el bus SCSI, es
muy probable que tenga un conflicto de interrupciones.

<item>Si el controlador del host avisa <tt/no SCSI devices found/ (no se
han encontrado dispositivos SCSI), verifique que el kernel fue compilado
con los controladores SCSI de alto nivel apropiados para sus dispositivos
(por ejemplo, disco, cinta, CD-ROM, y/o genéricos). Si falta un
controlador de alto nivel, los dispositivos de ese tipo se ignorarán. 

</itemize>


<sect1>Tarjetas de memoria PCMCIA 
<label id="mem">
<p>

El controlador <tt/memory_cs/ maneja todos los tipos de tarjetas de
memoria, y también proporciona acceso directo al espacio de la dirección
de memoria PCMCIA para tarjetas que tienen otras funciones. Cuando se
carga, crea una combinación de dispositivos de caracteres y de bloques.
Revise la página del manual del módulo para ver una descripción completa
del esquema de nombres de estos dispositivos. Los dispositivos de bloques
se usan para tener acceso a disco (creando y montando sistemas de
archivos, etc.).  Los dispositivos de caracteres son para lecturas en
bruto (que no se procesan) que no se guardan en el buffer y son escritas
en posiciones arbitrarias. 

La dirección de dispositivo que se pasa a <tt/memory.opts/ consiste de dos
campos: el esquema, y el número de socket. Las opciones se aplican a la
primera partición de memoria común en la tarjeta correspondiente.

Algunas tarjetas de memoria antiguas, y la mayoría de las tarjetas de RAM
simple estática, carecen de <it/Card Information Structure, CIS/
(Estructura de Información de Tarjeta), que es el esquema que las tarjetas
PCMCIA usan para identificarse a si mismas. Normalmente, <tt/cardmgr/
asumirá que una tarjeta que carece de CIS es una tarjeta de memoria
simple, y cargará el controlador <tt/memory_cs/. Por tanto, un efecto
lateral es que otros tipos de tarjetas pueden detectarse erróneamente como
tarjetas de memoria. 

El controlador <tt/memory_cs/ usa un algoritmo heurístico para determinar
la capacidad de esas tarjetas. Este algoritmo no funciona con tarjetas
protegidas contra escritura, y puede cometer errores en algunos otros
casos. Si una tarjeta se configura de forma errónea, su tamaño puede
especificarse explícitamente cuando se haga uso de los comandos <tt/dd/ o
<tt/mkfs/. 

<sect2>Parámetros de dispositivos de memoria 
<label id="mempar">
<p>

<descrip>

<tag/DO_FSTAB/Es una opción booleana (y/n): Especifica si se debe añadir
una entrada <tt>/etc/fstab</tt> para este dispositivo. 

<tag/DO_FSCK/Es una opción booleana (y/n): Especifica si se debe comprobar
este dispositivo antes de ser montado, con <tt>fsck -Ta</tt>.

<tag/DO_MOUNT/Es una opción booleana (y/n): Especifica si este dispositivo
debe montarse automáticamente en el momento de insertar la tarjeta. 

<tag/FSTYPE, OPTS, MOUNTPT/El tipo de sistema de archivos, opciones de
montaje, y punto de montaje que se utilizarán para la entrada en
<tt/fstab/ y/o para montar el dispositivo.

</descrip>

He aquí un ejemplo de un script que montará automáticamente las tarjetas
de memoria basándose en el socket en que estén insertadas:

<tscreen><verb>
       case "$ADDRESS" in
       *,0,0)
           # Montar sistema de archivos, pero no actualizar /etc/fstab
           DO_FSTAB="n" ; DO_FSCK="y" ; DO_MOUNT="y"
           FSTYPE="ext2" ; OPTS=""
           MOUNTPT="/mem0"
           ;;
       *,1,0)
           # Montar sistema de archivos, pero no actualizar /etc/fstab
           DO_FSTAB="n" ; DO_FSCK="y" ; DO_MOUNT="y"
           FSTYPE="ext2" ; OPTS=""
           MOUNTPT="/mem1"
           ;;
       esac
</verb></tscreen>


<sect2>Uso de tarjetas de memoria flash 
<label id="flash">
<p>

La dirección de dispositivo que se pasa a <tt/ftl.opts/ consiste en tres o
cuatro campos: el esquema, el número de socket, el número de región, y
opcionalmente, el número de partición. La mayoría de tarjetas flash tienen
sólo una región de memoria flash, así que el número de región será
generalmente cero siempre. 

Para usar una tarjeta de memoria flash como un dispositivo de bloques del
tipo de un disco ordinario, primero se crea una partición FTL, o <it/flash
translation layer/, en el dispositivo por medio del comando
<tt/ftl_format/. Esta capa oculta los detalles específicos de dispositivo
de la programación de la memoria flash y hace que la tarjeta se vea como
un simple dispositivo de bloques. Por ejemplo:

<tscreen><verb>
       ftl_format -i /dev/mem0c0c
</verb></tscreen>

Nótese que este comando accede a la tarjeta por medio de la interface
<it/raw/ de la tarjeta de memoria. Una vez formateada, la tarjeta puede
tratarse como un dispositivo de bloques ordinario por medio del
controlador <tt/ftl_cs/. Por ejemplo:

<tscreen><verb>
       mke2fs /dev/ftl0c0
       mount -t ext2 /dev/ftl0c0 /mnt
</verb></tscreen>

La nomenclatura de dispositivos FTL es difícil. Los números menores de los
dispositivos tienen tres partes: el número de tarjeta, el número de región
en esa tarjeta, y opcionalmente, la partición dentro de esa región. Una
región puede ser tratada como un simple dispositivo de bloques sin tabla
de partición (como un disquete), o puede particionarse como un disco duro.
El dispositivo <tt/ftl0c0/ es la tarjeta <tt/0/, región de memoria común
<tt/0/, la región entera. Los dispositivos de <tt/ftl0c0p1/ a
<tt/ftl0c0p4/ son primariamente las particiones de <tt/1/ a <tt/4/ si la
región ha sido particionada.

Hay dos formatos mayores para tarjetas de memoria flash: el estilo
<it/FTL/, y el sistema de archivos <it/Microsoft Flash/. El formato FTL es
generalmente más flexible porque permite que pueda utilizarse cualquier
sistema de archivos de alto nivel en una tarjeta flash como si fuera un
dispositivo de disco ordinario. El <it/FFS/ es un tipo sistema de archivos
completamente diferente. Linux no puede manejar actualmente tarjetas
formateadas con <it/FFS/. 

Las tarjetas flash <it/Intel Series 100/ usan el primer bloque flash de
128k para almacenar la información de la configuración de la tarjeta. Para
prevenir el borrado accidental de esta información, <tt/ftl_format/
automáticamente detectará esto y saltará al primer bloque cuando se cree
una partición FTL. 

<sect1>Tarjetas PCMCIA para unidades ATA/IDE
<p>

El soporte para unidades ATA/IDE se basa en el controlador IDE regular del
kernel. La parte específica PCMCIA del controlador es <tt/ide_cs/.
Asegúrese de usar <tt/cardctl/ o <tt/cardinfo/ para apagar la tarjeta
ATA/IDE antes de expulsarla, porque el controlador no fue programado a
prueba de extracción en caliente. 

La dirección de dispositivo que se pasa a <tt/ide.opts/ consiste de tres o
cuatro campos: el esquema actual, el número de socket, el número de serie
de la unidad, y un número opcional de partición. El comando <tt/ide_info/
puede usarse para obtener el número de serie del dispositivo IDE. Tal y
como sucede con los dispositivos SCSI, <tt/ide.opts/ se llama primero para
el dispositivo entero. Si <tt/ide.opts/ retorna una lista de particiones
en la variable <tt/PARTS/, el script entonces se llamará para cada
partición.

<sect2>Parámetros para discos ATA/IDE 
<label id="ide">
<p>

Los siguientes parámetros se pueden especificar en <tt/ide.opts/:

<descrip>

<tag/DO_FSTAB/Es una opción booleana (y/n): Especifica si se debe añadir
una entrada <tt>/etc/fstab</tt> para este dispositivo. 

<tag/DO_FSCK/Es una opción booleana (y/n): Especifica si se debe comprobar
este dispositivo antes de ser montado, con <tt>fsck -Ta</tt>.

<tag/DO_MOUNT/Es una opción booleana (y/n): Especifica si este dispositivo
debe montarse automáticamente al momento de insertar la tarjeta. 

<tag/FSTYPE, OPTS, MOUNTPT/El tipo de sistema de archivos, opciones de
montaje, y punto de montaje que se utilizarán para la entrada en
<tt/fstab/ y/o para montar el dispositivo.

</descrip>

He aqui un ejemplo del archivo <tt/ide.opts/ para montar la primera
partición de cualquier tarjeta ATA/IDE en <tt>/mnt</tt>. 

<tscreen><verb>
       case "$ADDRESS" in
       *,*,*,1)
           DO_FSTAB="y" ; DO_FSCK="y" ; DO_MOUNT="y"
           FSTYPE="msdos"
           OPTS=""
           MOUNTPT="/mnt"
           ;;
       *,*,*)
           PARTS="1"
           ;;
       esac
</verb></tscreen>


<sect2>Diagnóstico de problemas con adaptadores ATA/IDE 
<label id="idediag">
<p>

<itemize>

<item>Algunas unidades IDE violan la especificación PCMCIA al requerir un
tiempo mayor para iniciar que el máximo permitido para la configuración de
la tarjeta. Desde la versión <tt/3.0.6/, el controlador <tt/ide_cs/
automáticamente intentará sondear el dispositivo para darle tiempo de
iniciarlos. Con los controladores antiguos, necesita cargar el módulo
<tt/pcmcia_core/ con:

<tscreen><verb>
       CORE_OPTS="unreset_delay=400"
</verb></tscreen>

<item>Para usar una unidad de CD-ROM ATA/IDE, el kernel debe compilarse
con <tt/CONFIG_BLK_DEV_IDECD/ activado. Normalmente será el caso para los
kernels estándar, sin embargo es bueno estar enterado por si compila un
kernel personalizado. 

</itemize>

<sect1>Tarjetas multifunción 
<label id="multi">
<p>

Se puede compartir una simple interrupción entre varios controladores,
como el controlador serie y el controlador ethernet: en efecto: la
especificación PCMCIA requiere que todas las funciones de las tarjetas
compartan la misma interrupción. Normalmente, todas las funciones de las
tarjetas están disponibles sin tener que intercambiar controladores. 

El uso simultáneo de dos funciones de tarjetas es algo «difícil» y varios
fabricantes de hardware han implementado el compartir interrupciones en
sus propias formas incompatibles (y a veces propietarias). Los
controladores para algunas tarjetas (Ositech Jack de Diamond, 3Com 3c562,
Linksys) soportan de forma apropiada el acceso simultáneo, pero otras
(Megahertz en particular) no.

Los kernels antiguos no soportan el compartir interrupciones entre
diferentes controladores de dispositivos, así que no es posible para los
controladores PCMCIA el configurar esta tarjeta para acceso simultáneo
ethernet y módem. Los controladores ethernet y serie se cargan
automáticamente. Sin embargo, el controlador ethernet por omisión «posee»
la interrupción de la tarjeta. Para usar el módem, puede descargar el
controlador ethernet y reconfigurar el puerto serie haciendo algo como:

<tscreen><verb>
       ifconfig eth0 down
       rmmod 3c589_cs
       setserial /dev/modem autoconfig auto_irq
       setserial /dev/modem
</verb></tscreen>

El segundo <tt/setserial/ debe verificar que el puerto ha sido configurado
para usar la interrupción que previamente utilizaba el controlador
ethernet. 


<sect>Temas avanzados 
<label id="avan">
<p>

<sect1>Apartado de recursos para dispositivos PCMCIA
<p>

En teoría, no debe importar qué interrupción se reserva para cada
dispositivo, mientras dos dispositivos no sean configurados para usar la
misma interrupción.

En <tt>/etc/pcmcia/config.opts</tt> encontrará un lugar para excluir las
interrupciones que son usadas por dispositivos no PCMCIA. 

De igual modo, no hay forma de especificar directamente las direcciones de
E/S que va a utilizar una tarjeta. El archivo
<tt>/etc/pcmcia/config.opts</tt> permite especificar rangos de puertos
disponibles para ser usados por una tarjeta cualquiera, o para excluir
rangos que causan conflictos con otros dispositivos.

Después de modificar <tt>/etc/pcmcia/config.opts</tt>, puede reiniciar
<tt/cardmgr/ con <tt>kill -HUP</tt>.

La interrupción que se utiliza para monitorizar el estado de la tarjeta se
determina por el módulo controlador de bajo nivel del socket (<tt/i82365/
o <tt/tcic/) antes de que <tt/cardmgr/ pase a <tt>/etc/pcmcia/config</tt>,
así no se ve afectado con los cambios a este archivo. Para establecer esta
interrupción, use la opción <tt/cs_irq=/ cuando se cargue el controlador
del socket, estableciendo la variable <tt/PCIC_OPTS/ en
<tt>/etc/rc.d/rc.pcmcia</tt>

Todos los controladores de tarjetas tienen un parámetro llamado
<tt/irq_list/ para especificar qué interrupciones pueden intentar
reservar. Dichas opciones deben establecerse en el archivo
<tt>/etc/pcmcia/config</tt>. Por ejemplo: 

<tscreen><verb>
       device "serial_cs"
         module "serial_cs" opts "irq_list=8,12"
         ...
</verb></tscreen>

debe especificarse que el controlador serie debe utilizar sólo la irq 8 o
la 12. Sin importar las configuraciones de <tt/irq_list/, los Servicios de
Tarjetas nunca reservarán una interrupción que ya esté siendo usada por
otro dispositivo, o una interrupción que esté excluida en el archivo de
configuración. 

<sect1>Cómo puedo separar configuraciones de los dispositivos para casa y el
trabajo? 
<label id="casa">
<p>

Esto es bastante fácil con el soporte de «esquemas». Usando dos esquemas
de configuración, llamados <tt/casa/ y <tt/trabajo/. He aquí un ejemplo
del script <tt/network.opts/ con configuraciones específicas de esquemas:

<tscreen><verb>
       case "$ADDRESS" in
       trabajo,*,*,*)
           # definiciones para la tarjeta de red en el esquema trabajo
           ...
           ;;
       casa,*,*,*|default,*,*,*)
           # definiciones para la tarjeta de red en el esquema casa
           ...
           ;;
       esac
</verb></tscreen>

La primera parte de una dirección de dispositivo siempre es la
configuración del esquema. En este ejemplo, la segunda cláusula <tt/case/
aplicará para ambos esquemas. Así, si un esquema no está establecido por
cualquier razón, se tomará por omisión la configuración <tt/casa/.

Ahora, para seleccionar entre dos conjuntos de configuraciones, ejecute:

<tscreen><verb>
       cardctl scheme casa
</verb></tscreen>

o bien

<tscreen><verb>
       cardctl scheme trabajo
</verb></tscreen>

El comando <tt/cardctl/ hace el equivalente a apagar todas sus tarjetas y
luego reiniciarlas. Este comando puede ejecutarse de forma segura estando
el sistema PCMCIA cargado o no, pero el comando puede fallar si está
usando otros dispositivos PCMCIA en ese momento (incluso si sus
configuracion no es explícitamente dependiente de la configuración del
esquema).

Para mostrar la configuración del esquema, ejecute:

<tscreen><verb>
       cardctl scheme
</verb></tscreen>

Por omisión, la configuración del esquema es persistente a través de los
inicios del equipo. Esto puede tener efectos no deseados si la red se
inicializa para el ambiente equivocado. Opcionalmente, puede establecer el
valor inicial del esquema con la opción de inicio <tt/SCHEME/; consulte la
sección <ref id="inicio" name=" Opciones de Inicio"> para más detalles. 
También es posible establecer el esquema desde el prompt de inicio de
<tt/lilo/.  Debido a que <tt/lilo/ pasa opciones desconocidas a <tt/init/
como variables de entorno, un valor destinado a <tt/SCHEME/ (o cualquier
otra opción de inicio de PCMCIA) en el prompt de inicio se propagará al
script de inicio PCMCIA. 

Para ahorrarse tecleo, los esquemas pueden ser especificados en el archivo
de configuración de <tt/lilo/. Por ejemplo, puede tener: 

<tscreen><verb>
       root = /dev/hda1
       read-only
       image = /boot/vmlinuz
         label  = casa
         append = "SCHEME=casa"
       image = /boot/vmlinuz
         label  = trabajo
         append = "SCHEME=trabajo"
</verb></tscreen>

Así, al teclear <tt/casa/ o <tt/trabajo/ en el prompt de inicio arrancará
con el esquema PCMCIA apropiado.

<sect1>Arranque desde un dispositivo PCMCIA 
<label id="boot">
<p>

Tener el sistema de archivos raíz en un dispositivo PCMCIA es algo difícil
porque el sistema PCMCIA de Linux no está diseñado para ser enlazado
dentro del kernel. Sus componentes principales, los módulos cargables del
kernel y el demonio <tt/cardmgr/ dependen de un sistema que ya está
ejecutándose. La funcionalidad <tt/initrd/ del kernel sortea esta
limitación permitiendo a Linux iniciar utilizando un disco ram temporal
como una imagen raíz mínima, cargar los controladores, y remontar entonces
un sistema de archivos raíz diferente. La raíz temporal puede configurar
dispositivos PCMCIA y luego remontar un dispositivo PCMCIA como raíz.

La imagen <tt/initrd/ de residir en un dispositivo arrancable
obligatoriamente;  lo que implica no puede tratarse de un dispositivo
PCMCIA. Esta es una limitación de BIOS, no del kernel. Aqui es útil
distinguir entre dispositivos «arrancables» (es decir, dispositivos desde
los que se puede iniciar), y dispositivos <it/root-able/s (es decir,
dispositivos origen, que son montados como raíz). Los dispositivos
«arrancables» se determinan por BIOS, y están limitados generalmente a
discos flexibles internos y unidades de disco duro. La funcionalidad
<tt/initrd/ permite disponer de más dispositivos origen, no de más
dispositivos «arrancables».

Algunas distribuciones de Linux permitirán la instalación a un dispositivo
conectado a un adaptador SCSI PCMCIA, como un efecto lateral involuntario
de su soporte para instalar desde unidades de CD-ROM SCSI PCMCIA. Sin
embargo, en la actualidad, no hay herramientas de instalación de Linux que
soporten el configurar una imagen <tt/initrd/ apropiada para iniciar Linux
con un sistema de archivos raíz PCMCIA. Configurar un sistema con raíz
PCMCIA de este modo requiere que se use otro sistema Linux para crear la
imagen <tt/initrd/. Si no tiene otro sistema Linux disponible, una opción
podría ser instalar temporalmente una configuración mínima en una unidad
no PCMCIA, crear una imagen <tt/initrd/, y luego reinstalar en el
dispositivo PCMCIA destino. 

El <it/Linux Bootdisk-HOWTO/ contiene información general acerca de la
configuración de discos de inicio pero nada específico de <tt/initrd/.  El
documento principal de <tt/initrd/ se incluye con las distribuciones
recientes del código fuente del kernel, en
<tt>linux/Documentation/initrd.txt</tt>. Antes de empezar, debería leer
este documento. Es de utilidad estar familiarizado con <tt/lilo/. El uso
de <tt/initrd/ también requiere que tenga un kernel compilado con
<tt/CONFIG_BLK_DEV_RAM/ y <tt/CONFIG_BLK_DEV_INITRD/ activados.

Esta es una técnica de configuración avanzada, y requiere un alto nivel de
familiaridad con Linux y el sistema PCMCIA. Asegúrese de leer toda la
documentación relevante antes de empezar. Las siguientes recetas deberían
funcionar, pero las derivaciones de los ejemplos le pondrán rápidamente en
un territorio desconocido y «no soportado»; y estará solo.

Este método requiere obligatoriamente que se use una versión del
controlador PCMCIA <tt/2.9.5/ o posterior. Los paquetes PCMCIA antiguos o
los componentes individuales no funcionarán en el contexto <tt/initrd/. No
mezcle componentes de diferentes versiones. 

<sect2>El script <tt>pcinitrd</tt> 
<label id="pcinitrd">
<p>

El script <tt/pcinitrd/ crea una imagen básica para iniciar con una
partición raíz PCMCIA. La imagen incluye una jerarquía de directorios
mínima, algunos archivos de dispositivos, unos cuantos binarios,
bibliotecas compartidas, y un conjunto de módulos controladores PCMCIA.
Cuando se invoca <tt/pcinitrd/, especifique los módulos controladores que
busca que se incluyan en la imagen. Los componentes principales de PCMCIA,
<tt/pcmcia_core/ y <tt/ds/, se incluyen automáticamente.

Como ejemplo, digamos que su portátil usa un controlador compatible con
<tt/i82365/, y quiere iniciar Linux con el sistema de archivos raíz en un
disco duro conectado a un adaptador <it/Adaptec SlimSCSI/. Podría crear
una imagen <tt/initrd/ apropiada con:

<tscreen><verb>
       pcinitrd -v initrd pcmcia/i82365.o pcmcia/aha152x_cs.o
</verb></tscreen>

Para personalizar la secuencia de inicio de <tt/initrd/, podría montar la
imagen usando el dispositivo <it/loopback/ con un comando como: 

<tscreen><verb>
       mount -o loop -t ext2 initrd /mnt
</verb></tscreen>

y luego editar el script <tt/linuxrc/. Los archivos de configuración se
instalarán bajo <tt>/etc</tt> en la imagen, y también puede
personalizarse. Consulte la página del manual de <tt/pcinitrd/ para mayor
información.


<sect2>Creación de un disquete de inicio <tt>initrd</tt>
<label id="initrddsk">
<p>

Después de crear una imagen con <tt/pcinitrd/, puede crear un disquete de
inicio copiando el kernel, la imagen initrd comprimida, y algunos archivos
de soporte para <tt/lilo/ a un disquete limpio. En el ejemplo siguiente,
asumimos que el dispositivo raíz PCMCIA deseado es <tt>/dev/sda1</tt>:

<tscreen><verb>
       mke2fs /dev/fd0
       mount /dev/fd0 /mnt
       mkdir /mnt/etc /mnt/boot /mnt/dev
       cp -a /dev/fd0 /dev/sda1 /mnt/dev
       cp [kernel-image] /mnt/vmlinuz
       cp /boot/boot.b /mnt/boot/boot.b
       gzip < [initrd-image] > /mnt/initrd
</verb></tscreen>

Genere un fichero <tt>/mnt/etc/lilo.conf</tt> que contenga:

<tscreen><verb>
       boot=/dev/fd0
       compact
       image=/vmlinuz
           label=linux
           initrd=/initrd
           read-only
           root=/dev/sda1
</verb></tscreen>

Finalmente, invoque a lilo con:

<tscreen><verb>
       lilo -r /mnt
</verb></tscreen>

Cuando <tt/lilo/ es invocado con <tt/-r/, realiza todas las acciones
tomando como directorio raíz el especificado. La razón para crear los
archivos de dispositivo bajo <tt>/mnt/dev</tt> es que <tt/lilo/ no podrá
usar esos archivos en <tt>/dev</tt> cuando se ejecute con este directorio
raíz alternativo.

<sect2>Instalación de una imagen <tt>initrd</tt> en una unidad no-Linux 
<label id="nolinux">
<p>

Un uso común de la funcionalidad <tt/initrd/ puede darse en sistemas donde
el disco duro interno está dedicado a otro sistema operativo. El kernel de
Linux y la imagen <tt/initrd/ pueden ponerse en una partición no-Linux, y
<tt/lilo/ o <tt/LOADLIN/ pueden configurarse para iniciar Linux desde esas
imágenes. 

Asumiendo que tiene un kernel que se ha configurado para el dispositivo
raíz apropiado, y una imagen <tt/initrd/ creada en otro sistema, la forma
más fácil de iniciar Linux es utilizando <tt/LOADLIN/, como:

<tscreen><verb>
       LOADLIN <kernel> initrd=<imagen-initrd>
</verb></tscreen>

Una vez que pueda iniciar Linux en su máquina destino, puede instalar
<tt/lilo/ para permitir que Linux se inicie directamente. Por ejemplo,
digamos que <tt>/dev/hda1</tt> es la partición no-Linux destino y
<tt>/mnt</tt> puede usarse como un punto de montaje. Primero, genere un
subdirectorio en el destino para los archivos de Linux:

<tscreen><verb>
       mount /dev/hda1 /mnt
       mkdir /mnt/linux
       cp [imagen-del-kernel] /mnt/linux/vmlinuz
       cp [imagen-initrd] /mnt/linux/initrd
</verb></tscreen>

En este ejemplo, digamos que <tt>/dev/sda1</tt> es la partición raíz de
Linux deseada, en un disco duro SCSI montado vía un adaptador PCMCIA SCSI.
Para instalar <tt/lilo/, genere un archivo <tt/lilo.conf/ que contenga: 

<tscreen><verb>
       boot=/dev/hda
       map=/mnt/linux/map
       compact
       image=/mnt/linux/vmlinuz
               label=linux
               root=/dev/sda1
               initrd=/mnt/linux/initrd
               read-only
       other=/dev/hda1
               table=/dev/hda
               label=windows
</verb></tscreen>

La línea <tt/boot=/ dice que se instale el cargador de inicio en el MBR
(<it/master boot record/) del dispositivo especificado. La línea
<tt/root=/ identifica el sistema de archivos raíz deseado a usar después
de cargar la imagen <tt/initrd/, que puede resultar innecesario si la
imagen del kernel ya se encuentra configurada de esta forma. La sección
<tt/other=/ se usa para describir el otro sistema operativo instalado en
<tt>/dev/hda1</tt>. 

Para instalar <tt/lilo/ en este caso, teclee:

<tscreen><verb>
       lilo -C lilo.conf
</verb></tscreen>

Nótese que en este caso, el archivo <tt/lilo.conf/ usa rutas absolutas que
incluyen <tt>/mnt</tt>. Hice esto en el ejemplo porque el sistema de
archivos destino puede no soportar la creación de archivos de dispositivos
para las opciones <tt/boot=/ y <tt/root=/.

<sect>Problemas con tarjetas no soportadas 
<label id="unsupp">
<p>

<sect1>Configuración de tarjetas no reconocidas
<label id="configurando">
<p>

Asumiendo que su tarjeta está soportada por algún controlador existente,
todo lo que se necesita hacer es añadir una entrada a
<tt>/etc/pcmcia/config</tt> para decirle a <tt/cardmgr/ cómo identificar
la tarjeta, y qué controlador(es) necesitan ser asociados a esta tarjeta. 
Consulte la página del manual de <tt/pcmcia/ para más información acerca
del formato del archivo de configuración. Si inserta una tarjeta
desconocida, <tt/cardmgr/ normalmente almacenará parte de información de
la identificación en el registro del sistema, lo cual puede usarse para
elaborar la entrada de configuración. Esta información puede mostrarse
también con el comando <tt/cardctl ident/. 

He aquí un ejemplo de cómo avisa <tt/cardmgr/ de una tarjeta no soportada
en <tt>/usr/adm/messages</tt>

<tscreen><verb>
  cardmgr[460]: unsupported card in socket 1
  cardmgr[460]: product info: "MEGAHERTZ", "XJ2288", "V.34 PCMCIA MODEM"
  cardmgr[460]: manfid: 0x0101, 0x1234  function: 2 (serial)
</verb></tscreen>

La entrada correspondiente en <tt>/etc/pcmcia/config</tt> podría ser:

<tscreen><verb>
       card "Megahertz XJ2288 V.34 Fax Modem"
         version "MEGAHERTZ", "XJ2288", "V.34 PCMCIA MODEM"
         bind "serial_cs"
</verb></tscreen>

o usar los códigos de ID más compactos del producto:

<tscreen><verb>
       card "Megahertz XJ2288 V.34 Fax Modem"
         manfid 0x0101, 0x1234
         bind "serial_cs"
</verb></tscreen>


Puede usar <tt/*/ para comparar cadenas que no necesiten concordar
exactamente, como los números de versión. Cuando haga nuevas entradas en
la configuración, hay que ser cuidadosos para copiar las cadenas
exactamente, preservando mayúsculas y minúsculas, y espacios en blanco.
Asegúrese también de que la entrada en la configuración tiene el mísmo
número de cadenas que aparecen en el archivo de registro.

Tenga en cuenta que puede especificar cualquier controlador para una
tarjeta, pero si sólo está dando palos de ciego, no hay mucha razón para
esperar que esto resulte productivo. Puede tener suerte y encontrar que su
tarjeta está soportada por un controlador existente. Sin embargo, el
resultado más probable es que el controlador no funcione, y puede tener
efectos laterales desafortunados como el congelamiento de su sistema. A
diferencia de la mayoría de los controladores de dispositivos, los cuales
comprueban la pressencia de la tarjeta apropiada, el sondeo para un
dispositivo PCMCIA se hace con <tt/cardmgr/, y el controlador por sí mismo
puede no verificar antes de intentar comunicarse con el dispositivo. 

Después de editar <tt>/etc/pcmcia/config</tt>, envíe una señal a
<tt/cardmgr/ para recargar el archivo con:

<tscreen><verb>
       kill -HUP `cat /var/run/cardmgr.pid`
</verb></tscreen>

Si configura una entrada para una tarjeta nueva, por favor, envíeme una
copia para que pueda incluirla en el archivo de configuración estándar.

<sect1>Soporte para una tarjeta ethernet compatible con NE2000
<label id="ne2000">
<p>

Antes de empezar: este procedimiento sólo funcionará para tarjetas
ethernet simples. Las tarjetas multifunción (por ejemplo, las tarjetas
«combo» ethernet/módem) tienen una capa extra de complejidad en relación a
cómo están integradas las dos funciones, y generalmente no pueden
soportarse sin obtener algo de información de la configuración provista
por el fabricante de la tarjeta. Usar el procedimiento siguiente con una
tarjeta multifunción no resultará productivo en absoluto. 

Primero, compruebe si la tarjeta es reconocida por <tt/cardmgr/. Algunas
tarjetas que no están listadas en <tt/SUPPORTED.CARDS/ son realmente
versiones OEM de tarjetas que sí están soportadas. Si encuentra una
tarjeta como ésta, hágamelo saber para que pueda añadirla a la lista. 

Si su tarjeta no es reconocida, siga las instrucciones en la sección <ref
id="configurando" name="Configuración de tarjetas no reconocidas"> para
crear una entrada en la configuración para su tarjeta, y relacionar la
tarjeta con el controlador <tt/pcnet_cs/. Reinicie <tt/cardmgr/ para
utilizar el archivo de configuración actualizado.

Si el controlador <tt/pcnet_cs/ dice que no puede determinar la dirección
ethernet del hardware de la tarjeta, edite su nueva entrada en la
configuración para relacionar la tarjeta con el controlador de memoria
<tt/memory_cs/. Reinicie <tt/cardmgr/ para utilizar el nuevo archivo de
configuración actualizado. Necesitará conocer la dirección ethernet del
hardware de la tarjeta. Esta dirección es una serie de seis números
hexadecimales de dos dígitos, impresos normalmente en la misma tarjeta. Si
no están impresos en la tarjeta, puede usar un controlador de DOS para
mostrar la dirección. En cualquier caso, una vez que la sepa, ejecute:

<tscreen><verb>
       dd if=/dev/mem0a count=20 | od -Ax -t x1
</verb></tscreen>

y busque el volcado de información de su tarjeta. Sólo los bytes pares
están definidos, así que ignore los bytes impares del volcado. Anote el
desplazamiento hexadecimal del primer byte de la dirección. Ahora, edite
<tt>clients/pcnet_cs.c</tt> y busque la estructura <tt/hw_info/. 
Necesitará crear una nueva entrada para la tarjeta. El primer campo es el
desplazamiento de memoria. Los siguientes tres campos son los primeros
tres bytes de la dirección de hardware. El campo final contiene algunos
indicadores de características especiales de la tarjeta; para empezar,
pruebe estableciéndola a <tt/0/. 

Después de editar <tt/pcnet_cs.c/, compile e instale el nuevo módulo. 
Edite nuevamente <tt>/etc/pcmcia/config/</tt>, y cambie la relación de
<tt/memory_cs/ con <tt/pcnet_cs/. Siga las instrucciones para recargar el
archivo de configuración, y habrá terminado. Por favor mándeme copias de
sus nuevas entradas de configuración a <tt/hw_info/.

Si no puede encontrar la dirección hardware de su tarjeta en el vaciado
hexadecimal, como un último recurso, puede «forzar» la dirección cuando se
inicializa el módulo <tt/pcnet_cs/. Edite <tt>/etc/pcmcia/config.opts</tt>
y añada una opción <tt/hw_addr/, como esta: 

<tscreen><verb>
       module "pcnet_cs" opts "hw_addr=0x00,0x80,0xc8,0x01,0x02,0x03"
</verb></tscreen>

Por supuesto, sustituya su propia dirección de hardware de la tarjeta en
el punto apropiado. Tenga en cuenta que si ha tenido que hacer esto, es
muy difícil que su tarjeta sea genuinamente compatible con NE2000. De
hecho, no estoy seguro de la existencia de tarjetas que no sean manejadas
por alguno de los dos primeros métodos. 

<sect1>Tarjetas PCMCIA para unidades de disquete 
<label id="floppy">
<p>

La interfaz para disquete PCMCIA que se usa en los <it/Compaq Aero/ y
otros equipos todavía no está soportada por este paquete. La dificultad
para soportar el disquete Aero radica en que el Aero parece usar un
controlador PCMCIA personalizado para soportar DMA en el disquete. Sin
saber exáctamente cómo se hace esto, no hay forma de implementar soporte
bajo Linux. 

Si la tarjeta del adaptador de disquete está presente cuando se inicia, la
BIOS configurará la tarjeta, y Linux la identificará como una unidad de
disquete normal. Cuando se cargan los controladores PCMCIA de Linux,
notarán que la tarjeta ya está configurada y conectada al controlador de
Linux, y este socket se dejará solo. Así que, la unidad puede usarse si
está presente al momento de iniciar, pero la tarjeta no se puede
intercambiar en caliente.

<sect1>¿Qué hay de las tarjetas Xircom? 
<label id="xircom">
<p>

El paquete actual PCMCIA incluye un controlador para las tarjetas ethernet
y ethernet/modem de Xircom, gracias al trabajo de Werner Koch. He
dispuesto un foro especialmente para la discusión del desarrollo del
controlador Xircom, en <tt><htmlurl
url="http://hyper.stanford.edu/HyperNews/get/pcmcia/xircom.html" 
name="http://hyper.stanford.edu/HyperNews/get/pcmcia/xircom.html"></tt>. 

Durante mucho tiempo, las tarjetas Xircom no fueron soportadas porque
Xircom tenía como política de la compañía no divulgar información técnica
acerca de sus tarjetas. Sin embargo, han modificado sus reglas, y ahora,
distribuyen información de los controladores... 

<sect>Trucos para depurar e información de programación
<label id="tips">
<p>

<sect1>Envío de informes de <it>bugs</it> que son de utilidad 
<label id="bugs">
<p>

La mejor forma de informar de <it/bugs/ es usar las listas de mensajes de
HyperNews en el servidor web de Linux PCMCIA. De este modo, otras personas
podrán ver los problemas actuales (y reparaciones o trabajos relacionados,
si están disponibles). He aqui algunas cosas que se deben incluir en los
informes de <it/bugs/: 

<itemize>

<item>El tipo de sistema, y la salida del comando <tt/probe/.

<item>Qué tarjetas PCMCIA está usando.

<item>Su versión del kernel de Linux, y la versión del controlador PCMCIA.

<item>Cualquier cambio que haya hecho a los archivos de inicio en
<tt>/etc/pcmcia</tt>, o al script de inicio de PCMCIA. 

<item>Todos los mensajes relacionados con PCMCIA en el registro de su
sistema. 

</itemize>

Todos los módulos PCMCIA y el demonio <tt/cardmgr/ envían mensajes de
estado al registro del sistema, que estará normalmente en sitios como
<tt>/var/log/messages</tt> o <tt>/usr/adm/messages</tt>. Este archivo debe
ser el primer lugar a comprobar cuando se esté rastreando un problema.
Cuando envíe una notificación de bug, incluya siempre el contenido de este
archivo. Si tiene problemas para encontrar los mensajes de su sistema,
revise <tt>/etc/syslog.conf</tt> para ver cuantas clases diferentes de
mensajes se manejan.

Antes de enviar una notificación de bug, por favor asegúrese que no esté
usando una copia obsoleta del paquete de controladores. Aunque resulte
gratificante leer informes sobre un bug que ya he reparado, no supone un
uso particularmente constructivo de mi tiempo. 

Si no tiene acceso a web, puede enviarme los informes de <it/bugs/ a
<tt><htmlurl url="mailto:dhinds@hyper.stanford.edu" 
name="dhinds@hyper.stanford.edu"></tt>. Sin embargo, prefiero que sean
introducidos en mi servidor web, así pueden ser vistos por otros. 

<sect1>Interpretación de los informes generados por los <it>traps</it> del kernel 
<label id="trampas">
<p>

Si su problema incluye un fallo del kernel, el vaciado del registro del
fallo sólo es útil si puede traducir la dirección del error, EIP, o algo
semejante. Las versiones recientes de <tt/klogd/ intentan traducir las
direcciones de fallos basándose en el mapa actual de símbolos del kernel,
pero puede que no funcione si el error se produce en un módulo, o si el
problema es lo bastante severo como para que que <tt/klogd/ no pueda
terminar de escribir la información del fallo en el registro del sistema.

Si se localiza en el kernel principal, la dirección de fallo puede
encontrarse en el archivo <tt/System.map/. El cual puede estar instalado
en <tt>/System.map</tt> o en <tt>/boot/System.map</tt>. Si está en un
módulo, el comando <tt/nm/ proporciona la misma información; sin embargo,
la dirección del fallo necesita ajustarse basándose en la dirección de
carga del módulo. Digamos que experimenta el siguiente fallo del kernel:

<tscreen><verb>
       Unable to handle kernel NULL pointer dereference
       current->tss.cr3 = 014c9000, %cr3 = 014c9000
       *pde = 00000000
       Oops: 0002
       CPU:    0
       EIP:    0010:[<c2026081>]
       EFLAGS: 00010282
</verb></tscreen>

La dirección de fallo es <tt/0xc2026081/. Si buscamos en <tt/System.map/,
vemos que esto está más allá de los límites del kernel, por ejemplo, es un
módulo del kernel. Para determinar qué módulo, revise la salida de
<tt>ksyms -m | sort</tt>

<tscreen><verb>
       Address   Symbol                            Defined by
       c200d000  (35k)                             [pcmcia_core]
       c200d10c  register_ss_entry                 [pcmcia_core]
       c200d230  unregister_ss_entry               [pcmcia_core]
                 ...
       c2026000  (9k)                              [3c574_cs]
       c202a000  (4k)                              [serial_cs]
</verb></tscreen>

Así, <tt/0xc2026081/ está en el módulo <tt/3c574_cs/ con un desplazamiento
de <tt/0x0081/ desde el inicio del módulo. Todavía no podemos ver más allá
de este desplazamiento en <tt/3c574_cs.o/: cuando el kernel carga un
módulo, inserta un encabezado en la dirección de carga del mismo, así el
inicio real se desplaza desde la dirección mostrada en <tt/ksyms/.  El
tamaño del encabezado varía con la versión del kernel:  para encontrar el
tamaño en su kernel, busque un módulo que exporte símbolos (como
<tt/pcmcia_core/), y compare la dirección del símbolo con la salida de
<tt/nm/ para ese mismo símbolo. En este ejemplo, <tt/register_ss_entry/ se
carga con un desplazamiento de <tt/0xc200d10c - 0xc200d000 = 0x010c/,
mientras que <tt/nm pcmcia_core.o/ muestra el desplazamiento como
<tt/0x00c0/, así que el tamaño del encabezado es <tt/0x010c - 0x00c0 =
0x004c/ bytes. 

Regresando a <tt/3c574_cs.o/, nuestro desplazamiento de fallo es
<tt/0x0081/, y restando el encabezado <tt/0x004c/, el desplazamiento real
del módulo es <tt/0x0035/. Ahora comprobando el resultado de un <tt/nm
3c574_cs.o | sort/, observamos: 

<tscreen><verb>
  0000002c d if_names
  0000002c t tc574_attach
  00000040 d mii_preamble_required
  00000041 d dev_info
</verb></tscreen>

El fallo se localiza en <tt/tc574_attach()/.

En este ejemplo, el fallo no causó un congelamiento total del sistema, así
que <tt/ksyms/ puede ejecutarse después de haber tenido lugar el fallo. En
otros casos, puede que tenga que deducir indirectamente las direcciones de
carga del módulo. La misma secuencia de eventos cargará normalmente los
módulos en el mismo orden y en las mismas direcciones. Si se produce un
fallo cuando se inserta cierta tarjeta, obtenga la salida de <tt/ksyms/
antes de insertar la tarjeta, o con una tarjeta diferente insertada. Puede
cargar manualmente los módulos controladores de la tarjeta con <tt/insmod/
y ejecutar <tt/ksyms/ antes de insertarla. 

Para profundizar, consulte <tt/man insmod/, <tt/man ksyms/, y <tt/man
klogd/. En el árbol de los fuentes del kernel,
<tt>Documentation/oops-tracing.txt</tt> también es relevante. He aquí unas
cuantas pistas para depurar el kernel:

<itemize>

<item>Dependiendo del error, puede ser útil traducir direcciones en el
<it/Trazado de llamadas/, usando el mismo procedimiento para la dirección
de error principal.

<item>Para diagnosticar un congelamiento silencioso, pruebe provocar el
problema con X desactivado, porque los mensajes del kernel se envían a la
consola en texto, y no serán visibles bajo X. 

<item>Si mata a <tt/klogd/ muchos de los mensajes del kernel harán eco
directamente a la consola de texto, el cual puede ser útil si el problema
impide a <tt/klogd/ escribir en el registro del sistema.

<item>Para hacer que todos los mensajes del kernel se envíen a la consola,
para kernels <tt/2.1.x/, si existe <tt>/proc/sys/kernel/printk</tt>,
hacer: 

<tscreen><verb>
       echo 8 > /proc/sys/kernel/printk
</verb></tscreen>

<item>La combinación de teclas <tt/&lt;RightAlt&gt;&lt;ScrLk&gt;/ imprime
un vaciado del registro en la consola de texto. Esto puede funcionar en
caso de que el sistema esté o no completamente sin responder, y la
dirección EIP puede interpretarse como fallo del kernel.

<item>Para los kernels <tt/2.1.x/ configurados con <tt/CONFIG_MAGIC_SYSRQ/
activado, se pueden activar varias funciones de emergencia por medio de
las combinaciones especiales de las teclas <tt/&lt;Alt&gt;&lt;SysRq&gt;/,
que están documentadas en <tt>Documentation/sysrq.txt</tt> dentro del
árbol de los fuentes del kernel. 

</itemize>

<sect1>Primeros auxilios al depurar a bajo nivel 
<label id="aux">
<p>

Los módulos PCMCIA contienen bastante código de depuración compilado de
forma condicional. La mayor parte de este código está bajo el control de
las definiciones del preprocesador de <tt/PCMCIA_DEBUG/. Si no está
definido, el código de depuración no se compilará. Si se establece a
<tt/0/, se compilará pero no estará activo. Los números mayores
especifican el incremento del nivel de detalle del registro. Cada módulo
compilado con <tt/PCMCIA_DEBUG/ definido tendrá un parámetro entero,
<tt/pc_debug/, que controla el nivel de detalle de su salida. Esto puede
ajustarse cuando se carga el módulo, así la salida puede controlarse en
base a cada módulo sin necesidad de recompilar. 

Su configuración por omisión para <tt/syslogd/ puede descartar los
mensajes de depuración del kernel. Para asegurarse de que se están
registrando, edite <tt>/etc/syslog.conf</tt> y compruebe que los mensajes
<tt/kern.debug/ se registren en algún lugar. Consulte <tt/man syslog.conf/
para más detalles. 

Hay algunas herramientas de depuración en el subdirectorio
<tt>debug_tools</tt> dentro de la distribución de PCMCIA. Las utilidades
<tt/dump_tcic/ y <tt/dump_i365/ generan volcados completos de los
controladores PCMCIA, y decodifican mucha de la información del registro. 
Son útiles si tiene acceso a una hoja con los datos del chip controlador
correspondiente. El comando <tt/dump_cis/ (<tt/dump_tuples/ en las
distribuciones <tt/pre-3.0.2/) lista el contenido de la CIS (<it/Card
Information Structure/) (Estructura de Información de Tarjeta), y
decodifica algunos bits importantes. <tt/dump_cisreg/ muestra los
registros de configuración local de una tarjeta. 

El controlador de tarjetas de memoria <tt/memory_cs/ a veces también es
útil para depurar problemas con PC Cards de 16 bits. Puede utilizarse con
cualquier tarjeta, y no interfiere con otros controladores. Puede usarse
para acceder directamente a los atributos de memoria o memoria común de
cualquier tarjeta. De igual modo, con las tarjetas <it/CardBus/, el
controlador <tt/memory_cb/ puede utilizarse con cualquier tarjeta de 32
bits, para dar acceso directo a los espacios de direcciones de esa
tarjeta. Revise las páginas del manual para más información.

<sect1><tt>/proc/bus/pccard</tt> 
<label id="pccard">
<p>

A partir de los kernels <tt/2.1.103/, el paquete PCMCIA crea un árbol de
información de estado bajo <tt>/proc/bus/pccard</tt>. La entrada
<tt/memory/ muestra las posiciones de memoria para dispositivos PC Card en
un formato similar a <tt>/proc/ioports</tt>. Cada socket tiene también su
propio subdirectorio de entradas de estado. La entrada <tt/info/
identifica el controlador del host y describe sus características. La
entrada <tt/exca/ es un volcado del registro <tt/ExCA/ compatible con
<it/Intel i82365sl/ que se configura para ese socket. Para los puentes
<it/CardBus/, la entrada <tt/pci/ es el volcado del espacio de la
configuración PCI del puente, y la entrada <tt/cardbus/ es el vaciado de
los registros de configuración de <it/CardBus/.

<sect1>Programación de controladores de servicios PCMCIA para nuevas tarjetas
<label id="escribiendo">
<p>

El <it/Linux PCMCIA Programmer's Guide/ constituye la mejor documentación
acerca de la interfaz de los controladores. La última versión estará
siempre disponible en <tt/hyper.stanford.edu/ en <tt>/pub/pcmcia/doc</tt>,
o vía WWW en <tt><htmlurl
url="http://hyper.stanford.edu/HyperNews/get/pcmcia/home.html" 
name="http://hyper.stanford.edu/HyperNews/get/pcmcia/home.html"></tt>. 

Con los dispositivos relativamente similares a los dispositivos ISA
normales, probablemente pueda Vd. usar parcialmente controladores Linux
existentes. En algunos casos, el tropiezo más grande será modificar un
controlador existente que pueda manejar la inserción y extracción de
dispositivos después del momento de iniciar. De los controladores
actuales, el controlador de tarjeta de memoria es el único controlador
autónomo, que no depende de otras partes del kernel de Linux para hacer la
mayor parte del trabajo sucio. 

En muchos casos, el mayor impedimento para soportar un nuevo tipo de
tarjeta es el obtener información técnica por parte del fabricante. Puede
ser difícil el encontrar a quién preguntar, o a quien explicar que
información se necesita. Sin embargo, con pocas excepciones, es muy
difícil, si no imposible, el implementar un controlador para una tarjeta
sin información técnica por parte del fabricante.

He escrito un controlador modelo con muchos comentarios que explican
bastante cómo el controlador se comunica con los Servicios de Tarjetas; lo
encontrará en la distribución fuente de PCMCIA en
<tt>clients/dummy_cs.c</tt>.

<sect1>Sugerencias para los autores de controladores PCMCIA
<label id="sugerencias">
<p>

He decidido que no es realmente factible para mi el distribuir todos los
controladores de PCMCIA como parte del paquete PCMCIA. Cada controlador
nuevo hace que el paquete principal sea incrementalmente más dificil de
mantener, e incluir un controlador inevitablemente transfiere algo del
trabajo de mantenimiento del autor del controlador hacia mí. En lugar de
ello, decidiré caso por caso si se incluyen o no los controladores que
sean contribuciones, basándome en la demanda de los usuarios y también en
la facilidad de mantenerlos. Para los controladores que no se incluyen en
el paquete principal, sugiero que los autores de los controladores adopten
el esquema siguiente para empaquetar sus controladores de cara a su
distribución.

Los archivos controladores deben acomodarse en el mismo esquema del
directorio que utiliza la distribución fuente de PCMCIA, así el
controlador puede ser desempaquetado en la parte más alta del árbol de los
fuentes de PCMCIA. Debe incluir los archivos fuentes (en
<tt>./modules/</tt>), una página del manual (en <tt>./man/</tt>), y los
archivos de configuración (en <tt>./etc/ </tt>). El directorio más alto
debe incluir también un archivo <tt/README/.

El directorio de más alto nivel debe incluir un <it/makefile/, configurado
para que <tt/make -f ... all/ y <tt/make -f ... install/ compilen el
controlador e instalen los archivos apropiados. Si este archivo tiene una
extensión <tt/.mk/, será invocado automáticamente por el <tt/Makefile/ de
más alto nivel para los destinos <tt/all/ e <tt/install/. He aquí un
ejemplo de cómo debe elaborarse un <tt/Makefile/:

<tscreen><verb>
       # Un simple Makefile para un controlador de contribución
       FILES = sample_cs.mk README.sample_cs \
               modules/sample_cs.c modules/sample_cs.h \
               etc/sample etc/sample.opts man/sample_cs.4
       all:
               $(MAKE) -C modules MODULES=sample_cs.o
       install:
               $(MAKE) -C modules install-modules MODULES=sample_cs.o
               $(MAKE) -C etc install-clients CLIENTS=sample
               $(MAKE) -C man install-man4 MAN4=sample_cs.4
       dist:
               tar czvf sample_cs.tar.gz $(FILES)
</verb></tscreen>

Este <tt/Makefile/ usa los destinos de instalación que se definen en la
versión <tt/2.9.10/ y versiones posteriores del paquete PCMCIA. Este
makefile también incluye un destino <tt/dist/ para conveniencia del autor
del controlador.  Probablemente desee añadir un número de versión al final
del nombre del paquete (por ejemplo, <tt/sample_cs-1.5.tar.gz/). Una
distribución completa puede ser similar a: 

<tscreen><verb>
       sample_cs.mk
       README.sample_cs
       modules/sample_cs.c
       modules/sample_cs.h
       etc/sample
       etc/sample.opts
       man/sample_cs.4
</verb></tscreen>

De esta forma, cuando un controlador de contribución se desempaquete, se
convierte en parte esencial del árbol de los fuentes de PCMCIA. Puede
hacer uso de los archivos de encabezados de PCMCIA, así como también de la
maquinaria para comprobar la configuración del sistema del usuario, y
chequeo automático de dependencias, tal y como un controlador «normal». 

Aceptaré controladores preparados de acuerdo a esta especificación y los
colocaré en el directorio <tt>/etc/pcmcia/contrib</tt> en mi servidor FTP,
<tt/hyper.stanford.edu/. El archivo <tt/README/ en este directorio
describirá cómo desempaquetar un controlador de contribución.

La interface de controlador no ha cambiado mucho a pesar del tiempo, y ha
preservado casi siempre su compatibilidad con las versiones anteriores. Un
controlador normalmente no necesitará actualizarse para revisiones menores
en el paquete principal. Trataré de notificar a los autores de los
controladores «externos» de los cambios que se requiera realizar a sus
controladores.

<sect1>Sugerencias para encargados de las distribuciones de Linux
<label id="encargados">
<p>

Si su distribución tiene herramientas para configuración del sistema que
quiera que sean compatibles PCMCIA, por favor, use los archivos
<tt/*.opts/ en <tt>/etc/pcmcia</tt> para su «integración». Dichos archivos
no serán modificados si un usuario compila e instala una nueva versión del
paquete PCMCIA. Si modifica los scripts principales de configuración, una
instalación fresca sobreescribirá silenciosamente sus scripts
personalizados y romperá la conexión con sus herramientas de
configuración. Contacte conmigo si no está seguro de cómo escribir un
script de opciones apropiado, o si necesita características adicionales.

Resulta muy útil para los usuarios (y para mi) que documente cómo deriva
su distribución del paquete PCMCIA que se describe en este documento. En
particular, por favor documente los cambios al script de inicio y a los
scripts de configuración. Si me manda la información apropiada, la
incluiré en la sección <ref id="distribuciones" name="Notas acerca de
distribuciones de Linux específicas">.

Cuando construya una distribución PCMCIA, considere el incluir los
controladores aportados, que no son parte del paquete PCMCIA principal. 
Por razones de mantenimiento, estoy tratando de limitar el tamaño del
paquete principal, añadiendo solamente controladores nuevos si considero
que son de interés general. Los demás controladores se distribuirán por
separado, como se describe en la sección anterior. La división entre
controladores generales y separados es algo arbitraria y en parte
histórica, y no debería implicar diferencia alguna en cuanto a calidad. 

<sect>Anexo: El INSFLUG <label id="Insflug">
<p>

El <it/INSFLUG/ forma parte del grupo internacional <it>Linux Documentation
Project</it>, encargándose de las traducciones al castellano de los Howtos,
así como de la producción de documentos originales en aquellos casos en los
que no existe análogo en inglés, centrándose, preferentemente, en documentos
breves, como los <em/COMOs/ y <em/PUFs/ (<bf/P/reguntas de <bf/U/so
<bf/F/recuente, las <it/FAQs/. <tt/:)/ ), etc.

Diríjase a la sede del Insflug para más información al respecto.

En élla encontrará siempre las <bf/últimas/ versiones de las traducciones
«oficiales»:  <tt><htmlurl url="http://www.insflug.org" 
name="www.insflug.org"></tt>. Asegúrese de comprobar cuál es la última
versión disponible en el Insflug antes de bajar un documento de un
servidor réplica. 

Además, cuenta con un sistema interactivo de gestión de fe de erratas y
sugerencias en línea, motor de búsqueda específico, y más servicios en los
que estamos trabajando incesantemente.
                                                
Se proporciona también una lista de los servidores réplica (<it/mirror/)
del Insflug más cercanos a Vd., e información relativa a otros recursos en
castellano.

En <tt><htmlurl url="http://www.insflug.org/insflug/creditos.php3"
name="http://www.insflug.org/insflug/creditos.php3"></tt> cuenta con una
detallada relación de las personas que hacen posible tanto esto como las
traducciones.

¡Diríjase a <tt><htmlurl
url="http://www.insflug.org/colaboracion/index.php3"
name="http://www.insflug.org/colaboracion/index.php3"></tt> si desea
unirse a nosotros!.

«Cartel» Insflug, <tt><htmlurl url="mailto:cartel@insflug.org"
name="cartel@insflug.org"></tt>. 

</article>
