Luis Angel Cofiño

 

El software

Este ordenador viene preinstalado con Microsoft Windows XP Home Edition. Puaj. Para comprobar la compatibilidad con Linux reboté la máquina con un CD de Knoppix 3.3. El resultado me sorprende incluso a mí, que ya estoy acostumbrado a las excelencias de Knoppix: reconoce correctamente gran parte del hardware del ordenador, incluida la tarjeta de red. No reconoce el módem ni el chip WiFi, así que eso requerirá un poco más de trabajo. Pero en cambio, la pantalla funciona perfecta, así como el disco duro, la tarjeta de sonido la unidad de DVD/CDRW, y muchas más cosas. Todo lo esencial, en suma, para trabajar con el ordenador en Linux cómodamente desde el primer instante. :-)

Vale, ya estuvo bien de tonterías. Encendemos el ordenador y nos arranca Windows XP, claro. Ahora metemos el CD de Knoppix 3.3 y rebotamos. Mientras Windows se va, le despedimos con la mano.

Arranca Linux. Nos vamos al simbolito de Knoppix y abrimos una consola root. Ahí, inmisericordes, tecleamos "knoppix-installer". Arranca el nuevo instalador, que sustituye al viejo knx-hdinstall. Contestamos un par de chorradas y entonces sale la chicha, o sea, el qtparted, (el programa de particionado del disco duro, vaya). Le digo que se vaya a /dev/hda y agarre la primera y única partición. Le digo que cambie el tamaño y la reduzca a 8 Gb, que es todo lo que se merece el Windows XP Home. Y soy generoso...

Qtparted lo intenta y se para. Me dice que la unidad NTFS está fragmentada y hay trozos por encima de ese tamaño, con lo que o la defragmento o el tamaño mínimo son unos 36 Gb. La madre que... ¿cómo que está fragmentada?. ¡Si el p*t* windows me ha venido directamente de fábrica!.

Reboto el ordenador y vuelvo a arrancar con Windows XP. La sonrisa de conmiseración con la que lo despedí se vuelve un tanto salvaje.

Arranco el defragmentador del Windows. Veo que efectivamente, Linux NO me ha mentido. Hay un inmenso bloque de archivos marcados en un precioso color verde que estan situados en el puñetero medio del disco duro. ¿Pero qué demonios hacen ahí?. ¡Ahh... vete tu a saber... ! ¿tal vez evitar que los borregos instalen Linux?. Le digo que defragmente, y entonces descubro que el color verde significa "ficheros de sistema... inamovibles". La sonrisa se vuelve carcajada.

Lo medito a fondo durante unos quince segundos. El ordenador es nuevo. No tengo nada metido, ni un triste archivo personal... todo lo que hay es lo que vino de fábrica. Y el Windows XP Home de las narices no me gusta ni un poquito. Si fuera el Professional, todavía. Total, que si necesitaba una excusa, Microsoft me la ha dado perfecta.

Meto el CD de Knoppix y arranco de nuevo con Linux. Abro una consola de root. Tecleo: "fdisk /dev/hda". Borro la partición de Windows, entera, mientras saludo de nuevo con la mano. Creo una partición primaria de 8 Gb para Windows, pobrecito. Creo otra primaria de 128 Mb para /boot, otra primaria de 128 Mb para almacenar kernels, ahora que le he cogido gusto a compilarlos. Luego creo una partición extendida y, dentro de ella, una partición lógica de 10 Gb para Knoppix, otra de 512 Mb para swap, otra de 10 Gb para datos, otra de 10 Gb para Fedora Core 1, otra de 10 Gb para unidades VMWare y ficheros temporales de la grabadora, y lo que queda (unos 8,5 Gb más) para lo que se tercie, que de momento no la necesito. ;-)

Termino con fdisk y arranco knoppix-installer. Las preguntas que me hace el programa instalador son para niños, pero no me permiten muchas opciones. Lo instala en una única partición (con lo que no me permite decirle que quiero meter /boot en hda2) Cuando pregunta si quiero el modo "Debian" o el modo "Knoppix" contesto que Debian. El modo Knoppix debe ser que lo graba en disco duro, pero en una imagen comprimida, como si fuera el CD, con lo que habrá muchas limitaciones de espacio. Y eso es todo. El resto de las preguntas son chorradas.

Reboto el ordenador, saco el CD cuando me lo pide y... primera sorpresa, aunque en realidad es bastante lógico y debería haberlo supuesto. La BIOS de esta máquina es muy nueva con lo que no existe el límite de los 1024 cilindros. Lilo puede arrancar Knoppix esté donde esté, sin límites. Así que no voy a necesitar la partición /boot en hda2, después de todo.

Hago un par de configuraciones testimoniales en el prompt, me paseo un poco y cambio enseguida, que es día de guerra y estoy inspirado. Además de Knoppix, vamos a por una distribución más standard para el trabajo normal: Fedora Core 1, que tengo ganas de probarla.

Metemos el CD de arranque de Fedora Core 1 (tengo los tres). Rebotamos e iniciamos la instalación. Las preguntas ya no son tan infantiles, pero para un linuxero serían francamente sencillas y para un güindosero, razonablemente asequibles. La instalación es muuuucho más larga pero allá va. Le echo un buen vistazo al Fedora. El aspecto es precioso, con un look verdaderamente cuidado. Pero en la distribución faltan algunos paquetes que yo, personalmente, considero esenciales, como LyX (¡no tiene Lyx, por Dios!) o como Dosemu. Y empiezo a echar mucho de menos mi querido apt-get. Pero mucho, mucho.

Afortunadamente, existe un apt-get para Fedora. Si lo instalas, luego modifica tu /etc/apt/sources.list para incluir los siguiente servidores:

	# List of available apt repositories available from ayo.freshrpms.net.
	# This file should contain uncommented default suitable for your system.
	#
	# See http://ayo.freshrpms.net/ for a list of other repositories.
	#
	# $Id: sources.list.i386,v 1.2 2003/11/06 21:05:23 dude Exp $

	# Fedora Linux 1
	rpm http://ayo.freshrpms.net fedora/linux/1/i386 core updates freshrpms
	rpm http://download.fedora.us/fedora fedora/1/i386 os updates stable
	rpm-src http://download.fedora.us/fedora fedora/1/i386 os updates stable

	rpm http://apt.ling.li fedora/1/i586 li unstable

	rpm http://apt.sw.be redhat/fc1/en/i386 dag

Una vez hecho esto, haz un "apt-get update" seguido de "apt-cache search lyx" y verás aparecer a LyX, inexplicablemente excluido de la distribución oficial.

En cuanto a Dosemu, puedes instalar los binarios que encontraras en su home. Funcionan correctamente, pero leete el README para las instrucciones y recuerda que tienes que bajarte DOS paquetes: el binario y el freedos.

Fedora Core me ha dejado muy buen sabor de boca, así que configuro lilo para que sea éste el sistema operativo por defecto.

Pero queda lo más importante: los datos. Reboto a Knoppix, formateo la partición hda7, configuro la red con Claudia (mi otro ordenador, el de sobremesa), y empiezo a transferir como 2 Gb de datos en total. Esa partición, hda7, se montará a partir de ahora como "/datos" y se exportará mediante el sistema "nfs" hacia claudia, de tal forma que se mantendrá constantemente sincronizada. Si no sabes cómo lo hago, deberías echarle un vistazo a otra sección, que es donde te lo pongo con un poco más de detalle. Cuando acaba, y con la red aún levantada, lo dejo toda la noche funcionando con un "apt-get update && apt-get dist-upgrade". Esto convierte la Knoppix en una Debian Testing completa, pero necesita bajarse unos 400 Mb desde distintos servidores, así que lleva algo de tiempo. Afortunadamente, en desatendido ;-), lo que aprovecho para ir a contarselo todo con detalle a María, que a estas alturas está ya bastante harta de mí y del ordenador de las narices.

Por cierto, si haces el "apt-get dist-upgrade" en Knoppix, prepárate a tener un montón de problemas. Entre otras cosas, a mí me hizo crash la configuración gráfica, pero son gajes del oficio... ¡Eh!. De la palabra "Testing", ¿qué parte es la que no entiendes?. ;-) ;-P

Al final le toca el turno a Windows. He decidido que no voy a instalar Windows XP Home ni jarto güisqui. En cambio, tengo por ahí un Windows 2000 que me vino con otro ordenador, hace ya algo de tiempo. Y a Windows 2000 le tengo un poco más de respeto... sin contar conque uno de los CD que me vinieron con el portatil incluye drivers para Win2000, mira tú.

Arranco el ordenador, meto el CD con Windows 2000 profesional y lo instalo en su fantástica partición (ejem... de 8 Gb). Instalo todos los drivers y compruebo que todo el hardware esté funcionando bien.

Reboto el ordenador y me despido de Windows 2000. Le tengo más respeto que al XP Home, pero no estoy tonto: sé perfectamente que muy, muy poquitas veces más volveré a verlo.

 

El hardware

¿Cómo está funcionando el hardware bajo Linux, así, recién instalado?. Bueno, pues vayamos por partes. La tarjeta gráfica y la pantalla funcionan perfectas, a 1024x768 con aceleración por hardware y AGP. El disco duro va bastante bien: estoy cazando velocidades de transferencia a 25 Mb/segundo. El Combo DVD/CD-RW lee y graba sin ningún problema. Además, el boot activa también todas las funciones APIC, lo que se nota en una mejora del rendimiento. En cambio no activa ACPI, porque el kernel no lo soporta, al menos en Knoppix (sí en Fedora). Activarlo también en Knoppix requerirá un kernel nuevo, claro. Los puertos serie y paralelo están activos, así como el PCMCIA. Con Fedora también está activo y funcionando el FireWire, pero no en Knoppix. En cuanto al chip Wifi tiene soporte completo por parte del fabricante (Intel), e incluido de serie en la mayoria de los sistemas Linux, como Gentoo.

El modem integrado Smartlink 56 K que viene incluido no funciona al principio. En cambio, la tarjeta ethernet integrada Realtek sí es reconocida y configurada automáticamente. Funciona y lo hace muy bien, a la máxima velocidad disponible (100 Mbps) y en full-duplex. Mejor, imposible. Lo mismo ocurre con todos los puertos USB y con los chips de sonido AC'97. No puedo decir lo mismo del lector Winbond SD, que no parece ser reconocido. Y tampoco va el puerto de infrarrojos.

Es curiosa, la batería. Linux cree que está conectado a la red y que no existe. Sin embargo, la batería funciona y el led cambia de color de acuerdo con la carga, aunque Linux no se de cuenta de nada.

Bien, esa es la situación del portátil con los sistemas operativos recién instalados y sin configurar, tal y como se instalan por defecto Knoppix y Fedora Core 1. Pero, naturalmente, no lo vamos a dejar así, ¿verdad?. ;-)

 

Soporte del hardware en Linux (una vez configurado adecuadamente)

 

