Los controladores son el software que hace funcionar al dispositivo, y que da soporte lógico al Sistema Operativo para interactuar con él. En Linux la integración de este soporte se lleva a cabo configurando y compilando el núcleo o kernel, con lo que obtenemos un corazón del Sistema Operativo a la medida de cada máquina.
Linux ofrece la posibilidad de compilarlo íntegro en el kernel o en
módulos aparte, que se cargan según los necesite el sistema o no. Si no
está familiarizado con todo esto, es momento de que lea el
Kernel-Como, disponible en el Insflug
http://www.insflug.org.
El kernel necesitará tener dos tipos de soporte; uno genérico, (módulo
isdn) y otro específico a la tarjeta (hisax, etc).
Como algunas tarjetas RDSI, especialmente las que tienen soporte experimental, sólo funcionan con controladores específicos modulares, nos centraremos en este tipo de soporte, por ser más universal.
No obstante, en los ejemplos supondremos que hacemos uso de kernels
estables (2.0.xx), aunque tengamos que parchearlos. Puede usar
kernels de desarrollo si lo prefiere, tan sólo téngalo en cuenta en los
ejemplos que aplique y modifíquelos en consecuencia, sin olvidar que estos
kernels son para lo que son, desarrollo, no siendo muy idóneos para
la instalación por primera vez de algo que se desconoce.
Antes de continuar, suponemos que ha leído la sección soportadas y que sabe a ciencia cierta que su tarjeta está soportada.
Si no parece estarlo, es conveniente que lea (sí, bueno, relea ;-) de todos
modos la documentación que hay en /usr/src/linux/Documentation/isdn
que siempre estará más actualizada que este Como. Si no, no está todo
perdido; obtenga el último árbol de desarrollo de
ftp://ftp.suse.com/pub/isdn4linux/v2.0/isdn.tar.gz y eche un
vistazo a los ficheros de isdn/Documentation/isdn/, puede que se
lleve una grata sorpresa.
Si su tarjeta está soportada en la distribución estándar del kernel actual (2.0.34 a día de hoy), salte a la sección confkr. Si necesita parchear, siga leyendo.
Para añadir soporte al kernel actual, integraremos una parte del árbol de
fuentes modificada, que añada soporte para la misma. Obtenga el fichero
ftp://ftp.suse.com/pub/isdn4linux/v2.0/isdn.tar.gz, suele ser
un enlace simbólico a la última versión del árbol de desarrollo RDSI
disponible.
No obstante... el soporte es experimental. Casos típicos son los de las últimamente disponibles popularmente Teles.SO 16.3c o las Asuscom. Los que suscriben no han visto nada anormal (cierto es que el tiempo de que hemos dispuesto para testearlas ha sido breve) y tienen noticias de varios servidores de los llamados de producción que están funcionando sin problemas con kernels estables y estas tarjetas.
No obstante, no se parchea en el sentido estricto, ya que lo único que se sustituye es la parte correspondiente a RDSI.
La parte del árbol modificada lleva un fichero llamado std2kern que
hace el trabajo de parcheo por nosotros, siempre y cuando
/usr/src/linux sea el directorio donde residan las fuentes de
linux. Asegúrese de que exista; si en su sistema el directorio se llama
/usr/src/linux-2.0.33, compruebe, y en su ausencia cree un
enlace al mismo llamado linux; por ejemplo:
cd /usr/src ;
ln -s linux-2.0.33 linux
Descomprima el árbol de fuentes isdn: suponiendo que ha dejado el
fichero en /tmp:
( cd /usr/src; tar zxvf /tmp/isdn.tar.gz )
Acceda a /usr/src/isdn, y ejecute el comando std2kern -d:
cd /usr/src/isdn
./std2kern -d
no olvide el "./" para dar el path directo al fichero, en
la mayoría de los sistemas el directorio actual no está en el PATH
por seguridad.
Compruebe que no se producen mensajes de error. Si es así, averigüe qué sucede. Lo más típico es que se haya equivocado en la elección de fichero, y haya escogido uno para un kernel de otra versión (2.1.xx por ejemplo).
Una vez hemos llevado a cabo los pasos anteriores procederemos a la configuración y posterior recompilación del kernel. Si no está habituado a esto, léase primero el Kernel-Como, disponible en Insflug, vea sección INSFLUG.
Acceda a /usr/src/linux y ejecute su método preferido de
configuración. Asegúrese de activar, en la sección principal, Code
maturity level options el apartado Prompt for development and/or
incomplete code/drivers, o de lo contrario, el programa de
configuración no le dará opción a seleccionar controladores
experimentales.
Una vez hecho esto, seleccione:
Vaya a la sección ISDN subsystem del menú principal:
M).Esto es para cuanto a soporte RDSI se refiere. En cuanto a soporte PPP, cuestiones específicas de redes, y demás aspectos, recurra al Como apropiado.
En la sección ISDN subsystem del menú principal, active el controlador que dé soporte a su tarjeta. El más popular es el HiSax, si ese es su caso, deberá además especificar:
De nuevo, no conocemos ni podemos conocer todas las tarjetas soportadas por Linux. Es posible que en drivers experimentales haya que indicar alguna otra opción; recurra a su sentido común, a la documentación (a la que no nos cansaremos de remitirle; este documento no es más que una guía) y a nosotros, a fin de actualizar este Como.
Salga del menú guardando los cambios, y compile; no olvide el make
modules y el make modules_install, y reinstalar el LILO para dicho
kernel.
Para más información de cómo recompilar el kernel, véase el Kernel-Como, disponible en el Insflug, vea sección INSFLUG.
Ya he recompilado, instalado los módulos, y arrancado con el nuevo
kernel. Además, he usado isapnp y todo parece haber ido
bien... ¿Qué hago ahora?
Se ha ganado un descanso. Tómese algo... ;-) No, en serio. Ahora viene la parte más interesante.
Hay varias formas de cargar los módulos, en cualquier caso, la manera que
nunca falla es hacerlo a mano directamente desde la línea de comandos.
Supondremos que hacemos uso del soporte específico HiSax. La sintaxis del
módulo hisax es la que sigue, si bien es conveniente leer (al final lo
conseguiremos ;-), especialmente en drivers experimentales,
/usr/src/linux/Documentation/isdn/README.HiSax.
modprobe hisax type=<codigo tarjeta> protocol=<protocolo> io=<direccion E/S> irq=<interrupcion>
Ha llegado el momento de echar mano de donde tuviera anotados (¿los anotó?) los parámetros que asignara en las secciones bios y recursos.
Suponiendo que se trate de la tarjeta Teles.SO 16.3c PnP, que al fin y al cabo, fue la causante en origen de este Como:
modprobe hisax type=14 protocol=2 io=<IO> irq=<IRQ>
Por ejemplo:
modprobe hisax type=14 protocol=2 io=0x0580 irq=11
con lo que si miramos en /var/log/messages deberíamos ver algo
como:
Jun 23 12:05:11 hal kernel: HiSax: Driver for Siemens chip set ISDN cards
Jun 23 12:05:11 hal kernel: HiSax: Version 2.8
Jun 23 12:05:11 hal kernel: HiSax: Revisions 1.15.2.8/1.10.2.5/1.10.2.3/1.30.2.6/1.8.2.5
Jun 23 12:05:11 hal kernel: HiSax: Card 1 Protocol EDSS1 Id=HiSax (0)
Jun 23 12:05:11 hal kernel: HiSax: Teles 16.3c driver Rev. 1.1.2.2
Jun 23 12:05:11 hal kernel: teles3c: defined at 0x580 IRQ 3 HZ 100
Jun 23 12:05:11 hal kernel: teles3c: resetting card
Jun 23 12:05:11 hal kernel: Teles 16.3c: IRQ 11 count 0
Jun 23 12:05:11 hal kernel: Teles 16.3c: IRQ 11 count 1
Jun 23 12:05:11 hal kernel: HiSax: DSS1 Rev. 1.16.2.3
Jun 23 12:05:11 hal kernel: HiSax: 2 channels added
Jun 23 12:05:11 hal kernel: HiSax: module installed
El tipo 14 es el que se corresponde con la Teles 16.3c PnP, el
protocolo 2 es el usado en España para las conexiones RDSI, EURO
ISDN o EDSS1. Los otros dos valores (dirección de E/S e interrupción)
dependerán de su configuración particular, que anotó en su momento,
¿verdad?
Dependiendo del driver, este puede que se cargue aun con parámetros erróneos, si bien no es el caso del HiSax, que rehusará a hacerlo.
Si sospechamos que pese a haberse cargado (repetimos, no en el caso del HiSax) hay por ejemplo conflictos de IRQ, o no está usando la que le hemos asignado, un indicador claro de esto es que al hacer un
cat /proc/interrupts
0: 9719062 timer
1: 342221 keyboard
2: 0 cascade
4: 495989 + serial
10: 1591809 ICN
12: 681 eth0
13: 1 math error
en un sistema con una tarjeta ICN la línea correspondiente a la irq usada
por el controlador contase con 0 interrupciones de contador (segunda
columna). Esto aplica para todos los dispositivos; si la línea
10: 1591809 ICN
fuese
10: 0 ICN
sería un claro síntoma de que el driver ICN no está usando dicha
interrupción, casi seguro por fallo de configuración. Tan sólo por cargar
correctamente, debe de poner el contador a 1 al menos.
Llegados a este punto, respire profundamente y siéntase todo un gurú
Linuxero... ;-) Ya casi está listo; para no tener que hacerlo en un
futuro a mano, y suponiendo que tiene las modutils correctamente
instaladas, edite o cree su /etc/conf.modules o
/etc/modules.conf e inserte las siguientes líneas, (suponiendo
que use por ejemplo una Teles 16.3 NO PnP/ con la IRQ 10 y la io 0x180 :
alias isdn hisax
options hisax type=3 protocol=2 io=0x180 irq=10
ejecute depmod -a para computar/actualizar las dependencias entre
módulos; de ahora en adelante un modprobe hisax bastará.