ORDENATA DE LA GARRAXI "KRISTON-SERVIDOREA": HARDWARE: - 2 procesadores Pentium III Katmai a 547 Mhz. En el boot del kernel 2.4.27 de Debian dice lo siguiente (puede ser util para recompilar el kernel): - Intel MultiProcessor Specification v1.4 (Virtual Wire compatibility mode). - Fast FPU save and restore. - Unmasked SIMD FPU exception support. - 'hlt' instruction. - popad bug - ExtINT on CPU#0. - Memoria RAM: Tiene 4 ranuras de memoria. Viene con 500 Mb de RAM, en 2 modulos de 250 Mb. - Placa base: Intel L440GX server board. BIOS L440GX + Phoenix BIOS del 1/6/00. - USB (tb. controladora de IDE) de la placa: Intel PIIX4 (82378AB/EB/MB). USB-FIREWIRE Belkin PCI: - USB 1.1: ALi Corporation USB 1.1 Controller (modulo ohci) - USB 2.0: ALi Corporation USB 2.0 Controller (modulo ehci) - FireWire (IEEE 1394): ALi Corporation M5253 P1394 OHCI 1.1 Controller (modulos ieee1394 y ohci1394) - Tarjeta grafica Cirrus Logic GD5489 (rev 35). Servidor X 4.x elejido por knoppix: cirrus. Knopix dice que es una CL GD5480. Servidor X 3.3.6 xserver-svga. - Agpgart: Intel 440 GX (Tambien la controladora PCI de la placa base). - Monitor SAMTRON 56E, Serial No: HSCW404620 (segun log de X4.3). Las X4.3 le asignan: Refresco horizontal 30-55 Khz, Refresco vertical 50-120 Hz. Resolucion que pilla 800x600. - Tarjeta de red Intel 82557/8/9 Ethernet Pro 100 (IRQ 21) - Tarjetas de sonido que le pongo: * CREATIVE VIBRA 16X ISA PNP (ISA): Modulo sb (OSS) y snd_sb16 (ALSA). El kernel la detecta sin problemas (tanto el de la knoppix, como el que compilo con soporte para ella, y con el de Debian, aunque una vez este ha fallado). No hay que tocar nada en la BIOS para detectarla (bien!!!, lo habia intentado para reconocerla en winNT y no lo habia conseguido). El kernel al arrancar le asigna los parametros: i/o=0x220, irq=5, dma=1, 3 * Ensoniq ES1371 [AudioPCI-97] Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128. Modulo ALSA snd-ens1371. He probado tambien una Hercules Muse LT, pero no la reconocia ni linux ni XP. La documentacion dice que para instalarla hay que quitar las otras tarjetas de sonido, asi que lo he dejado. - SCSI interno: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA driver. Adaptec AIC7846/97 Ultra2 SCSI adapter. IRQ 19. - Unidades de disco (SCSI + IDE): - SCSI0: 8,754 Gb - QUANTUM Model: ATLAS IV 9 WLS Rev: 0909 (sda) - SCSI1: 17,516 Gb - QUANTUM Model: ATLAS IV 18 WLS Rev: 0808 (sdb) - SCSI2: 8,754 Gb - QUANTUM Model: ATLAS IV 9 WLS Rev: 0909 (sdc) (pillado) - IDE primary master: CDROM ASUS CD-S500/A (hda) - IDE primary slave: - - IDE secundary master: HD 190 Gb MAXTOR 6L200P0 (para musica) (hdc) - IDE secundary slave: - Falta por añadir grabadora de CD SCSI: Yamaha CRW8424S-NB (problemas de conexion de cables, diferente ancho). CONFIGURACION DEL HARDWARE: Como primer paso le pongo el disco duro del anterior ordenata de la garraxi (PC-TXIKIA), para ir adaptandolo al nuevo entorno y despues pasarlo al disco SCSI mas pequeño (8,7 Gb). Para que valla bien tengo que cambiar el CD al IDE secundario y poner el disco en el IDE primario (/dev/hda). SCSI: - Kernels Debian: Pruebo a montar las particiones que existen en los discos SCSI. En realidad estan particionados asi: SCSI0 (sda) 8,754 Gb: sda1: particion primaria, NTFS normal, 4194,90 Mb. sda5: particion logica, NTFS volume set, 4984,52 Mb. SCSI1 (sdb) 17,516 Gb: sdb1: particion primaria, NTFS volume set, 18367,06 Mb. Las particiones 'NTFS volume set' corresponden a lo que desde WinNT se veia como una sola particion que estaba "montada" entre los dos discos. La particion sda1 se monta como root pero sin problemas con el comando 'mount -t ntfs /dev/sda1 new_directory' por ejemplo, pero solo permite acceso como root al dir. Se consigue que se monte normalmente en el inicio con una entrada en fstab asi: /dev/sda1 /home/garraxi/new_directory ntfs rw,user,auto,uid=1000,gid=1000 0 0 Asi se consigue que la particion este accesible al usuario garraxi (los archivos y dirs le pertenecen). Pero son de solo lectura (a pesar de estar montados con la opcion rw) debido a que el driver NTFS de la Sarge parece que es de solo lectura todavia (drivers de lectura y escritura nativos para linux hay solo desde hace poco?). Pruebo a formatear el SCSI1 (sdb) para instalar en el una copia exacta del disco de la Garraxi hda. El proceso funciona sin problemas, pero no botea incluso despues de habar grabado el grub en el MBR del sdb. Los problemas son: - kernel 2.4.20-ck compilado por mi, no tiene soporte para SCSI. - kernels 2.4.27 y 2.6.8 de Debian, no arrancan porque estan configurados para arrancar desde un disco IDE. El asunto parece ser que 1. los kernel Debian tienen el soporte para discos SCSI y IDE compilados como modulos (comprobado en /boot/config-2.4.27-2-386); y entonces 2. al arrancar montan primero un ramdisk con un entorno adecuado al hardware que fue configurado durante la instalacion del sistema (esto es lo que hay en el archivo /boot/initrd.img-2.4.27-2-386), que arranca el kernel del disco y le mete los modulos adecuados (o algo asi). Al haber instalado el sistema sobre un equipo con solo IDE ahora no hay soporte en el ramdisk para botear desde SCSI. He probado a cambiar esta configuracion con base-config (el programa que configura la base de Debian en la instalacion, pero no toca los primeros pasos de deteccion de hardware y tal) y configure-debian (programa de consola que lista todos los paquetes que se pueden dpkg-reconfigure'ar, pero hay no esta el kernel). Mirando info sobre initrd, veo que hay manuales para initrd(4) (info sobre como funciona el ramdisk inicial) y update-initrd(8) (como recrear el initrd para adaptarlo al hardware que detecta discover(8)). Con este ultimo se recrearia el initrd usando los modulos que estan instalados actualmente, correspondientes a kernel-version (update-initrd handles the creation of just such an initrd, using the currently installed modules corresponding to kernel-version): update-initrd kernel-version update-initrd takes a single argument - the version number of the (installed) kernel for which to generate an initrd image. Asi, intento recrear el initrd para el kernel 2.4.27 de Debian, con el comando 'update-initrd 2.4.27-2-386', de manera que inicia la recreacion, pero da un error: 'cp: no se puede efectuar `stat' sobre «/bin/ash»: No existe el fichero o el directorio'. Probablemente se deba a que esta intentando recrear el initrd con los modulos y tal del kernel actualmente en uso, que es el del diskete de arranque, dado que no puedo reiniciar el ordenata de otra manera con el disco SCSI. Pruebo a desinstalar (purgando configuraciones) y volver a instalar el paquete kernel-image-2.4.27-2-386. De esta manera se me recrea de nuevo el archvio /boot/initrd.img-2.4.27-2-386. Pero en el grub pone por defecto para montar como root a /dev/hda1. Para cambiarlo y que al añadir mas kernels te ponga otro disco como root por defecto hay que cambiar en /boot/grub/menu.lst la linea #kopt=root=/dev/hda1 por #kopt=root=/dev/sdb1 (por ejemplo), dejando el comentario inicial intacto. Asi ya arranca sin problemas el kernel 2.4.27, aunque ahora no reconoce los discos IDE (hda y hdc (cdrom)) ??. El error que da mount es: '/dev/hda1 is not a valid block device' por ejemplo (lo mismo con el CD). Finalmente el problema se debe a que por alguna razon el kernel no carga por defecto el modulo ide-detect necesario para detectar los devices IDE. Tras cargarlo la primera vez con modconf parece que ya se queda para siempre (porque se guarda en /etc/modules :-)). Despues de esto puedo instalar tambien el kernel 2.6.8 y este no da problemas con los IDE, los monta desde el principio. Asi que el truco es volver a instalar los kernel de Debian en el nuevo hardware para que se hagan cargo del cambio. Con el compilado por mi lo recompilare para dar soporte al nuevo hardware. - Kernel Mio: Intento compilar el kernel 2.4.20 con el parche de kolivas, pero da errores, parece que en la parte de multiprocesador: gcc -D__KERNEL__ -I/usr/src/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -DKBUILD_BASENAME=sched -fno-omit-frame-pointer -c -o sched.o sched.c sched.c:461:1: aviso: "/*" dentro de un comentario sched.c: En la función `set_cpus_allowed': sched.c:1465: error: structure has no member named `cpus_runnable' sched.c:1468: error: structure has no member named `processor' sched.c:1475: error: structure has no member named `cpus_runnable' sched.c: En el nivel principal: sched.c:2122: error: redefinition of `set_cpus_allowed' sched.c:1454: error: `set_cpus_allowed' previously defined here Asi que pruebo a compilar el 2.4.20 con solo el parche de supermount-ng (http://sourceforge.net/projects/supermount-ng/). Esto da el tipico problema de ide-cd.c que se arregla parcheando el /drivers/ide/ide-cd.h original, hay que cambiar ese archivo por el parcheado que sale del patch de kolivas, (que guardo en el dir /manola/problemas-memoria). Despues da otro problema con el driver SCSI de la Adaptec: make[5]: Entering directory `/usr/src/linux-2.4.20/drivers/scsi/aic7xxx' gcc -D__KERNEL__ -I/usr/src/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -DKBUILD_BASENAME=aic7xxx_osm -c -o aic7xxx_osm.o aic7xxx_osm.c aic7xxx_osm.c:420:27: falta carácter terminando " aic7xxx_osm.c:439:1: falta carácter terminando " aic7xxx_osm.c: En la función `ahc_linux_map_seg': aic7xxx_osm.c:683: aviso: la constante entera es demasiado grande para el tipo "long" Esto parece que se arregla usando el gcc-2.95, para lo que hay que correr la orden de compilar como: MAKEFLAGS="CC=gcc-2.95" make-kpkg --revision=3:2.4.20garraxi3 kernel_image Tras esto da otro error: gcc-2.95 -D__KERNEL__ -I/usr/src/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -DKBUILD_BASENAME=sd -c -o sd.o sd.c sd.c: In function `sd_init_onedisk': sd.c:823: `SDev' undeclared (first use in this function) sd.c:823: (Each undeclared identifier is reported only once sd.c:823: for each function it appears in.) Asi que decido utilizar otro nucleo que soporte supermount. El otro que tengo (aplicando patches sucesivos) es el 2.4.23 y le aplico el parche de supermount adecuado. Asi, sin hacer mas compila perfectamente con una configuracion similar a las probadas antes. El paquete es kernel-image-2.4.23_2.4.23garraxi3_i386.deb y su configuracion es kernel2.4.23-garraxi32.config. Aparentemente (primeras pruebas) funciona sin problemas. Mas adelante, con el asunto de los kernels Debian que tengo instalados (kernel-image-2.4.27-2-386 y kernel-image-2.6.8-2-386) compruebo que no tienen soporte para dos procesadores (soporte multiprocesador o smp). Asi que los desinstalo e instalo los kernels kernel-image-2.4.27-2-686-smp y kernel-image-2.6.8-2-686-smp que estan compilados con soporte multiprocesador y para Pentium III (descripcion de los paquetes: Linux kernel image for version 2.X.XX on PPro/Celeron/PII/PIII/P4 SMP). Ademas instalo el paquete irqbalance que venia como recomendaciones en los nucleos smp. Es un daemon que sirve para distribuir las interrupciones del hardware entre los procesadores en sistemas multiprocesador, de manera que se incrementaria el rendimiento. INSTALAR MAS DISCOS DUROS SCSI Mas tarde consigo otro disco duro SCSI de 9 Gb QUANTUM Model: ATLAS IV 9 WLS (igual que el que traia el server). Para ponerlo hay que seleccionar en cual 'SCSI id' ira. Como los otros discos duros son id0 e id1, a este le pongo id2. Para ello en la parte inferior del disco duro hay 2 filas de 14 pines donde se seleccionan cosas con junppers. Su pinta es la siguiente (con la indicacion que hay junto a los pines): ------------------------------------------------------ || || || || || || || || || || || || || || A3 A2 A1 A0 FO DS SE BO WP SS NW Por orden, empezando por A3, la indicacion que tienen estos pines en el propio disco duro es la siguiente: - SCSI ID(3) - SCSI ID(2) - SCSI ID(1) - SCSI ID(0) - FAULT OUT - DELAY SPIN - FORCE SE - NC - BUSY OUT - WR PROTECT - STAGGER SPIN - NO WIDE - RESERVED - TERMPWR Compruebo como estan colocados los junppers en los discos SCSI que trae el servidor y veo que: SCSI ID: 0 -> no junppers SCSO ID: 1 -> junpper en pines A0 Por lo que para seleccionar que el nuevo disco sea ID: 2, pongo un junpper en los pines A1, de manera que se identifica en el arranque como SCSI0:A:2 (id2). No se como habria que hacer para conseguir id's mayores que 5, o asi. Mas tarde coloco los 3 discos SCSI en la parte superior del ordenata, dado que el cable SCSI es largo. De esta manera los 2 discos que traia, con su sitema de ventilacion estan uno arriba y el otro abajo, y el disco SCSI que he pillado,que no tiene sistema de ventilacion en medio, de manera que recibe parte de la ventilacion de los otros dos (para ello a una de las cajas le he quitado la tapa y la he montado arriba, al reves, con la "tapa quitada" hacia abajo, la otra abajo, con el la tapa separada un poco y el "nuevo" disco atornillada a ella). El disco (sdc) asi se calienta mucho menos que antes y sirve para alojar las cuñas. Al formatearlo (en ext2, como los demas de Biltegi, con el comando mke2fs -c -v /dev/sdc1) le paso el checkeador de bloques defectuosos (-c) y no da problemas. CD-ROM: En el PC-txikia el cdrom era hdb y ahora es hda asi que en principio no funcionaba ni el tocador de cds ni el ripperx. El problema era porque: 1. /dev/cdrom es un enlace simbolico que apuntaba a /dev/hdb, lo cambio a /dev/hda 2. /dev/hda pertenecia a root:disk, mientras que hdb pertenecia a root:cdrom. Intercambio los papeles para que hda pertenezca a cdrom. 3. El usuario garraxi ya era miembro del grupo cdrom, por lo que eso no es necesario cambiarlo. PARTICIONES (tamaños aprox): -> sda: -> sda1 8,5 Gb ext3 / -> sda2 0,5 Gb swap -> sdb: -> sdb1 18 Gb ext2 /home/garraxi/Biltegi/Programas -> sdc: -> sdc1 9 Gb ext2 /home/garraxi/Biltegi/kunyas -> hdc: -> hdc1 190 Gb ext2 /home/garraxi/Biltegi/Musica TARJETAS DE SONIDO Y DE USB: -ISA SB16 VIBRA: La tarjeta de sonido ISA Creative Vibra 16X ISA PNP funciona bien como dije (con los parametros autodetectados: i/o=0x220, irq=5, dma=1, 3), cuando no hay otra tarjeta PCI pinchada. Pero cuando pruebo a pinchar una tarjeta PCI de conectores USB 2.0 (de Belkin) la de sonido ISA deja de funcionar (he probado a pincharla en varias ranuras PCI). Los "sintomas" que da la ISA son excasos, parece que arranca bien, se detecta como siempre, se cargan los modulos ALSA, los programas de tocar musica arrancan normal y no dan errores al principio, pero no sacan sonido. Al rato sox dice que no puede escribir en /dev/dsp. He probado con otros dispositivos pero es peor (no los reconoce). El problema se arregla quitando la tarjeta PCI USB Belkin. Finalmente logro que funcionen las tarjetas pci y la isa a la vez, poniendo en la BIOS que el O.S. no es plug and play (ver abajo). - USB-PCI BELKIN: Pillo una tarjeta PCI de conectores USB y firewire de Belkin. La idea es que haya buena conexion por USB en el ordenata, dado que trae un par de conectores USB de la version 1.0 (los dispositivos modernos funcionan con la 2.0 y tienen compatibilidad para la 1.1, pero no dicen nada de la 1.0). Ademas los conectores que trae estan mal colocados, muy cerca del conector de la pantalla, por lo que algunos apartatos no podran conectarse. Para que no interfiera con la tarjeta ISA SB16, que parece que da problemas de IRQ compartidas, pruebo la PCI Belkin ella sola. Finalmente el problema no ha sido de IRQ compartidas, posiblemente porque ACPI permite que las IRQ se distribuyan adecuadamente (o algo asi he leido por ahi). Con un XP que tengo en un disco duro aparte (y que puede estar mal configurado) me da muchos problemas para reconocerla: el XP se cuelga cuando trata de acceder a ella si esta pinchada en las 2 primeras ranuras (que se supone que son las nuevas y mas rapidas segun la documentacion de la placa base), y no funciona si esta en la 4º (mas lenta y antigua?). Con Linux funciona sin problemas con el nucleo 2.4.27 de Debian (posiblemente tambien en el 2.6, pero no lo he probado). Para acceder a ella (y tambien a los USB de la placa) utiliza los modulos: usb-uhci, usb-ohci (ambos para usb1), ehci-hcd (para usb2.0), ieee1394, ohci1394 (ambos para el firewire) y usb-storage cuando enchufas una memoria usb. Con el linux 2.4.23 que compile yo (version garraxi4) no funciona y es porque no tiene el modulo ehci para usb2, ni tampoco el ohci para usb1 compilados. Asi que compilo la version garraxi5 del kernel 2.4.23 añadiendo los modulos de arriba. Para ello debo activar el soporte para cosas experimentales del nucleo, dado que tanto el ehci, como todo el firewire (1394) estaban en experimentacion en el 2.4.23. Sin embargo una vez en marcha, la memoria USB probada antes funciona sin problemas. Para poder montar memorias usb como usuario normal añado la siguiente linea al /etc/fstab: /dev/sdd1 /mnt vfat rw,user,noauto,noatime,sync 0 0 De esta forma, el usb puede montarse en el dir /mnt, sin automontaje. Para ponerle automontaje con supermount, la linea queda: none /media/usb1 supermount dev=/dev/sdd1,fs=vfat,rw,user,noatime,sync 0 0 Notar que no hay que poner el 'noauto' como opcion con supermount, pues este deja de funcionar (probado). Con supermount la memoria usb parece funcionar bien, probandola con unas cuantas copias y borrados de ficheros. Comprobando las IRQ que usa la tarjeta Belkin, el gxproc informa que: Interrupts: CPU0 CPU1 20: 32513 69245 IO-APIC-level ehci_hcd 21: 0 0 IO-APIC-level usb-uhci, usb-ohci, usb-ohci 22: 2 1 IO-APIC-level ohci1394 Y no dice nada de un interrupt 5 (el tipico de la tarjeta de sonido), dado que no tengo la ISA SB16 puesta. En 'PCI devices' (advanced) dice (1º el usb integrado en placa, y mas tarde el PCI): Bus 0, device 18, function 2: USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 1). IRQ 21. Master Capable. Latency=64. I/O at 0x2060 [0x207f]. USB Controller: ALi Corporation USB 1.1 Controller (rev 3). IRQ 21. Master Capable. Latency=208. Max Lat=80. Non-prefetchable 32 bit memory at 0xf4200000 [0xf4200fff]. Bus 2, device 4, function 1: USB Controller: ALi Corporation USB 1.1 Controller (#2) (rev 3). IRQ 21. Master Capable. Latency=64. Max Lat=80. Non-prefetchable 32 bit memory at 0xf4201000 [0xf4201fff]. Bus 2, device 4, function 3: USB Controller: ALi Corporation USB 2.0 Controller (rev 1). IRQ 20. Master Capable. Latency=64. Max Lat=80. Non-prefetchable 32 bit memory at 0xf4202800 [0xf42028ff]. Bus 2, device 4, function 4: FireWire (IEEE 1394): ALi Corporation M5253 P1394 OHCI 1.1 Controller (rev 0). IRQ 22. Master Capable. Latency=64. Max Lat=3. Non-prefetchable 32 bit memory at 0xf4202000 [0xf42027ff]. Sin embargo, si pincho despues la tarjeta de sonido ISA, los USB siguen funcionando sin problemas, pero el sonido no. Para cambiar los parametros veo en /usr/share/doc/alsa-base/driver/ALSA-Configuration.txt.gz que la tarjeta permitiria los siguientes parametros: port - port # for SB DSP 4.x chip (0x220,0x240,0x260) irq - IRQ # for SB DSP 4.x chip (5,7,9,10) dma8 - 8-bit DMA # for SB DSP 4.x chip (0,1,3) dma16 - 16-bit DMA # for SB DSP 4.x chip (5,6,7) Con lo que con 'modconf' pruebo a pasar al modulo snd-sb16 combinaciones de los parametros anteriores, del tipo: port=0x220 irq=5 dma8=1 dma16=3 Tambien pruebo cambiando los modulos de ALSA por los de OSS (en los kernels de Debian 2.4 y 2.6). Pero el resultado es el mismo con ambos sistemas. Al cargar los modulos de OSS, deja en los logs indicaciones de que es la IRQ5 la que entra en conflicto (seguramente con la tarjeta PCI Belkin): sb: PnP: Found Card Named = "Creative ViBRA16X PnP", Card PnP id = CTL00F0, Device PnP id = CTL0043 Detected at: io=0x220, irq=5, dma=1, dma16=0 SB 4.16 detected OK (220) sb: Interrupt test on IRQ5 failed - Probable IRQ conflict Finalmente, tras una corta busqueda en google.groups acerca de 'belkin usb pci soundcard', con pocos resultados, pruebo una de las posibles soluciones aportadas, que es poner en la BIOS que el O.S. no sea compatible con plug'n'play ??. Misteriosamente esto hace que funcione el sonido de la ISA (con ALSA y la configuracion por defecto) y el USB Belkin a la vez, en todos los kernel !!!. Por otra parte, habiendo probado tanto usbmgr como hotplug como metodos para el control dinamico de los modulos usb, veo que es mejor hotplug. usbmgr carga directamente en el arranque los modulos necesarios para usb-storage, aunque no haya ningun aparato enchufado en el usb. Ademas, el demonio de usbmgr que esta arrancado desde el inicio consume 516 Kb de memoria, mientras que el de hotplug no consume nada. Lo bonito de usbmgr es que cuando se conecta una memoria usb, emite un pitido para indicar que esta correctamente reconocida y conectada. Mas tarde, con el ordenata auxiliar, para compilar en el kernel el soporte para enchufar memorias usb, me cuesta un tiempo. Al final el truco es darle soporte para discos SCSI = CONFIG_BLK_DEV_SD (al menos como modulo). De esta manera, los modulos (y soporte en el nucleo) para USB y SCSI que compilo son: # IDE, ATA and ATAPI Block devices: CONFIG_BLK_DEV_IDESCSI=m # SCSI support: CONFIG_SCSI=y CONFIG_BLK_DEV_SD=m CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_SG=m CONFIG_SCSI_DEBUG_QUEUES=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # USB support: CONFIG_USB=m CONFIG_USB_DEVICEFS=y CONFIG_USB_BANDWIDTH=y CONFIG_USB_EHCI_HCD=m CONFIG_USB_UHCI=m CONFIG_USB_UHCI_ALT=m CONFIG_USB_OHCI=m CONFIG_USB_AUDIO=m CONFIG_USB_STORAGE=m - TARJETAS DE SONIDO PCI: Primero pruebo con una Hercules Muse LT que pille por 20 euros nueva en PCCITY. Pero el sistema no la reconoce de ninguna manera (ni con linux ni con XP). Ademas la documentacion dice que para instalarla se debe desinstalar primero cualquier otra tarjeta de sonido que haya. Asi que decido dejarla para mi ordenata, y poner en el de la garraxi la que tengo en el mio, que esta perfectamente soportada por linux. Asi que pincho la Ensoniq ES1371. Con lspci obtengo que es reconocida por linux nada mas pincharla: Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06) Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128 Flags: bus master, slow devsel, latency 208, IRQ 23 I/O ports at 3000 [size=64] Capabilities: [dc] Power Management version 1 Sin embargo, despues de hacer muchas pruebas compruebo que no funciona en las ranuras PCI 1º y 2º, supuestamente porque estas son "mas nuevas" y quizas la tarjeta sea "mas vieja" (ver arriba). Por lo tanto, finalmente picho la Ensoniq en la ranura PCI 4º (y la Belkin en la 1º, porque esa parece funcionar igual en cualquiera). Ahora, probando con el kernel 2.4.27 de Debian (el que tiene todos los modulos de ALSA) y la configuracion creada por 'alsaconf' no consigo mas que funcione o una tarjeta o la otra. Esto es porque, segun /usr/share/doc/alsa-base/README.Debian.gz, ese programilla solo sirve para configurar una sola tarjeta de sonido. Tambien dice lo que hay que hacer para configurar es editar el archivo /etc/modutils/sound, para poner lo siguiente: alias snd-card-0 snd-ens1371 options snd-ens1371 index=0 alias snd-card-1 snd-sb16 options snd-sb16 index=1 Donde decimos que la tarjeta PCI Ensoniq es la primera y la ISA SB16 es la 2º, ademas de indicarle los modulso de ALSA que tiene que cargar para cada una. De esta manera, /dev/dsp0 sera el dispositivo OSS (emulado por ALSA) que corresponde a la 1º (Ensoniq) y /dev/dsp1 el que corresponde a la 2º (ISA SB16). Sera a traves de estos dispositivos que configuraremos una tarjeta u otra para emitir o grabar sonido. Ademas, para que ambas tarjetas se inicialicen en el arranque y no haya problemas, al menos con el kernel 2.4.27 ha sido necesario meter los modulos snd-ens1371 y snd-sb16 (en ese orden, porsia) en /etc/modules. Tambien realizo pruebas de audicion caseras para ver cual de las 2 tarjetas es mejor, de manera que trabaje para emitir sonido (la tarea principal de la radio). Mi primera impresion es que la Ensoniq (que es mas reciente) es mejor que la SB16, mas que nada porque trabaja mejor con los stereos y parece dar un sonido menos "plano". De esta manera, dejo la Ensoniq como 1º tarjeta, dado que prefiero que la que emita sonido mantenga el dispositivo /dev/dsp0 (=/dev/dsp), el predeterminado por el sistema, de manera que cualquier programa que queramos utilizar para emitir sonido la encuentre. Para grabar estara la SB16, y como eso es menos frecuente, ya configurare los programas adecuados para utilizar /dev/dsp1. Otro condicionante tambien es el cable del CD que se conecta con la tarjeta, que llega mejor a la Ensoniq que a la SB16 (ISA, esta abajo del todo). - Kernel 2.4.23 con excesiva informacion de debug. Para hacer todas las pruebas anteriores, porsiacaso compile los kernels 2.4.23 con las siguientes opciones de debug activadas: CONFIG_SCSI_DEBUG_QUEUES=y CONFIG_AIC7XXX_DEBUG_ENABLE=y CONFIG_USB_DEBUG=y CONFIG_USB_STORAGE_DEBUG=y De esta manera se llenan los logs (/var/log/syslog y /var/log/kernelog) de exesiva informacion, sobre todo cuando se mete una memoria USB (usb-storage). Asi que compilo el kernel 2.4.23 garraxi6 sin la informacion de debug indicada, a la vez que los modulos de ALSA para la nueva tarjeta Ensoniq (mas la sb16).