Tarjeta gráfica: ATI Mobility Radeon 9000

Tanto Knoppix como Fedora Core 1 la configuran correctamente en el arranque y por defecto. Funciona desde el primer momento con aceleración hardware y AGP. ¿Qué más quieres?. El kernel informa de ella así (con el comando "dmesg"):

	Linux agpgart interface v0.99 (c) Jeff Hartmann
	agpgart: Maximum main memory to use for agp memory: 439M
	agpgart: Detected Intel(R) 855PM chipset
	agpgart: AGP aperture is 64M @ 0xb0000000
	[drm] AGP 0.99 Aperture @ 0xb0000000 64MB
	[drm] Initialized radeon 1.7.0 20020828 on minor 0
	[drm] AGP 0.99 Aperture @ 0xb0000000 64MB
	[drm] Initialized i810 1.2.1 20020211 on minor 1

 

Disco duro: Fujitsu MHT2060AT SP

Es reconocido también de forma automática, y la configuración hdparm que adopta por defecto es la mejor que he conseguido haciendo pruebas. El kernel informa de esta manera:

	ide: Assuming 33MHz bus speed for PIO modes; override with idebus=xx
	ICH4: IDE controller at PCI slot 00:1f.1
	PCI: Enabling device 00:1f.1 (0005 -> 0007)
	ICH4: chipset revision 3
	ICH4: not 100% native mode: will probe irqs later
		ide0: BM-DMA at 0x1100-0x1107, BIOS settings: hda:DMA, hdb:pio
		ide1: BM-DMA at 0x1108-0x110f, BIOS settings: hdc:DMA, hdd:pio
	hda: FUJITSU MHT2060AT SP, ATA DISK drive
	blk: queue c0415fc0, I/O limit 4095Mb (mask 0xffffffff)
	ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
	ide1 at 0x170-0x177,0x376 on irq 15
	hda: attached ide-disk driver.
	hda: host protected area => 1
	hda: 117210240 sectors w/8192KiB Cache, CHS=7296/255/63, UDMA(100)

 

DVD/CD-RW: Toshiba SD-R6112

El combo es reconocido en el arranque, de forma automática y por defecto. Funciona tanto en modo lectura (CD/DVD) como en grabación (CDR-CDRW). El kernel informa:

	hdc: TOSHIBA DVD-ROM SD-R6112, ATAPI CD/DVD-ROM drive
	SCSI subsystem driver Revision: 1.00
	hdc: attached ide-scsi driver.
	scsi0 : SCSI host adapter emulation for IDE ATAPI devices
		Vendor: TOSHIBA   Model: DVD-ROM SD-R6112  Rev: 1031
		Type:   CD-ROM                             ANSI SCSI revision: 02
	Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
	sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
	Uniform CD-ROM driver Revision: 3.12

 

Gestión de energía: APM, ACPI, APIC.

La chicha empieza aquí. El kernel reconoce APIC y lo activa correctamente, pero Knoppix espera APM y el ordenador no lo ofrece. Esto causará problemas, principalmente con el manejo de la batería. Fedora Core 1, en cambio, pregunta por ACPI (y si no lo hay, entonces busca APM en segundo lugar). Por eso, con Fedora funciona ACPI sin problemas. Aún así la batería no va correctamente, quizás porque falta una de las opciones.

En cualquier caso, el kernel informa de la gestión de recursos así (pongo la salida de Fedora, no la de Knoppix, que sería mucho más triste):

	ACPI: have wakeup address 0xc0001000
	On node 0 totalpages: 131056
	zone(0): 4096 pages.
	zone(1): 126960 pages.
	zone(2): 0 pages.
	ACPI: RSDP (v000 OID_00                                    ) @ 0x000e6010
	ACPI: RSDT (v001 INSYDE RSDT_000 0x00000001 _CSI 0x00010101) @ 0x1fffb880
	ACPI: FADT (v001 COMAPL CL20_000 0x00000100 _CSI 0x00010101) @ 0x1ffffb00
	ACPI: BOOT (v001 INSYDE SYS_BOOT 0x00000100 _CSI 0x00010101) @ 0x1ffffb90
	ACPI: DBGP (v001 INSYDE DBGP_000 0x00000100 _CSI 0x00010101) @ 0x1ffffbc0
	ACPI: SSDT (v001 INSYDE   GV3Ref 0x00002000 INTL 0x20021002) @ 0x1fffb8c0
	ACPI: DSDT (v001 INSYDE   Canyon 0x00001004 INTL 0x02002036) @ 0x00000000
	Local APIC disabled by BIOS -- reenabling.
	Found and enabled local APIC!
	Initializing CPU#0
	ACPI: Subsystem revision 20031002
	PCI: PCI BIOS revision 2.10 entry at 0xe9c24, last bus=2
	PCI: Using configuration type 1
	ACPI: IRQ9 SCI: Edge set to Level Trigger.
	ACPI: Interpreter enabled
	ACPI: Using PIC for interrupt routing
	ACPI: System [ACPI] (supports S0 S1 S3 S4bios S4 S5)
	ACPI: PCI Root Bridge [PCI0] (00:00)
	PCI: Probing PCI hardware (bus 00)
	PCI: Ignoring BAR0-3 of IDE controller 00:1f.1
	Transparent bridge - Intel Corp. 82801BAM/CAM PCI Bridge
	ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
	ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT]
	ACPI: PCI Interrupt Link [LNKA] (IRQs 5 7 9 *10 11)
	ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7 9 10 *11)
	ACPI: PCI Interrupt Link [LNKC] (IRQs 5 7 9 10 *11)
	ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11)
	ACPI: PCI Interrupt Link [LNKE] (IRQs 5 7 9 10 11 14 15)
	ACPI: PCI Interrupt Link [LNKF] (IRQs 5 7 9 10 11)
	ACPI: PCI Interrupt Link [LNKG] (IRQs 5 7 9 10 11 14 15)
	ACPI: PCI Interrupt Link [LNKH] (IRQs 5 7 9 10 *11)
	ACPI: Embedded Controller [EC0] (gpe 28)
	PCI: Probing PCI hardware
	ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
	ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
	ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
	ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
	ACPI: AC Adapter [AC] (on-line)
	ACPI: Battery Slot [BAT0] (battery present)
	ACPI: Power Button (FF) [PWRF]
	ACPI: Sleep Button (CM) [SLPB]
	ACPI: Lid Switch [LID]
	ACPI: Processor [CPU0] (supp C1 C2 C3, 5 perf & 8 throttling states)

Bien, ¿qué puedo decir?. Cuando un kernel te suelta esto, no hay duda alguna de que ha reconocido el hardware, ¿verdad?.

 

Batería

La autonomía nominal de esta batería es de 3 horas a potencia máxima. Pero una de las virtudes de los ordenadores Centrino es que pueden ahorrar mucha energía gracias a los estados throttle y al cambio dinámico de la velocidad del procesador, lo que permite aumentar la autonomía hasta las cinco horas.

El control de la batería está íntimamente ligado a ACPI. Esto hace que Knoppix 3.4 no la reconozca y crea que el ordenador está constantemente conectado a red, como si fuera uno de sobremesa. Los de Fedora reconocen que hay una batería, pero dicen que está descargada.

No podrás solucionar esto salvo que compiles un kernel a medida. Y yo de tí lo haría sin dudarlo, porque para hacer funcionar varias cosas de tu ordenador, como por ejemplo los infrarrojos, tendrás que compilar de todas formas. Si nunca has compilado un kernel y te asusta, te diré que es mucho más fácil de lo que piensas. Hay muchos sitios de Internet donde se explica cómo hacerlo. Yo mismo te lo cuento en otra sección, así que vete para allá, practica, y cuando lo tengas dominado vuelve aquí.

¿Ya?. Bueno, pues configura tu kernel. Yo usé primero un 2.4.24 (y es lo que describo aquí), aunque luego me pasé miserablemente a la serie 2.6.x. Suelo utilizar "make menuconfig", pero tú mismo. Para lo que nos interesa ahora, en el menú "General Setup", activa la opción "Power management support", desactiva "Advanced Power Management BIOS support" y entra en "ACPI support". Dentro de ACPI, activa "AC adapter", "Battery", "button", "fan", "processor" y "thermal zone". Luego recompila e instálalo.

Ya está. Cuando arranques con este kernel, reconocerá la batería y los applets mostrarán la cantidad de energía disponible. Eso sí, el applet de KDE será incapaz de extrapolar el tiempo que falta, lo que es bastante molesto. Parece un problema del applet, no del portátil. El applet de Gnome funciona perfectamente. No borres ni las fuentes ni la configuración de este kernel, y no hagas un "make mrproper". Lo necesitarás dentro de muy poco. ;-)

 

Puertos serie y paralelo

Reconocidos en el arranque sin problemas, con los kernels originales de Knoppix y Fedora (para esto no hace falta recompilar). El kernel informa:

	parport0: PC-style at 0x378 [PCSPP,TRISTATE,EPP]
	pty: 256 Unix98 ptys configured
	Serial driver 5.05c with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
	ttyS01 at 0x02f8 (irq = 3) is a 16550A
	lp0: using parport0 (polling).
	lp0: console ready

 

Puertos USB

Reconocidos en el arranque. Sin problemas. El kernel dice:

	usb.c: registered new driver usbdevfs
	usb.c: registered new driver hub
	usb-uhci.c: $Revision: 1.275 $ time 15:50:32 Oct 29 2003
	usb-uhci.c: High bandwidth mode enabled
	PCI: Found IRQ 10 for device 00:1d.0
	PCI: Sharing IRQ 10 with 01:00.0
	PCI: Setting latency timer of device 00:1d.0 to 64
	usb-uhci.c: USB UHCI at I/O 0x1200, IRQ 10
	usb-uhci.c: Detected 2 ports
	usb.c: new USB bus registered, assigned bus number 1
	hub.c: USB hub found
	hub.c: 2 ports detected
	PCI: Found IRQ 11 for device 00:1d.1
	PCI: Sharing IRQ 11 with 02:01.0
	PCI: Setting latency timer of device 00:1d.1 to 64
	usb-uhci.c: USB UHCI at I/O 0x1600, IRQ 11
	usb-uhci.c: Detected 2 ports
	usb.c: new USB bus registered, assigned bus number 2
	hub.c: USB hub found
	hub.c: 2 ports detected
	PCI: Found IRQ 11 for device 00:1d.2
	PCI: Sharing IRQ 11 with 00:1f.1
	PCI: Sharing IRQ 11 with 02:02.0
	PCI: Sharing IRQ 11 with 02:03.0
	PCI: Setting latency timer of device 00:1d.2 to 64
	usb-uhci.c: USB UHCI at I/O 0x1700, IRQ 11
	usb-uhci.c: Detected 2 ports
	usb.c: new USB bus registered, assigned bus number 3
	hub.c: USB hub found
	hub.c: 2 ports detected
	usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
	PCI: Found IRQ 11 for device 00:1d.7
	PCI: Setting latency timer of device 00:1d.7 to 64
	ehci_hcd 00:1d.7: Intel Corp. 82801DB USB2
	ehci_hcd 00:1d.7: irq 11, pci mem e4c2f000
	usb.c: new USB bus registered, assigned bus number 4
	ehci_hcd 00:1d.7: enabled 64bit PCI DMA
	PCI: cache line size of 32 is not supported by device 00:1d.7
	ehci_hcd 00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2003-Jun-19/2.4
	hub.c: USB hub found
	hub.c: 6 ports detected
	usb.c: registered new driver hiddev
	usb.c: registered new driver hid
	hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
	hid-core.c: USB HID support drivers

Y a eso, uno le dice "amén".

 

Puerto PCMCIA

Lo mismo. Reconocido en el arranque sin problemas. El kernel:

	Linux Kernel Card Services 3.1.22
	options:  [pci] [cardbus] [pm]
	PCI: Found IRQ 11 for device 02:03.0
	PCI: Sharing IRQ 11 with 00:1d.2
	PCI: Sharing IRQ 11 with 00:1f.1
	PCI: Sharing IRQ 11 with 02:02.0
	Yenta IRQ list 0200, PCI irq11
	Socket status: 30000006
	cs: IO port probe 0x0c00-0x0cff: clean.
	cs: IO port probe 0x0100-0x04ff: excluding 0x230-0x237 0x300-0x30f
	cs: IO port probe 0x0a00-0x0aff: clean.

 

Tarjeta Ethernet: Fast Ethernet Realtek RTL8139

Reconocida en el kernel automáticamente. La salida de dmesg dice:

	8139too Fast Ethernet driver 0.9.26
	PCI: Found IRQ 11 for device 02:01.0
	PCI: Sharing IRQ 11 with 00:1d.1
	divert: allocating divert_blk for eth0
	eth0: RealTek RTL8139 Fast Ethernet at 0xe4d09000, 00:02:3f:0f:9c:ed, IRQ 11
	eth0:  Identified 8139 chip type 'RTL-8100B/8139D'
	divert: freeing divert_blk for eth0
	ip_tables: (C) 2000-2002 Netfilter core team
	8139too Fast Ethernet driver 0.9.26
	PCI: Found IRQ 11 for device 02:01.0
	PCI: Sharing IRQ 11 with 00:1d.1
	divert: allocating divert_blk for eth0
	eth0: RealTek RTL8139 Fast Ethernet at 0xe4d09000, 00:02:3f:0f:9c:ed, IRQ 11
	eth0:  Identified 8139 chip type 'RTL-8100B/8139D'
	ip_tables: (C) 2000-2002 Netfilter core team
	eth0: link down

Lo de "link down" significa que la red está caída. Naturalmente, tendrás que configurarla a tu gusto y luego levantarla, pero eso es muy fácil y Linux tiene herramientas de sobra para hacerlo cómodamente. Lo importante, y lo que nos interesa aquí, es que el hardware funciona correctamente.

 

Wireless: Intel Pro/Wireless LAN 802.11b 2100 3B Mini PCI

Hay dos formas de manejar el Wireless con Linux: emulando el driver mediante NDisWrapper, o instalando un driver nativo.

Emulando el driver mediante NDisWrapper

Si decides instalar NDisWrapper es que está loco de remate. Hoy en día existe excelente soporte WiFi nativo para Linux. Te pongo lo de NDisWrapper a modo de curiosidad histórica, pero hazme caso y vete corriendo a la sección sobre el driver nativo ipw2100.

Al principio no existian drivers nativos para linux para este chip típico de la tecnología Centrino. La culpa era, naturalmente, de Intel que no programaba el driver ni cedía las especificaciones técnicas a la comunidad linux. A base de protestas y repetidas peticiones de linuxeros, Intel ha terminado por ceder y ha desarrollado un driver con licencia abierta, lo que permite la colaboración de los chicos del Software Libre. Vale, les ha costado tiempo pero al final se han dado cuenta de que le estaban cerrando las puertas a un mercado creciente.

Pero entretanto han ido surgiendo soluciones alternativas. No son las ideales, pero pueden servirte si las necesitas. Fueron las primeras, asi que en primer lugar las pongo. Me refiero, naturalmente, a NDisWrapper: con él puedes usar el Wireless gracias a un driver no nativo, diseñado para Windows. NDisWrapper no es otra cosa que un intérprete, que traduce órdenes Windows (Win XP, concretamente) a órdenes Linux. No todas, naturalmente, solo un puñado, el suficiente para hacer funcionar en Linux determinados drivers Windows. Entre ellos, el de nuestra tarjeta Wireless. :-) ¿Cómo se hace?.

En primer lugar, vete a NDISWrapper en Sourceforge y bájate el último driver. Yo me bajé, concretamente, "ndiswrapper-0.4.tar.gz". Ahora descomprimelo en /usr/src:

	[14:12:44/0]·[lacofi@lynette:~]$ su
	password:
	[14:13:13/0]·[root@lynette:/home/lacofi]# cd /usr/src
	[14:13:24/0]·[root@lynette:/usr/src]# tar -xzvf ndiswrapper-0.4.tar.gz
	[14:19:01/0]·[root@lynette:/usr/src]# ln -s /sbin/lspci /usr/bin/lspci
	[14:21:11/0]·[root@lynette:/usr/src]# ln -s /sbin/depmod /usr/bin/depmod
	[14:22:23/0]·[root@lynette:/usr/src]# ln -s /sbin/modprobe /usr/bin/modprobe

El script que configurará e instalará ndiswrapper asume que lspci, depmod y modprobe están en el path. Sin embargo, en Fedora no es así. Por eso, el script fallará hasta que metas esos tres programas en el path. De todas formas, LEETE el fichero INSTALL que encontrarás dentro del directorio /usr/src/ndiswrapper. Contiene instrucciones muy detalladas de cómo instalar este driver, tanto automáticamente como a mano. Yo lo hice en automático y me fue bien, una vez que creé los enlaces simbólicos que cito arriba.

Pero aun te queda la segunda parte (te lo dicen en las instrucciones, pero te lo cuento yo también): debes bajarte un driver para Windows XP. En la página de ndiswrapper tienes enlaces a los drivers, si quieres. Yo me bajé "intel2100b.zip". Ese fichero, descomprímelo en cualquier sitio. Solo te interesan dos ficheros: "w70n51.inf" y "w70n51.sys". Vale, pues ahora crea un directorio "/lib/windrivers" y copia ahí esos dos ficheros.

Ahora regresa a /usr/src/ndiswrapper y ejecuta "install.sh". Este programa se encargará de hacer el resto. El resto es compilar un nuevo módulo de kernel, para lo cual es imprescindible que hayas compilado tu uno previamente. Install.sh detectará la configuración y las fuentes de tu kernel buscándolas en "/usr/src/linux" y confrontándolas con el kernel que esté funcionando en ese momento. ES IMPORTANTE que el kernel que esté funcionando en este momento sea el mismo que se encuentra configurado en /usr/src/linux, ¿vale?. Bueno, pues el programa de instalación recurrirá a lspci, depmod y modprobe para manipular los módulos después de compilarlos, y también meterá una entrada en /etc/modules.conf que dirá algo parecido a esto:

	alias wlan0 ndiswrapper
	options ndiswrapper if_name=wlan0
	post-install ndiswrapper /usr/sbin/loadndisdriver 8086 1043 \
		/lib/windrivers/w70n51.sys /lib/windrivers/w70n51.inf

Y, hecho todo esto, configurará y cargará los módulos por primera vez. Todo automático, aunque te hará algunas preguntas muy sencillas como el nombre concreto de los ficheros "*.inf" y "*.sys" que forman el driver windows. Leete el fichero INSTALL, hazme caso. Trae todo esto que te he explicado y mucho más.

Cuando el driver ndiswrapper haya terminado de instalarse y te devuelva a la línea de comandos, puedes ejecutar un "modprobe ndiswrapper" y luego un comando dmesg para ver la respuesta del kernel:

	ndiswrapper version 0.4 loaded
	NdisWriteConfiguration --UNIMPLEMENTED--
	NdisWriteConfiguration --UNIMPLEMENTED--
	NdisWriteConfiguration --UNIMPLEMENTED--
	NdisWriteConfiguration --UNIMPLEMENTED--
	NdisInitializeString --UNIMPLEMENTED--
	NdisWriteConfiguration --UNIMPLEMENTED--
	NdisInitializeString --UNIMPLEMENTED--
	NdisWriteConfiguration --UNIMPLEMENTED--
	NdisInitializeString --UNIMPLEMENTED--
	NdisWriteConfiguration --UNIMPLEMENTED--
	NdisInitializeString --UNIMPLEMENTED--
	NdisWriteConfiguration --UNIMPLEMENTED--
	NdisInitializeString --UNIMPLEMENTED--
	NdisWriteConfiguration --UNIMPLEMENTED--
	NdisWriteConfiguration --UNIMPLEMENTED--
	NdisInitializeString --UNIMPLEMENTED--
	NdisWriteConfiguration --UNIMPLEMENTED--
	NdisInitializeString --UNIMPLEMENTED--
	NdisWriteConfiguration --UNIMPLEMENTED--
	NdisWriteConfiguration --UNIMPLEMENTED--
	wlan0: ndiswrapper ethernet device 00:04:23:8d:bd:9f

Reconozco que el informe del kernel es feo de narices, pero lo cierto es que funciona. Compruébalo:

	[18:10:45/0]·[root@lynette:~]# /sbin/iwconfig wlan0 essid LYNETTE
	[18:10:57/0]·[root@lynette:~]# /sbin/iwconfig 
	lo        no wireless extensions.

	eth0      no wireless extensions.
 
	irlan0    no wireless extensions.

	Warning: Driver for device wlan0 has been compiled with version 16
	of Wireless Extension, while this program is using version 15.
	Some things may be broken...
 
	wlan0	IEEE 802.11b  ESSID:""
		Mode:Managed  Channel:0  Access Point: FF:FF:FF:FF:FF:FF
		Bit Rate=54Mb/s
		RTS thr=1600 B   Fragment thr=2344 B
		Encryption key:off
		Power Management:off
		Link Quality:0/0  Signal level:-98 dBm  Noise level:-256 dBm
		Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
		Tx excessive retries:0  Invalid misc:0   Missed beacon:0
	[18:11:13/0]·[root@lynette:~]# /sbin/ifconfig wlan0 up
	[18:11:15/0]·[root@lynette:~]# /sbin/ifconfig wlan0 
	wlan0	Link encap:Ethernet  HWaddr 00:04:23:8D:BD:9F
		UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
		RX packets:0 errors:0 dropped:0 overruns:0 frame:0
		TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
		collisions:0 txqueuelen:1000
		RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
		Interrupt:11 Memory:d0000000-d0000fff

Naturalmente, no podremos hacer mucho con esto, puesto que no hemos configurado una red real (no hay IP, no hay carrier... no tengo ningún servidor al que conectarme). Pero está claro que el hardware funciona, que Linux puede controlarlo y que ha sido levantada una red wireless esperando por un servidor al que engancharse. :-)

Driver nativo

Tras muchas protestas por parte de la comunidad Linux, Intel ha recapacitado y ha publicado un driver nativo, con licencia abierta de tal forma que los linuxeros están colaborando activamente en el desarrollo. Las versiones van apareciendo y corrigiendo errores, incluso desgajándose en nuevos proyectos para versiones más recientes del chip. En el momento de redactar estas líneas se puede decir ya que el chip Intel PRO/Wireless 2100 Mini PCI 802.11b es ya completamente funcional bajo linux.

La configuración está bien descrita en un documento bastante detallado, (tenía que ser Gentoo WiKi, claro), pero está en inglés.

Así que vamos a hacerlo todo por nuestra cuenta, pero en castellano. ;-)

En primer lugar, tendrás que recompilar el kernel (una vez más, sí) para activar varias opciones que necesitará el driver. Quizás la más importante es la opción "Hotplug firmware loading support". En un kernel de la serie 2.6, lo encontrarás entrando en "Device Drivers", y luego "Generic Driver Options".

También debes asegurarte de que tienes activada la opción CONFIG_NET_RADIO del kernel (el soporte para las Wireless Tools). Puedes comprobarlo entrando en /lib/modules, en el directorio donde están tus módulos, y luego en build/include/linux. En el fichero autoconf.h debería haber una línea que dice:

	#define CONFIG_NET_RADIO 1

Si es así (es lo más probable), te felicito: ya tienes CONFIG_NET_RADIO activado.

Si no, tendrás que recompilar un kernel y asegurarte de que activas las opciones adecuadas, para un kernel de la serie 2.6.x (lo cuento más abajo y en cualquier caso lo tienes en Gentoo-Wiki).

Fíjate que además, si quieres usar la red inalambrica con un poco más de seguridad puedes usar WEP, que es una especie de protocolo que encripta la transmisión. Para ello entra en "Cryptographic options", activa "Cryptographic API" y asegúrate de que están marcados al menos "ARC4 cipher algorithm" y "CRC32 CRC algorithm". Ahora recompila el kernel. Asumo que sabes como hacerlo, claro.

Si eres usuario de Gentoo, instalar los drivers para la Intel Pro/Wireless es tan fácil como hacer un "emerge ieee80211 ipw2100". :-) Supongo que otras distribuciones tienen sus propios paquetes ipw2100 listos para instalar. Estoy seguro de Debian, por ejemplo, pero no dudo de que también lo tenga una Mandriva o una Ubuntu.

Si ahora haces un "dmesg" verás cómo identifica el chip Wireless y las rutinas IEEE80211:

ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
ieee80211_crypt: registered algorithm 'NULL'
[...]
ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, git-1.2.2
ipw2100: Copyright(c) 2003-2006 Intel Corporation
ACPI: PCI Interrupt 0000:02:02.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
ipw2100: Detected Intel PRO/Wireless 2100 Network Connection

Solo queda un detalle: aparte de activar el Wireless, tienes que levantar la red editando /etc/conf.d/wireless (en la parte amarilla está el nombre de tu red y en la cian debe ir la contraseña WEP):

modules_eth1=( "iwconfig" )
mode_eth1="Managed"
essid_eth1="dancerine"
preferred_aps=( "dancerine" )
key_dancerine="s:66666666666666 enc open"

Y ahora arranca la red:

 
[root@lynette]# /etc/init.d/ipw2100 start

O mejor aún, haz que la red arranque en cuanto enciendas el ordenador:

 
[root@lynette]# rc-update add ipw2100 default

En los kernels más nuevos de Linux (por ejemplo un 2.6.18), el soporte de la Intel Pro Wireless 2100 está ya integrado en el núcleo, así que podrás encontrar todo lo necesario simplemente haciendo un make menuconfig. Eso sí, todavía necesitarás instalar los ficheros del firmware, que tendrás que descargar y ponerlos en el directorio /lib/firmware.

Si prefieres compilar ipw2100 desde tu kernel, tendrás la ventaja de que no necesitarás reemerger o recompilar el módulo ipw2100 cada vez que recompiles el kernel: estará todo integrado en el propio núcleo, así que es lo que yo te recomiendo. Haz un make menuconfig:

 
Networking --->
		   <*>   Generic IEEE 802.11 Networking Stack
			[ ]     Enable full debugging output
			<M>     IEEE 802.11 WEP encryption (802.1x)
			<M>     IEEE 802.11i CCMP support
			<M>     IEEE 802.11i TKIP encryption
			<M>     Software MAC add-on to the IEEE 802.11 networking stack
Device Drivers --->
  Network Device support --->
	 Wireless LAN (non-hamradio) --->
		   [*]	Wireless LAN drivers (non-hamradio) & Wireless Extensions
		   <M>   Intel PRO/Wireless 2100 Network Connection
		   [ ]     Enable promiscuous mode
			[ ]     Enable full debugging output in IPW2100 module.

Pero recuerda que sigue siendo necesario instalar el firmware. En el caso de Gentoo, bastará con un "emerge ipw2100-firmware". Si no tienes un paquete preparado para tu distribución, puedes encontrar el firmware en Souceforge. Tendrás que leer y aceptar las condiciones de la licencia, eso sí.

 

Modem integrado: Smart Link 56K AC'97

Existe un driver nativo para hacer funcionar este modem en linux. Bájate la última versión disponible y descomprímelo en /usr/src

	[19:12:00/0]·[root@lynette:/usr/src]# tar -xzvf slmodem-2.9.6.tar.gz
	[19:12:59/0].[root@lynette:/usr/src]# cd slmodem
	[19:13:09/0].[root@lynette:/usr/src/slmodem]# make && make install
	[19:14:12/0].[root@lynette:/usr/src/slmodem]# ln -s /dev/ttySL0 /dev/modem

Observa que la última orden crea un enlace ROTO en /dev/modem. Lo que hace el driver que acabas de compilar es precisamente crear un fichero /dev/ttySL0 que es donde está el modem, con lo que /dev/modem dejará de estar roto.

Si eres usuario Gentoo, puedes instalar los drivers con un "emerge slmodem" o, si tienes un kernel moderno, usando los drivers integrados que vienen con el kernel (haz un make menuconfig y vete a la sección de sonido y ALSA). Yo te recomiendo usar el driver intel8x0m integrado en kernel que viene con los más nuevos (por ejemplo un kernel 2.6.18). Tienes instrucciones detalladas sobre cómo hacerlo en el Gentoo-WiKi. Presta atención a la configuración.

Pero ahora tienes que hacer que arranque el driver. Para eso, edita el fichero /etc/init.d/slmodemd (con permisos de lectura y ejecución) y asegúrate de que contenga que contenga:

	/usr/sbin/slmodemd --country=SPAIN &

Y luego crea un enlace simbólico en /etc/rc5.d para que se ejecute siempre que entres en runlevel 5:

	[19:15:17/0].[root@lynette:/usr/src/slmodem]# cd /etc/rc5.d
	[19:15:19/0].[root@lynette:/etc/rc5.d]# ln -s ../init.d/slmodemd S20slmodemd

Si usas Fedore Core 1, existe una solución mucho más elegante. Después de compilar, copia el script slmodemd que encontrarás en /usr/src/slmodem/scripts/slmodemd a /etc/init.d/slmodemd. Edita este script y cambia la línea que pone SLMODEMD_COUNTRY=USA por SLMODEMD_COUNTRY=SPAIN. Luego, ejecuta como root el comando "/sbin/checkconfig --add slmodemd". El programa checkconfig se encargará de crear el enlace simbólico en el runlevel actual, con la ventaja de que slmodemd quedará integrado, por ejemplo, en las herramientas de Fedora Core (aparecerá mismamente en el programa "servicios", en el menú de "configuración del sistema"). Gracias a Pierre François por este detalle. ;-) Sin embargo, esta solución no funcionará en sistemas Debian, Knoppix o derivados. El motivo es que el script /etc/init.d/slmodemd llama a un script externo /etc/init.d/functions que solo existe en distribuciones basadas en Red Hat. Gracias a Nuria por descubrirlo. ;-)

Ahora, Linux cargará el driver del modem en cada arranque. La respuesta del kernel será:

	slamr: SmartLink AMRMO modem.
	slamr: probe 8086:24c6 ICH4 card...
	PCI: Setting latency timer of device 00:1f.6 to 64
	slamr: mc97 codec is SIL22
	slamr: slamr0 is ICH4 card.

Y, naturalmente, ahora podrás ya arrancar kppp, por ejemplo, y configurar una conexión a Internet por modem.

Muchas gracias, desde aquí a aktaion que describió, en su web, la configuración de SUSE en un ordenador Fujitsu-Siemens Amilo M-7400. ¿Qué tiene que ver conmigo?. Que ambos ordenadores (el suyo y el mio) usan tecnología Centrino, y tienen el mismo modem. :-)

 

Tarjeta de sonido integrada: Intel 810 + Realtek AC'97 Audio

Es reconocida automáticamente en los kernels por defecto, tanto de Knoppix como de Fedora. Solo quiero mencionarte un detalle: si estás compilando un kernel, ni se te ocurra meter el audio dentro del mismo. Compilalo siempre como módulos, con lo que se configurarán solos. Si no, no te funcionará el audio porque tendrías que meter toda la configuración como parámetros del kernel. Hazme caso, si compilas, mételos como módulos y te ahorrarás problemas.

En el caso de Gentoo, seguramente usarás un kernel a medida (a que sí), así que haz un make menuconfig, vete a Sound, desactiva OSS, activa ALSA, y activa como módulos las opciones "Sequencer support", "OSS Mixer API", "OSS PCM (digital audio) API", y después entra en "PCI devices" y activa también los módulos "Emu10k1", e "Intel/Sis/nVidia/AMD/ALI AC97 Controller" (que es el driver propiamente dicho).

Si eres usuario Gentoo, vete corriendo a la excelente documentación Gentoo, que te lo cuentan todo mucho mejor que yo.

 

Firewire: IEEE 1394 VIA Tech

Fedora lo reconoce automáticamente con el kernel por defecto. Si compilas uno entra en la primera opción del menú principal de "make menuconfig", la que pone "Code maturity level options". Dentro, marca la única opción que hay: "Prompt for development and/or incomplete code/drivers". Una vez activado, aparecen opciones en el resto de los menús que antes no existían.

Bueno, pues ahora, si sales al menú principal verás una entrada que dice "IEEE 1394 (FireWire) support (EXPERIMENTAL)". Más claro, agua. Entra, y pon módulos como un loco, anda. Una vez compilado, y arrancado, el kernel te dirá:

	ohci1394: $Rev: 1045 $ Ben Collins <bcollins@debian.org>
	ohci1394_0: OHCI-1394 1.0 (PCI):
		IRQ=[11]
		MMIO=[d0001800-d0001fff] Max Packet=[2048]
	ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00023f3b320005a5]
	cs: IO port probe 0x0c00-0x0cff: clean.
	cs: IO port probe 0x0100-0x04ff: excluding 0x230-0x237 0x300-0x30f 0x4d0-0x4d7
	cs: IO port probe 0x0a00-0x0aff: clean.

 

Infrarrojos: Puerto infrarrojos SMC IrCC - Fast Infrared

Aquí no hay más narices que recompilar el kernel. Ahora que has activado lo de "Prompt for development drivers" para dar soporte a tu FireWire, entra otra vez en la sección de "IrDA (Infrared) support". Verás que ha aparecido la opción que tanto buscabas y no encontrabas: en "infrared-port device drivers" encontrarás "SMC IrCC (Experimental)". Una vez compilado, el kernel informara:

	IrCOMM protocol (Dag Brattli)
	found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
	SMC IrDA Controller found
	IrCC version 2.0, firport 0x230, sirport 0x2f8 dma=3, irq=3

 

Winbond SD: Winbond Secure Digital

Las ranuras de lectura SD integradas están soportadas en los kernels más nuevos. En el momento de escribir estas líneas, estoy usando un kernel 2.6.18, pero podría valer también un 2.6.17 y quizás kernels un poco más viejos. Si tienes este portatil, de todas formas, te recomiendo que te actualices a un kernel 2.6.18 porque a mí me funciona correctamente y es el primero que he visto que soporta al 100% todo el hardware del portátil incluyendo la ranura Winbond SD.

Haz un "make menuconfig" y recompila:

 
Device Drivers --->
  MMC/SD Card support --->
	 <*> MMC support
	 [ ]   MMC debugging
	 <M>   MMC block device driver
	 < >   Secure Digital Host Controller Interface support  (EXPERIMENTAL)
	 <M>   Winbond W83L51xD SD/MMC Card Interface support

Si reseteas con el nuevo kernel, y cargas ahora los módulos con un "modprobe mmc-block wbsd", verás que la salida dmesg identifica el chip correctamente, pero en cuanto metas una tarjeta SD empezarán a pasar cosas raras con la línea de comandos, como quedarse congelado el cursor, o aparecer caracteres aleatoriamente. El problema es que este lector SD no soporta las funciones DMA, así que vamos a desactivar el DMA (solo para el lector de tarjetas, no te preocupes).

Bien, saca la tarjeta SD, y retira los módulos con un "rmmod mmc-block wbsd". Ahora edita el fichero /etc/modprobe.conf y añade una línea que diga:

 
options wbsd nopnp=1 irq=5 dma=-1

Con esto estás desactivando el Plug and Play de la ranura (imprescindible, para que te permita cambiar los otros parámetros), estás especificando el IRQ correcto y estás desactivando el DMA.

Ahora vuelve a cargar los módulos con un "modprobe wbsd mmc-block". La salida del comando dmesg debería decir:

 
wbsd: Winbond W83L51xD SD/MMC card interface driver, 1.6
wbsd: Copyright(c) Pierre Ossman
mmc0: W83L51xD id 7112 at 0x248 irq 5 FIFO

Si ahora metes una tarjeta SD, la salida dmesg añade:

 
mmcblk0: mmc0:b368 SMI   249856KiB
 mmcblk0: p1

Y si tienes instalado UDEV (espero que sí), deberían aparecer los dispositivos correctos en /dev:

 
[lacofi@lynette]$ ls /dev/mmc*
brw-rw---- 1 root disk 254, 0 dic 28 18:36 /dev/mmcblk0
brw-rw---- 1 root disk 254, 1 dic 28 18:36 /dev/mmcblk0p1

El que nos importa es el segundo dispositivo, porque es la particion y es el que vamos a usar para montarlo.

 
[lacofi@lynette]$ su
password:
[root@lynette]# mount /dev/mmcblk0p1 /mnt/pruebas -t vfat -o rw
[root@lynette]# ls /mnt/pruebas
total 12K
drwxrwx--- 6 root users 4,0K oct  2 03:54 Mi_musica/
drwxrwx--- 3 root users 4,0K oct  2 02:48 palm/
-rwxrwx--- 1 root users   38 oct  2 02:48 volume.nam*
[root@lynette]# umount /mnt/pruebas

Vale. Lo hemos desmontado enseguida porque una vez comprobado que funciona, vamos a modificar los scripts de autofs para que el montaje de las tarjetas SD sea automático. Edita /etc/autofs/auto.misc y añade una línea que diga:

 
sdintegrado     -fstype=vfat,gid=100,umask=0007,sync    :/dev/mmcblk0p1

Ahora vete a /mnt y crea el link adecuado. Después reinicia el sistema autofs.

 
[root@lacofi]# cd /mnt
[root@lacofi]# ln -s auto/sdintegrado sdintegrado
[root@lacofi]# /etc/init.d/autofs restart

Y por último añade los módulos mmc-block y wbsd a tu fichero /etc/modules.autoload.d/kernel-2.6 para que se carguen automáticamente en el arranque:

 
# en /etc/modules.autoload.d/kernel-2.6
mmc-block
wbsd nopnp=1 irq=5 dma=-1

Resetea, y ya está. Ahora basta con que metas una tarjeta SD en la ranura para que puedas ver (y escribir) en ella en el directorio /mnt/sdintegrado.

 

Trucos específicos para este ordenador

 

Speedstep-centrino

APM está muerto. El futuro es de ACPI.

Y una de las aplicaciones prácticas de ACPI es Speedstep, en los ordenadores Centrino como éste. Speedstep permite modificar la velocidad de proceso del ordenador dependiendo de la energía disponible. De esta forma, si la batería dispone de poca energía, el procesador irá más lento para ahorrar potencia.

Sin embargo, cuando digo que Linux soporta plenamente ACPI, estoy diciendo una verdad a medias. Sí, es cierto, lo soporta y el kernel permite utilizar muchas funciones de ACPI, pero los que lo aprovecharán son los kernels de la serie 2.6.x. En cambio, el kernel 2.4.24 no dispone de funciones específicas como Speedstep, por ejemplo, con lo que la velocidad de proceso es fija, no cambia dinámicamente dependiendo de la carga.

Hombre... si quieres, puedes parchear un 2.4.24 para incorporar Speedstep-centrino. Para ello, tienes que bajarte un parche (yo me bajé cpufreq-LINUX_2_4-20040225.tar.gz) desde ftp.linux.org.uk. Descomprimelo en /usr/src y ejecuta el script patchin.sh que encontrarás en /usr/src/cpufreq (el subdirectorio cpufreq se crea al descomprimir el fichero con el parche). Cuando ejecutas ese script, se parcheará automáticamente el kernel que se encuentre en /usr/src/linux. Si luego haces un "make menuconfig" verás opciones nuevas dentro de "Processor type and features". Mira dentro de "CPU Frecuency scaling" y encontrarás Speedstep Centrino. Luego puedes completarlo instalando el demonio cpufreqd, que debería estar disponible en tu apt-get o en la distribución que uses.

Pero es terreno pantanoso. Ya te advierto que el parche que me he bajado yo no ha servido, no funciona. Cierto que tampoco me ha hecho daño, pero desde luego no ajusta la velocidad del procesador. Es como si no existiera.

O también puedes compilar un Kernel de la serie 2.6, claro, que tienen ya pleno soporte de cpufreqd y de speedstep-centrino, sin necesidad de parche alguno. Desde que me pasé a los kernel 2.6.5, a mí me funciona perfectamente y no tengo ya ninguna queja. ;-)

 

¿Puedo aprovechar los estados "throttling" para ahorrar batería?

El procesador Pentium M Centrino de este ordenador tiene 8 estados throttle diferentes, desde 0 hasta 7. Este throttling consiste en que el procesador se pone periódicamente en standby durante una fracción de segundo. Con ello se enlentece, claro, pero no se interrumpe, y durante el breve momento en que queda en suspenso, consume poca energía lo que alargará la vida de la batería. A más nivel de throttling, más periodos de "standby" y, por tanto, más lentitud y ahorro de energía.

Parece una chorrada, eso de que el ordenador vaya más lento, pero piensa uno poco: tu ordenador es tan rápido que la mayor parte del tiempo no está haciendo nada, salvo esperar a que tú le pidas algo. Solo necesita plena potencia en momentos muy concretos, cuando arrancas un procesador de textos, o cuando haces correr un simulador como "celestia". El resto del tiempo, podrías estar usando la mitad, o la cuarta parte de su potencia real, y no enterarte. Esa es la cuestión que subyace al throttling: usar solo la energía que realmente necesitas. Según esto, Linux debería cambiar continuamente el throttling según la carga del sistema, de tal modo que el microprocesador proporcione más potencia solo si se necesita. De hecho, esto solo debería ser así si estás trabajando con batería, porque si estás conectado a la red no necesitas ahorrar nada, con lo que el throttling debería quedar fijado en cero. ¿Se puede hacer todo esto?.

Pues sí. Pero necesitas un programa que lo gestione adecuadamente y de forma automática. Puedes utilizar scaler, pero es demasiado brusco en los cambios de throttle, con lo que el ordenador funciona un poco a saltos. Yo te recomiendo autothrottle que hace lo mismo, pero con una suavidad pasmosa, tanta que no notarás que el ordenador está cambiando la velocidad. El programa se compila con un simple "make && make install", pero tiene un pequeño error que le hace fallar con el ACPI. El problema es que el programa presupone el fichero /proc/acpi/processor/CPU/throttling, cuando nuestro ordenador utiliza /proc/acpi/processor/CPU0/throttling. Afortunadamente, esto es linux, código abierto, así que solo hay que cambiar el fichero config.c de las fuentes de autothrottle, de tal forma que donde diga "CPU/throttling" debe decir "CPU0/throttling", y luego ya puedes compilar. Son solo dos cambios de nada, pero ¿ves?, esto en Windows sería imposible, y el programa quedaría inservible solo por esa tontería.

Cuando ejecutes autothrottle como root, empezará a funcionar cambiando el throttling de acuerdo con la carga. Pero aún tienes que hacer que se ponga en marcha adecuadamente y solo cuando sea necesario. Eso puedes conseguirlo con un sencillo script ACPI.

Crea un fichero /etc/acpi/events/ac.conf que contenga:

	# ACPID: configuración para AC
	event=battery.*
	action=/usr/local/bin/ac.sh "%e"

Esto hace que ante cualquier evento de batería, se llame a un script externo "ac.sh". Un evento de batería es por ejemplo un cambio crítico en la carga, o el cambio de corriente alterna a batería y a la inversa. Vale, pues ahora tienes que crear el script que pondrá en marcha el programa scaler. Por ejemplo este:

#!/bin/sh

STATUS=`cat /proc/acpi/ac_adapter/AC/state`
LOG="/var/run/scaler.pid"
ACPILOG=/var/log/acpid

case $STATUS in
	*on-line)
		if [ -f $LOG ] ; then
			killall -9 autothrottle
			rm $LOG
			echo 0 > /proc/acpi/processor/CPU0/throttling
			echo 1400000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
			echo "-- Estamos on-line. Energía plena." >> $ACPILOG
		fi
		;;
	*off-line)
		if [ -f $LOG ] ; then
			echo "-- Estamos off-line. Ahorro de energía." >> $ACPILOG
		else
			echo 4 > /proc/acpi/processor/CPU0/throttling
			echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
			autothrottle
			echo "-- Estamos off-line. A medio gas y throttling." >> $ACPILOG
			touch $LOG
			fi
			;;
	*)
		echo  "Hubo un error"
		;;
esac
	

Ya solo queda reiniciar el demonio acpid "/etc/init.d/acpid restart" y entrará todo en funcionamiento. En mi ordenador, autothrottling ha conseguido aumentar la duración de mi batería desde 3 horas (sin autothrottling) hasta 5 (te lo juro, solo con el autothrottling). Lo que no está nada mal, por cierto. Madre mía, cinco horas de autonomía, solo tirando de batería (!!!).

Sin embargo, un detalle de puro sentido común: El autothrottling no funcionará si tienes activado el salvapantallas. Efectivamente, además de no servir para nada, el salvapantallas exige una alta potencia de proceso casi siempre, (para procesar esas bonitas imágenes), además de que la propia pantalla consume muchísima energía. El resultado es que autothrottle se verá obligado a ajustar el throttle a cero, precisamente cuando no estés usando el ordenador. La batería durará tres horas, no cinco, solo por la tontería del salvapantallas. Hazme caso, desactívalo, o al menos activa las funciones de ahorro de energía (apagado automático de la pantalla en inactividad). ;-)

 

Conseguir que apretando el botón off, se haga un apagado "limpio"

Con ACPI se puede conseguir que, cuando aprietes el botón off, el ordenador haga un shutdown ordenado en lugar de limitarse a cortar la energía.

En realidad, es muy fácil. Mete en /etc/acpi/events un fichero que se llame "power.conf" y que contenga esto:

	# This is a sample ACPID configuration

	event=button/power.*
	action=/usr/local/bin/shut.sh

Esto hará que cuando ACPI detecte que se ha pulsado el botón on/off, en lugar de apagar, se ejecute el script /usr/local/bin/shut.sh

Lo que pongas en ese script, naturalmente, queda a tu imaginación, pero no hay ningún límite teórico. Yo he puesto esto:

	#!/bin/sh
	/usr/bin/zenity --display=:0.0 --warning --title="ATENCION" \
		--text="Confirma que quieres APAGAR el ordenador:"
	status=$?
	if [ "$status" = 0 ] ; then
		shutdown -h now
	fi

Esto hace que, cuando pulses off, te salga en pantalla un cuadro de diálogo que dice "Confirma que quieres APAGAR el ordenador: SI/NO". Si pulsas el botón no, se cancelará el apagado. Si pulsas el botón SI, el ordenador iniciará un shutdown ordenado.

Si lo intentas, verás que a ti no te aparece el cuadro de diálogo. Eso es porque el servidor X no permite que otro usuario (en este caso root) saque mensajes en tu pantalla. Para solucionarlo, abre el menú de inicio, vete a "Preferencias", arranca el "Centro de control de Gnome" (Estás usando Gnome, ¿verdad?), vete a "Mas preferencias", Ahí arranca "Sesiones" y te saldrá un bonito cuadro de diálogo. En ese cuadro de diálogo vete a la pestaña "Programas al inicio" e introduce un comando que diga "xhost local:root@". Este comando se ejecutará cada vez que entres en tu Gnome, y sirve para que X Window permita a root (solo desde el ordenador local, no a un root remoto) que ejecute aplicaciones X en tu pantalla. Con esto, debería aparecer el cuadro de diálogo cuando pulses el botón de off.

 

Conseguir que, cuando se agote la batería, se haga un apagado "limpio"

A veces, cuando estoy trabajando, tengo que dejar solo el ordenador durante mucho tiempo. Con la batería, es facil que se agote y la máquina se apague bruscamente, por lo que si quiero evitarlo tengo que dejarlo siempre enchufado.

Ahora, ACPI permite tomar decisiones según el nivel de carga de la batería. Esto me permite hacer la siguiente virguería con el Highscreen: Si se está agotando la energía, unos cinco minutos antes de terminarse, la máquina se da cuenta y lanza un shutdown ordenado, con un minuto de advertencia para dar tiempo a cerrar los programas. Este truco no es mío, lo tomé de un foro. Gracias al autor (Eli Billauer) por esta pequeña joya. ;-)

Crea un fichero llamado /etc/acpi/events/lowbat.conf y que contenga:

	event=battery.*
	action=/usr/local/bin/checkbattery || wall "No se pudo ejecutar checkbattery."

Cada vez que ACPI sea notificado de un evento de batería, llamará al script checkbattery. Si por cualquier motivo no puede hacerlo, guardará una advertencia en /var/log/acpid (que es donde se guardan todos los logs de ACPI, claro). El script checkbattery es así:

	#!/usr/bin/perl -w

	eval {
 		open INFO, "/proc/acpi/battery/BAT0/info" ||
   		die("No se pudo abrir /proc/acpi/battery/BAT0/info\n");
 		$info = join "",<INFO>
 	close INFO;


 		open STATE, "/proc/acpi/battery/BAT0/state" ||
   		die("No se pudo abrir /proc/acpi/battery/BAT0/state\n");
 		$state = join "",<STATE>
 	close STATE;

	($warnlevel) = ($info =~ /^design capacity low:\s*(\d+)\s*mAh/im);

 	die "No se pudo resolver Design Capacity Low en /proc/acpi/battery/BAT0/info\n"
	unless (defined $warnlevel);

	($level) = ($state =~ /^remaining capacity:\s*(\d+)\s*mAh/im);

	die "No se pudo resolver Remaining Capacity en /proc/acpi/battery/BAT0/state\n"
	unless (defined $level);

	($ac) = ($state =~ /^charging state:\s*(\w+)/im);

	die "No se pudo resolver Charging State en /proc/acpi/battery/BAT0/state\n"
	unless (defined $ac);

	die "Charging State desconocido extraido de /proc/acpi/battery/BAT0/state: $ac\n"
	unless (($ac eq 'discharging') || ($ac eq 'charging') || 
			($ac eq 'charged') || ($ac eq 'unknown'));

	# Si estamos aquí, tenemos datos. Apagaremos si el nivel de carga
	# está por debajo del de emergencia, (salvo que se esté recargando, claro).

	exit 0 if ($ac eq 'charging');
	exit 0 if ($ac eq 'charged');
	exit 0 if ($level > $warnlevel);

	# ¿Estamos aquí?. ¡Necesitamos apagar YA!.


	open F, "|wall";
	print F <<"LOWEND";
	******************************************************************************
				L O W   B A T T E R Y   S H U T D O W N

	La carga de la batería es $level mAh <= $warnlevel mAh y está en modo $ac
	******************************************************************************
	LOWEND

	exec '/sbin/shutdown','-h','+1'; # Bye-bye sistema

	};

	if ($@) {

	open F, "|wall";
	print F <<"END";
	Esto es $0, llamado desde acpid.
	Se ha disparado un evento de batería pero no pudo manejarse.
	Un evento de batería es un cambio en la carga o que se haya (des)enchufado
	en ese momento. En otras palabras, un evento no es, en sí mismo, peligroso
	ni dañino.
	Pero el fallo de este script significa que el ordenador no puede
	apagarse correctamente a pesar de que la carga es muy baja, así que
	algo hace que este script resulte inútil. Deberías chequearlo.

	La razón del fallo:
	$@
	END
 		close F;
	}

Una vez reiniciado /etc/init.d/acpid, este script será llamado cada vez que la batería notifique un evento a ACPI. El script buscará qué es lo que ha ocurrido (si el ordenador está enchufado, si la carga es correcta, si está por debajo del nivel de emergencia...). Si procede, se iniciará un shutdown, con un minuto de margen para que, si estamos delante, nos de tiempo a guardar los datos y salir de los programas. Si no estamos da igual, el ordenador lo cerrará todo y comenzará la secuencia de apagado. Lo he comprobado en mi ordenador, y con este script se apaga automáticamente cuando le queda solo un minuto de energía en la batería. Más ajustado imposible. :-)

Eso sí, el ordenador te va a abrasar a pitidos histéricos en los últimos minutos, porque el script se pondrá en marcha cuando la energía sea realmente baja. Si quieres poner un margen más generoso sustituye "capacity low" por "capacity warning", que es como venía en el script original de los foros. Entonces se empezará a apagar mucho antes, cuando aún hay como 20 minutos de energía disponible en la batería. Yo prefiero apurar hasta la última gota, pero tú mismo.

 

Pero así, al agotarse la batería, puedo perder datos...

Bueno, sí, pero existe una alternativa mejor: conseguir que funcione la hibernación. Si lo consigues, puedes usar el script "checkbattery" del punto anterior, pero sustituyendo donde pone:

	exec '/sbin/shutdown','-h','+1'; # Bye-bye sistema

Por esto otro:

	exec '/usr/local/sbin/hibernate'; # Hasta luego, nada más.

De esta forma, cuando se quede sin batería, el ordenador no se apaga realmente, sino que se hiberna, de tal forma que cuando volvamos a encenderlo, recuperará toda la información intacta, justo donde lo habíamos dejado. Espectacular.

 

¿Puedo hacer que el ordenador reaccione de algún modo al cerrar la tapa?

La tapa de un portátil genera dos eventos ACPI diferentes: "abrir la tapa" y "cerrar la tapa". Una solución útil sería por ejemplo que el ordenador entrase en hibernación en cuanto cierras la tapa del ordenador.

Pero no es la única solución. Por ejemplo, yo estoy haciendo uso de las funciones throttling del procesador. Así, cuando cierro la tapa, el ordenador pasa al nivel máximo de throttling (grado 7), con lo que el procesador se vuelve muy, muy lento pero no se detiene. Esto hace que ahorre mucha batería, pero continúa haciendo, lentamente, todos los trabajos que le hayas programado (por ejemplo, recompilar un kernel). En cuanto abres la tapa, el ordenador cambia a throttling grado 0, con lo que vuelve a funcionar a toda potencia. Hacer esto es muy fácil. Crea un fichero /etc/acpi/events/lid.conf que contenga:

	# Llamamos a un fichero de script externo.
 
	event=button/lid*
	action=/usr/local/bin/lid.sh %e

En cuanto reinicies el demonio "acpid", cargará esta configuración y vigilará la aparición de cualquier evento de botón que haga referencia a "lid" (tapa, en inglés). Si surge ese evento, llamará al script /usr/local/bin/lid.sh y le pasará los argumentos sobre lo sucedido. Ahora tienes que crear ese script, claro. Por ejemplo, yo he adaptado una solución que encontré en el Google:

	#!/bin/sh
	# /etc/acpi/lid.sh
 
	EVENT=$1
	TYPE=$2
	ID1=$3
	COUNTER=$4
	STATUSFILE=/tmp/lid.status
 
	echo "`date`<$@> - $EVENT - $TYPE - $ID1 - $COUNTER - " >> /tmp/acpid.log
 
	STATUS=`cat /proc/acpi/button/lid/LID/state`
 
 	#*open)   echo "Alguien ha abierto la tapa" ;;
 	#*closed) echo "Alguien ha cerrado la tapa" ;;
 	#*)       echo "Alguien es mago" ;; 
	#o sea: 
 
	case $STATUS in
 		*open)   echo 0 > /proc/acpi/processor/CPU0/throttling ;;
 		*closed) echo 7 > /proc/acpi/processor/CPU0/throttling ;;
 		*)       echo "Alguien es mago" ;;
	esac

Por cierto. Puedes consultar todos los eventos ACPI que hayan sucedido últimamente, leyendo el fichero /var/log/acpid

 

¿Cómo hago para poner el ordenador en hibernación?

Ejecutando como root el comando:

	[15:10:01/0][root@lynette:~]# echo 1 > /proc/acpi/sleep

Esto haría un "Standby" clásico. El problema es que la única forma de despertarlo después es pulsando el botón de encendido. Si no quieres ver cómo tu ordenador se reactiva solo lo justo para entrar en shutdown, te recomiendo que interceptes la función de este botón haciendo uso de los eventos ACPI, tal y como te explico más arriba.

También puedes ejecutar:

	[15:12:23/0][root@lynette:~]# echo 4 > /proc/acpi/sleep

Esto haría una hibernación en disco (Software Suspend 1), pero no he conseguido que funcione. En la práctica, tendrás que instalar la versión 2 de Software Suspend.

Y aquí las cosas se complican un poco, porque Software Suspend 2 no viene de serie con el kernel, sino que hay que instalarlo y prepararlo, lo que resulta con poquito lioso e implica aplicar un parche. Pero, créeme, una vez hecho el resultado es magnífico. Es estable, funciona a la perfección, y en mi ordenador no ha dado ningún problema. Eso sí, el camino de linux hacia la hibernación en disco ha sido bastante tortuoso, y solo ahora se puede decir que funciona decentemente, gracias a que los kernels 2.6.9 y superiores incorporan la posibilidad de suspender la actividad en muchos dispositivos como audio, o USB, que en kernels anteriores daban bastante la puñeta.

Lo primero que necesitas es una partición de swap con un 30 % más de tamaño que tu RAM. En mi caso, es /dev/hda11, que tiene 750 Mb para una RAM de 512 Mb. Si no dispones de una swap tan grande, tendrás que crearla, lo siento, porque es imprescindible. Lo segundo que necesitas es actualizar tu kernel a uno 2.6.9 o superior. Tendrás que compilar uno nuevo, pero sirve la configuración que has estado usando hasta ahora en cualquiera de tus kernel 2.6.x, y si tienes un ordenador exactamente igual que el mio, te pongo mi fichero de configuración. Así que ya sabes:

[lacofi@lynette lacofi]$ su
password:
[lacofi@lynette lacofi]# cd /usr/src
[lacofi@lynette src]# tar -xjf ~/linux-2.6.9.tar.bz2
[lacofi@lynette src]# rm linux
rm: ¿borrar el enlace simbólico "linux"? (s/n) s
[lacofi@lynette src]# ln -s linux-2.6.9 linux && cd linux
[lacofi@lynette linux]# cp ../linux-2.6.7/.config . && vim Makefile
(copiamos la configuración de nuestro kernel viejo, para ahorrarnos trabajo)
(editamos Makefile con nuestro editor favorito para poner un apéndice
a EXTRAVERSION. En mi caso, EXTRAVERSION = -kal)

Pero no compilamos todavía, porque este kernel hay que parchearlo para que funcione la hibernación. Asi que nos vamos a la página Web de Software Suspend y le echamos un vistazo, que siempre viene bien. Tenemos que bajarnos los parches para nuestro kernel 2.6.9 y un script que se llama "hibernate-script". Ambas cosas están disponibles en el servidor. De todas formas, es muy posible que cuando leas esto, el kernel 2.6.9 ya esté anticuado, y los correspondientes parches descatalogados. Así que conviene que acudas a su sección de "download" que es donde te ponen los enlaces correctos. ¿Vale?.

Pues ahora hay que aplicarlo todo. Las instrucciones están muy detalladas en su web, así que no hay ningún misterio:

[lacofi@lynette linux]# cd ..
[lacofi@lynette src]# tar -xjf ~/software-suspend-2.1.5-for-2.6.9.tar.bz2
[lacofi@lynette src]# tar -xjf ~/hibernate-script-1.02.tar.gz
[lacofi@lynette src]# cd linux
[lacofi@lynette linux]# ../software-suspend-2.1.5-for-2.6.9/apply
(lista de parches que se están aplicando)
All patch OK!
[lacofi@lynette linux]# ../hibernate-script-1.02/install.sh
hibernate-script install finished
[lacofi@lynette linux]# make menuconfig

Ahora revisamos nuestra configuración. Comprobamos que tenemos marcado todo lo que queremos, y luego nos vamos a "Power management options" y ahí entramos en "Software Suspend 2". Yo he marcado y desmarcado las siguientes opciones:

<*> Software Suspend 2
--- Image Storage (you need at least one writer)
<*>    Swap Writer
--- Page Transformers
<*>    LZF image compression
< >    GZIP image Compression
--- User Interface Options
<*>   Text mode console support
--- General Options
(/dev/hda11)    Default resume device name
[ ]    Allow Keep Image Mode
--- Debugging
[ ]    Compile in debugging output
< >    Compile checksum module

Ahora compilamos nuestro kernel parcheado:

[root@lynette linux]# make &&
> make modules_install &&
> cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.9-kal &&
> cp System.map /boot/System.map-2.6.9-kal &&
> vim /etc/lilo.conf

Estamos compilando un kernel, sí, así que tardará un ratito. Nos vamos a tomar un café, y cuando volvamos encontraremos la configuración de lilo en pantalla. Ahora hay que asegurarse de que hay una entrada correcta para nuestro kernel, incluyendo la especificación de que use nuestra swap como espacio de hibernación (observa el parámetro "resume2"):

image=/boot/vmlinuz-2.6.9-kal
  vga=791 # o vga=normal, si no funcionan los tipos especiales de consola
  label=Gentoo
  root=/dev/hda5 # o la partición que nosotros tengamos
  append="hdc=ide-cd acpi=force acpi_os_name=MicrosoftWindows2000 resume2=swap:/dev/hda11"
  read-only

Ahora instalamos lilo y, por seguridad, ponemos en blanco la swap que servirá para hibernar:

[root@lynette linux]# /sbin/lilo
Added Serie
Added Probando
Added Inestable
Added Estable
Added Gentoo *
Added Gentooza
Added Gentoo-test
Added Win2000
Added MS-DOS
[root@lynette linux]# swapoff /dev/hda11
[root@lynette linux]# mkswap /dev/hda11
[root@lynette linux]# swapon /dev/hda11

Lo principal ya está hecho. Con esto, ya funcionaría. :-) Pero queremos algo más. Por ejemplo, que los usuarios normales (no solo root) también puedan hibernar la máquina. Para ello, editamos /etc/sudoers y añadimos una linea:

%users lynette = NOPASSWD: /usr/local/sbin/hibernate *

De esta forma, cualquier usuario del grupo users, en la máquina lynette, podrá ejecutar "sudo /usr/local/sbin/hibernate opciones" sin necesidad de hacerse root ni contraseñas. Además, hay alguna opción que deberíamos revisar en /etc/hibernate/hibernate.conf:

UseDummyXServer yes   #Deberíamos poner esto, por tener una ATI Radeon.
GentooModulesAutoload yes #Si usamos Gentoo, esta opción lo hará más estable.
Unmount /mnt/windows  #Desmontar la partición windows antes de hibernar...
Unmount /mnt/fedora   #Y también la de Fedora Core.
OnResume 20 mount /mnt/windows # Y montar ambas 20 seg. tras haber reiniciado
OnResume 20 mount /mnt/fedora

Es especialmente importante lo que desmontar las particiones ajenas antes de hibernar, y remontarlas después de reiniciar. Es automático, así que no nos molesta. Pero imaginaos: hibernais con un programa accediendo a esas particiones. Al dia siguiente arrancais con Windows, o Fedora, con lo que estais cambiando esas particiones. Al día siguiente reiniciais con Gentoo, que asume que todo está como lo había dejado, incluyendo los datos de Fedora y Windows. ¿Resultado?: ¡Corrupción de datos!. Con estas opciones, en cambio, la hibernación desmonta las particiones con lo que hiberna creyendo que no existen: no hay peligro de corrupción.

¿Queda algo más?. ¿No?. Pues rebotamos la máquina y arrancamos nuestro kernel parcheado. Nos logamos, arrancamos un terminal, y ejecutamos "sudo /usr/local/bin/hibernate". El ordenador se hiberna y se apaga delante de nuestras narices. Pulsamos el botón de arranque y seleccionamos el mismo kernel. El ordenador renace tal y como lo habíamos dejado. Et voilá!. :-D

 

¡Mi lápiz USB ha dejado de funcionar!

Confiésalo. Has estado jugando con la BIOS, ¿verdad?.

Esto me ocurrió a mí, y debo decir que me provocó más de un dolor de cabeza hasta que descubrí lo que había pasado. Después, siguió doliéndome porque me daba de cabezazos, claro. :-)

Resulta que un día descubro que mi lápiz USB Memorybird ya no podía montarse en /dev/sda1, porque siempre decía que no era un dispositivo de bloque válido. Como era un kernel recién compilado, pensé que me lo había cargado así que era cuestión de añadir un módulo aquí y otro allá y recompilar de nuevo.

Que si naranjas de la china. Recompilé y recompilé una y otra vez. Kernels 2.4.24, 2.6.3, incluso el original 2.4.22 que viene con Fedora Core. Y nada... imposible... hiciera lo que hiciera, /dev/sda1 nunca era un dispositivo de bloques válido. Curiosamente, el lápiz USB sí era reconocido correctamente si arrancaba el ordenador con él puesto. Pero luego no podía quitarlo, porque empezaban a salir multitud de errores en dmesg y ya no podía volverlo o poner (otra vez dispositivo no válido).

Al final, me dio por arrancar mi vieja Knoppix desde CD, para ver qué módulos se cargaban. Y hete aquí que Knoppix tampoco lo reconoce... Esto no es el kernel, deduzco. Esto es hardware, porque mi Knoppix nunca me ha fallado y recordaba perfectamente que sí lo reconocía en este mismo ordenador.

¿Te ocurre a tí?. Pues anda, entra en la BIOS y desactiva otra vez la opción que pone "USB Legacy support", que seguro que la has activado la última vez que entraste. Y ya está. Eso solucionó todos mis problemas y el lápiz USB volvió a comportarse como siempre con todos los kernels.

¿Para qué sirve "USB Legacy support"?. Convierte los dispositivos USB en fijos, no removibles. Son reconocidos en el arranque, y a partir de ahí se comportarán como si estuvieran incorporados de serie al hardware. Sirve para tres cosas: para poner un ratón USB externo que vas a usar hasta que apagues el ordenador, para poner un teclado USB externo, y para hacer que una unidad de disco USB se comporte como disco duro fijo.

¿Y esto último pa qué sirve?. Para hacer que el ordenador pueda arrancar desde el lápiz USB, por ejemplo. :-) Lo interpretará como disco duro, y podrá arrancar desde él. ¿Recuerdas que este ordenador no tiene disquetera?. Pues ahí tienes un sustituto perfecto. Eso sí, si arrancas desde USB, luego no tiene sentido quitarlo porque colgaría el sistema. De ahí que no te deje. En la práctica, causa más problemas de los que soluciona, sinceramente. Habiendo CD-ROM arrancables, ¿para qué quiero USB?. Me viene mucho mejor que se comporten como siempre, como unidades extraibles, así que hazme caso y desactiva esa opción. Te ahorrará problemas.

 

Con kernel 2.6 el USB solo funciona en 1.1: no detecta USB 2.0

Ejecuta este comando:

	[13:51:01/0][lacofi@lynette:~]$ /sbin/lspci | grep USB
	00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 03)
	00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 03)
	00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 03)

Ahora añade este parámetro a tu kernel: acpi=off, por ejemplo modificando Lilo así:

	image=/boot/vmlinuz-estable
        vga=791
        label=Estable
        root=/dev/hda8
        append="hdc=ide-cd acpi=off"
        read-only

Ahora ejecuta /sbin/lilo y rebota la máquina. Vuelve a ejecutar el primer comando. Ahora deberías ver esto:

	[14:01:23/0][lacofi@lynette:~]$ /sbin/lspci | grep USB
	00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 03)
	00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 03)
	00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 03)
	00:1d.7 USB Controller: Intel Corp. 82801DB USB2 (rev 03)

Como ves, desactivando ACPI se detecta un nuevo dispositivo, el USB 2.0. Sin embargo, esto no es una solución, porque no es aceptable desactivar ACPI en nuestro portátil.

El problema está en que la ACPI de este ordenador, desactiva el USB 2.0 (y quizás alguna cosa más), si el sistema operativo no se identifica a sí mismo como Windows ante la ACPI. Asombroso, ¿verdad?. No es un fallo de Linux, sino de la ACPI del ordenador. Y tampoco es un fallo, puesto que es una restricción puesta a propósito. "Una funcionalidad", dirían ellos, la madre que los parió...

Afortunadamente, nuestro Linux es más listo que todo esto, como puedes comprobar en Bugzilla de RedHat. Resumiendo, solo hay que pedirle que se identifique ante la ACPI con otro nombre. Para ello, modifica Lilo para añadir un nuevo parámetro de kernel, así:

	image=/boot/vmlinuz-estable
        vga=791
        label=Estable
        root=/dev/hda8
        append="hdc=ide-cd acpi=on acpi_os_name=MicrosoftWindows2000"
        read-only

Ejecuta "lilo" y rebota la máquina. Comprueba lspci. Ahí lo tienes :-)

Bien, lo cierto es que ACPI no comprueba el texto, sino solo la longitud de la cadena, por lo que el nombre que use el kernel para identificarse no tiene por qué ser "MicrosoftWindows2000", sino que vale cualquiera, mientras tenga 20 caracteres de largo y sean alfanuméricos (no valen espacios, ni guiones, solo números y letras).

Gracias a Jose por avisarme de este problema. ;-)

 

¿Puedo aprovechas las teclas "Easy" de mi teclado?

Sí. Instala el programa acme, disponible en casi todos los repositorios de linux. Con él puedes asignarle alguna función especial a esas teclas (la que quieras, es programable), y también a combinaciones con otras teclas, como por ejemplo Fn + AvPag para bajar el sonido o Fn + RePag para subirlo.

Sin embargo, acme tiene los días contados y se considera obsoleto. Una buena altenativa sería el programa xhkeys, también disponible en muchos repositorios, como el de Gentoo. Se configura en modo de texto, ejecutando xhkconf y siguiendo las instrucciones en pantalla. Una vez configurado, hay que ejecutar el demonio xhkeys, lo que se puede hacer linkandolo a Autostart en KDE, tal que así:

[20:45:42/0][lacofi@lynette:~]$ cd .kde/Autostart
[20:45:45/0][lacofi@lynette:~]$ ln -s /usr/bin/xhkeys xhkeys

Con esto, cada vez que arranquemos KDE, el demonio que permite el acceso a las Easy Keys estará ahí.

 

Con kernel 2.6.3, la batería parece descargarse de golpe

En este ordenador solo podrás monitorizar el estado de tu batería utilizando ACPI. Eso puedes hacerlo con el kernel original de Fedora, por ejemplo, pasándole al kernel la opción "acpi=on" (en Lilo). Ahora bien, si compilas un kernel 2.6.3, te encontrarás conque, al poco tiempo de usar el ordenador, de repente parece que la carga de la batería cae a cero. Naturalmente, es un error de monitorización, porque la batería está funcionando correctamente, como comprobarás si rebotas y rearrancas con un kernel de la serie 2.4. Bien, pues con el 2.6.3, si consultas dmesg cuando ocurre este problema, verás un error repetitivo que se parece a esto:

	ACPI-0279: *** Error: Looking up [BBST] in namespace, AE_ALREADY_EXISTS
	ACPI-1120: *** Error: Method execution failed [\_SB_.PCIO.LPCB.BAT0._BST] 
				(Node dff5f780), AE_ALREADY_EXISTS
	ACPI-0279: *** Error: Looking up [BBST] in namespace, AE_ALREADY_EXISTS
	ACPI-1120: *** Error: Method execution failed [\_SB_.PCIO.LPCB.BAT0._BST] 
				(Node dff5f780), AE_ALREADY_EXISTS
	ACPI-0279: *** Error: Looking up [BBST] in namespace, AE_ALREADY_EXISTS
	ACPI-1120: *** Error: Method execution failed [\_SB_.PCIO.LPCB.BAT0._BST] 
				(Node dff5f780), AE_ALREADY_EXISTS
	ACPI-0279: *** Error: Looking up [BBST] in namespace, AE_ALREADY_EXISTS
	ACPI-1120: *** Error: Method execution failed [\_SB_.PCIO.LPCB.BAT0._BST] 
				(Node dff5f780), AE_ALREADY_EXISTS
	ACPI-0279: *** Error: Looking up [BBST] in namespace, AE_ALREADY_EXISTS
	ACPI-1120: *** Error: Method execution failed [\_SB_.PCIO.LPCB.BAT0._BST] 
				(Node dff5f780), AE_ALREADY_EXISTS
	ACPI-0279: *** Error: Looking up [BBST] in namespace, AE_ALREADY_EXISTS

Si éste es tu caso, te diré que acabas de tropezarte con un bug gordísimo en los kernel 2.6.3. Las buenas noticias es que la comunidad Linux ya lo sabe, y que la solución ha ido bastante rápido puesto que afecta a multitud de ordenadores portátiles de última generación, no solo a este Highscreen. Aunque pueden cambiar ligeramente los códigos que aparecen en las salidas de dmesg, pero se reconoce fácilmente que el fallo es del mismo tipo.

El bug todavía no estaba solucionado en los kernels 2.6.4, pero parece que sí ha sido corregido en el 2.6.5, que es el que estoy usando yo en el momento de escribir estas líneas. Si no quieres estar a la última y prefieres usar algo más testado, puedes utilizar el kernel 2.6.2, que es el último que funcionaba correctamente. De todas formas, yo personalmente te recomiendo el 2.6.6 o superior. Además de funcionar sin problemas son los primeros kernel que incluyen el "Pentium M" dentro de "Processor family", que es exactamente el procesador que utiliza éste portátil.

 

¿Me pasas la configuración de tu kernel?

Claro. Actualmente utilizo un kernel 2.6.7. Puedes consultar el apartado status para ver lo que funciona y lo que no, aunque esta máquina funciona en general bastante bien con linux, sobre todo si te atreves a recompilar este kernel. Desde que empecé con esto de los kernels, le he ido cogiendo vicio, así que periódicamente voy subiendo mis configuraciones para quien le interese. Que las disfrutes.

Copia este fichero a tu /usr/src/linux, suponiendo que tu kernel sea el 2.6.7, aunque es posible que esta misma configuración también funcione con el resto de la serie 2.6.x. Renombra el fichero a ".config" y ejecuta make menuconfig. No cambies nada, si no quieres: simplemente vuelve a salir y cuando pregunte dile que sí, que grabe la configuración. Luego ejecuta make y make modules_install para compilar el kernel.

Esta configuración de kernel soporta todo el hardware de mi Highscreen CL50, excepto el módem interno (hay que instalarlo aparte), el Wireless (hay que instalarlo aparte, pero por lo menos activa todo lo necesario para hacerlo, como CONFIG_NET_RADIO y los módulos criptográficos). También queda pendiente alguna cosilla especial que te interese (como VMWare, que habría que reconfigurarlo de nuevo). Para ponerlo en marcha una vez compilado, habría que meter una entrada en lilo.conf tal que así:

	image=/boot/vmlinuz-2.6.7
		label=Estable
		vga=791
		root=/dev/hda8     # (o la que tú uses)
		append="hdc=ide-cd nomce acpi=force"
		read-only

Que lo disfrutes.

 

He recompilado mi kernel, pero ahora no funcionan los gráficos.

Si has actualizado alguna vez tu kernel, tal vez hayas comprobado que una vez recompilado e instalado, es muy posible que dejen de funcionar algunas cosas como la red WiFi, los gráficos (X Window), etc.

Ocurre que hay una serie de funciones en el sistema que se compilan como módulos del kernel. Por eso, si has cambiado de kernel, los modulos ya no están o, aunque estén, posiblemente no sirvan porque son de versión incorrecta.

La solución es muy simple: tendrás que recompilar también todo ese software, cada vez que cambies o recompiles tu kernel. En el momento de redactar estas líneas, el software de mi ordenador portátil que es "sensible a la recompilación del kernel" es: El subsistema de red ieee80211, el driver WiFi (ipw2100), el driver del linmodem SmartLink 56K AC'97 (slmodem), y el driver propietario ATI (ati-drivers).

De esta forma, cada vez que recompilo mi kernel, después tengo que hacer (en un sistema Gentoo):

[lacofi@lynette ~]$ su
password:
[root@lynette /home/lacofi]# emerge ieee8011 &&
> emerge ipw2100 &&
> emerge slmodem &&
> emerge ati-drivers