Guía de estabilidad hardware Linux, Parte 2

1.  Controladores (drivers)

Muchas causas de inestabilidad

Un problema de estabilidad puede no tener su causa en hardware defectuoso, sino en la configuración inadecuada del hardware o en malos controladores. Mi experiencia en este área comienza cuando traté de hacer funcionar Linux con mi Diamond Viper V550, una tarjeta AGP basada en NVIDIA TNT, usando los controladores acelerados propietarios de NVIDIA.

NVIDIA tiene sus propios controladores gráficos para Linux, una colaboración entre NVIDIA, SGI, y VA Linux. Estos controladores tienen muchas ventajas con respecto a los controladores NVIDIA, 2D únicamente, incluidos con Xfree86 4.0. Tienen soporte para la aceleración 3D. Aún mejor, incluyen la implementación oficial de OpenGL 1.2, en lugar de una versión mejorada de Mesa. Todo en uno. Estos controladores acelerados son los que se querrán usar si se dispone de una tarjeta gráfica basada en NVIDIA, por lo menos en teoría. Mi intento de ponerlos en funcionamiento adecuadamente, resultó ser una excelente experiencia de aprendizaje, por decir lo mínimo.

Después de haber instalado los controladores acelerados de NVIDIA para Linux (ver Recursos más adelante en este artículo), inicié Xfree86 y me puse a jugar con mis aplicaciones 3D, ahora maravillosamente aceleradas como debían haber estado siempre. Antes de llegar a este punto, tenía que reiniciar en Windows NT para obtener la ventaja de la aceleración 3D. Mientras que no me importa NT, tener que reiniciar para poder usar aplicaciones 3D era realmente molesto, y estaba encantado de tener una razón menos para tener que dejar Linux y reiniciar mi máquina. De cualquier forma, después de estar investigando durante una hora o así, mis aspiraciones 3D bajo Linux sufrieron una gran decepción -- mi máquina se bloqueó. El ratón sencillamente se detuvo, la pantalla se congeló y tuve que reiniciar el sistema.

Sí, tenía algún tipo de problema de estabilidad. Pero no sabía exactamente lo que estaba causando el problema. ¿Tenía hardware con problemas o estaba la tarjeta mal configurada? O podía ser un problema con el controlador -- ¿Por algún motivo no le gustaba mi placa madre Athlon VIA KT133? Cualquiera que fuera el problema, quería resolverlo rápidamente. En este artículo, comparto el procedimiento que seguí para solucionar mi problema de estabilidad hardware. Aunque puede que no se tenga exactamente el mismo problema, los pasos que seguí para diagnosticar y resolver el problema son de naturaleza general y aplicables a muchos tipos de problemas con el hardware bajo Linux.

Primero, el hardware

La primera cosa que se me pasó por la mente fue que tenía un hardware defectuoso o no adecuadamente refrigerado. Por un lado, mi tarjeta Diamond Viper V550 parecía no tener problemas bajo Windows NT. Por otro lado, quizá Linux estaba usando el chip de forma más agresiva y estaba causando bloqueos relacionados con el calor producido al mismo. Mi V550 se puso extremadamente caliente y el disipador OEM parecía inadecuado. La combinación de los bloqueos y del hecho de que la tarjeta no se estaba enfriando adecuadamente me convenció para echar un vistazo a "PC Power and Cooling" (ver Recursos) para comprar un mini disipador/ventilador para mi V550.

Así que recibí mi sistema de refrigeración Video Cool, quité el disipador OEM de la tarjeta (perdiendo la garantía), limpié el chip TNT y fijé el Video Cool en lo alto del chip. ¿Qué ocurrió? mi tarjeta gráfica no se calentó nunca más excesivamente, pero los bloqueos continuaron. La lección que aprendí de esta experiencia en concreto es esta -- si nos aseguramos de que nuestro sistema está adecuadamente refrigerado para empezar, nunca nos tendremos que preocupar acerca de componentes que estén funcionando mal debido a una inadecuada refrigeración. Esto, por sí mismo, es una buena razón para invertir algún tiempo y esfuerzo en asegurarnos de que nuestras estaciones de trabajo y servidores funcionan fríamente. Ahora que me había encargado del problema del calor, supe que los bloqueos no se debían a un hardware defectuoso y tenía que empezar a buscar el problema en otra parte.

Nuevos controladores -- ¿y una posible solución?

Sospechaba en parte que los controladores de NVIDIA eran la causa del problema. Afortunadamente, se acababa de realizar una nueva versión de los controladores, así que actualicé con la esperanza de que ello resolviese mis problemas de estabilidad. Pero no fue así, y después de comprobar con otras personas en el canal #nvidia de openprojects.net que, aunque no todo el mundo era capaz de usar el controlador con estabilidad, había mucha otra gente para la que estaba funcionando perfectamente.

En #nvidia, alguien sugirió que tratase de asegurarme de que la V550 no estaba compartiendo una IRQ con cualquier otra tarjeta. Al contrario que con el controlador estándar de XFree86, el controlador acelerado de NVIDIA requería el uso de una IRQ en exclusiva para funcionar adecuadamente. Para ver si tenía su propia IRQ dedicada, tecleé cat /proc/interrupts, y resultó que mi V550 estaba compartiendo la interrupción con la controladora IDE. Antes de explicar cómo resolví este problema en concreto, quiero profundizar algo más en las IRQs.

Los PCs usan IRQs, e interrupciones hardware en general, para permitir a los periféricos, tales como la tarjeta gráfica y la controladora de discos, enviar una señal a la CPU indicándole que tienen datos listos para ser procesados. En tiempos en los que el bus PCI aún no existía, era algo completamente indispensable que cada dispositivo en la máquina tuviese asignada su propia IRQ dedicada. En el caso de que aún se estén usando periféricos ISA en la máquina, esto sigue siendo cierto -- todos los periféricos no PCI deben tener su propia IRQ dedicada.

2.  IRQs

IRQs y PCI

De cualquier forma, las cosas son algo distintas con el bus PCI. PCI localiza cuatro IRQs que pueden usarse para las tarjetas PCI/AGP en el sistema. En general, estas interrupciones pueden compartirse entre múltiples dispositivos. (Si se hace esto, hay que asegurarse de que todos los dispositivos compartiéndolas son PCI y AGP.) Compartir las IRQ es importante, especialmente para máquinas modernas que cuentan con cinco ranuras PCI y una AGP. Sin compartir las IRQ, sería imposible tener más de cuatro tarjetas usando una IRQ en el sistema

De todos modos, hay algunas limitaciones al compartir IRQ PCI. Mientras que las BIOS de las placas madre modernas y el núcleo de Linux normalmente soportan que se compartan las interrupciones, algunas tarjetas PCI pueden sencillamente negarse a funcionar correctamente cuando comparten la IRQ con cualquier otro dispositivo. Si se están experimentando bloqueos aleatorios del sistema, especialmente cuando se dan precisamente al usar un dispositivo hardware, puede tratarse de hacer que todos los dispositivos PCI usen su propia IRQ, solo para asegurarnos. El primer paso es ver si algunos de los dispositivos en nuestro sistema están compartiendo una IRQ. Para hacer esto, seguimos estos pasos:

1. Usar los dispositivos hardware del sistema, tales como el disco, el sonido, vídeo, SCSI, etc. Con ello nos aseguramos de que Linux maneja las interrupciones para todos estos dispositivos.
2. cat /proc/interrupts, mostrará una lista en la que se reflejan todas las interrupciones manejadas por el núcleo. Hay que fijarse en la columna de la derecha. Si dos o más dispositivos aparecen en una única línea, entonces están compartiendo dicha IRQ.

Si uno de los dispositivos en cuestión no es un dispositivo PCI (ISA u otra tarjeta antigua) entonces hemos encontrado un conflicto IRQ, que podemos tratar de resolver desde la BIOS, el paquete isapnptools, o los puentes configurables (jumpers) en la tarjeta. Hay que notar que si un periférico se encuentra integrado en la placa madre, es probablemente un dispositivo PCI aunque no ocupe una ranura PCI.

Si todos los dispositivos en cuestión son dispositivos PCI o AGP, entonces si se puede tener o no un problema depende de nuestro hardware. He aquí algunos pasos a seguir para intentar configurar todos nuestros dispositivos PCI/AGP para que únicamente usen su propia IRQ:

1. Entrar en la BIOS del sistema y deshabilitar todos los periféricos que no usemos (USB, puerto paralelo, etc.) Esto puede liberar algunas IRQs, dando a cada dispositivo una oportunidad mayor de que se le asigne únicamente su propia IRQ.
2. Entrar en la sección PnP de nuestra BIOS y asegurarnos de que nuestra BIOS está configurada para ejecutar un sistema operativo "non-PnP". Entonces seleccionamos la opción "Reset ESCD data". Esto obligará a la BIOS a reasignar IRQs a todos nuestros dispositivos la próxima vez que reiniciemos.
3. Iniciamos Linux, usamos nuestro hardware, cat /proc/interrupts y vemos el resultado. Sería de esperar que todos nuestros dispositivos usasen su propia IRQ.

Si los dos dispositivos PCI sospechosos siguen compartiendo IRQs, aún tenemos dos opciones adicionales. Algunos programas de configuración de la BIOS permiten asignar una cierta IRQ a una ranura PCI. Si se tiene uno de estos programas de configuración de la BIOS, se puede usar esta funcionalidad para eliminar el conflicto. Si no se tiene esta opción en la BIOS (la gran mayoría de nosotros no la tiene, dado que solo está presente en muy pocas de ellas), hay otra posible solución segura para ello -- apagamos el sistema, lo desenchufamos de la toma eléctrica y esperamos unos minutos. Entonces abrimos la carcasa y movemos físicamente las tarjetas PCI a diferentes ranuras. Esta solución puede parecer un poco rara, pero funcionará definitivamente y es especialmente efectiva si se tienen algunas ranuras PCI libres en el sistema (aunque puede llevarnos algún tiempo encontrar la ranura correcta para cada una de las tarjetas).

He realizado el "truco de barajar las tarjetas" y fui capaz de lograr que todos los dispositivos en mi sistema usen una única IRQ. Bueno, casi. Como puede verse, dos de mis dispositivos IDE siguen compartiendo una IRQ:

# cat /proc/interrupts
           CPU0
  0:   52063600          XT-PIC  timer
  1:     616810          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:      89084          XT-PIC  ide2, ide3
  7:    1515741          XT-PIC  eth0
  8:     155928          XT-PIC  rtc
  9: 1139761505          XT-PIC  nvidia
 10:     164000          XT-PIC  Ensoniq AudioPCI
 12:    4458823          XT-PIC  PS/2 Mouse
 14:     664176          XT-PIC  ide0
 15:      38661          XT-PIC  ide1
NMI:          0
ERR:          0

De todos modos, esto es normal dado que los dispositivos ide2 e ide3 están integrados en el mismo chip de mi tarjeta IDE Promise FastTrak.

Así que, ahora que (casi) todos mis dispositivos tienen una única IRQ, probé mis controladores acelerados de nuevo y ... experimenté un bloqueo en menos de una hora. Aparentemente, el hecho de la IRQ compartida no era la causa del problema en absoluto. Bien... tiempo para seguir buscando por cualquier otra parte (de nuevo).

Resolver un problema para encontrar otro

Después de algún tiempo, encontré otra cosa que podía hacer para que los controladores NVIDIA funcionasen perfectamente, aunque bastante más lentamente -- deshabilitar AGP. Yo no quería hacer esto, pero la versión actual de los controladores permitían deshabilitar AGP sencillamente añadiendo una única línea a XF86Config. Con AGP deshabilitado, reduciría el ancho de banda del vídeo a la memoria 4x, pero tener 3D mucho más lento sería aún mejor que no tener aceleración 3D en absoluto. Después de deshabilitar AGP, finalmente tuve un sistema estable. Pero esta solución temporal creó otro problema. Cada vez que se reproducía una animación 3D OpenGL, la reproducción de sonido empezaba a ser confusa y entrecortada.

Afortunadamente, fui capaz de encontrar una solución a mi problema con el audio. Usé la utilidad setpci para ajustar más adecuadamente el temporizador de latencia del bus PCI para mis dispositivos PCI. Mostraré la solución específica en un minuto -- pero primero, algo de trasfondo.

Como probablemente se sabrá, el bus PCI es un recurso compartido -- todas las tarjetas PCI cogen su turno para comunicarse por el bus, y normalmente, todo va bien. De cualquier forma, dado que el bus PCI es un recurso compartido con un limitado (aunque normalmente adecuado) ancho de banda, es posible que una tarjeta PCI afecte negativamente al rendimiento del resto de las tarjetas PCI en el sistema. Por ejemplo, ¿qué ocurre cuando la tarjeta PCI A se encuentra enviando datos por el bus y en el mismo momento la tarjeta B intenta enviar datos?, ¿permite la tarjeta A que la otra tarjeta use el bus o continúa con su transferencia de datos -- y de ser así, durante cuánto tiempo?

3.  Latencia PCI

Temporizador de latencia PCI

La respuesta a esta pregunta está relacionada con un ajuste configurable que cada dispositivo PCI tiene, el temporizador de latencia del bus PCI. Normalmente es el controlador de Linux el que se encarga de ajustar el temporizador de latencia del bus PCI para cada dispositivo PCI en nuestro sistema, y la mayoría de las veces los valores por defecto son adecuados (si no óptimos), todos los dispositivos obtienen su valor y el sistema funciona adecuadamente. El temporizador de latencia del bus PCI puede ir desde cero a 248. Si un dispositivo tiene un valor de cero en el mismo, entonces dejará disponible el bus en cuanto otro dispositivo trate de transmitir datos. Si el dispositivo tiene un valor de 248, continuará usando el bus durante un periodo mayor de tiempo antes de parar, mientras que el otro dispositivo espera a que llegue su turno.

Si todos los dispositivos PCI tienen un valor alto en el temporizador de latencia del bus PCI y se está enviando mucha información a través del bus, entonces las tarjetas PCI del sistema tendrán que esperar mucho más hasta que puedan tomar el control del bus y puedan enviar los datos. De todos modos, una vez que tomen el control del bus serán capaces de enviar muchos datos más a través del mismo antes de que liberen el bus para cualquier otro dispositivo. Este es el motivo de que los ajustes del temporizador de latencia del bus PCI incrementen la latencia (el retardo en enviar datos a través del bus), aunque también incrementan el ancho de banda efectivo. Dado que cada dispositivo tiene la oportunidad de enviar grandes cantidades de datos sin interrupción, el bus PCI se usa más eficientemente y los dispositivos PCI pueden transmitir muchos más datos.

Por otro lado, si todos los dispositivos PCI tienen configurada la latencia del bus PCI con valores bajos, entonces cederán amablemente el bus si cualquier otra tarjeta necesita transmitir datos. Esto tiene como resultado una transferencia de datos con una latencia mucho más baja, dado que ningún dispositivo va a mantener el bus durante un periodo de tiempo elevado, ocasionando que otros dispositivos esperen. El gran inconveniente de todo esto es que un valor bajo del temporizador de latencia del bus PCI reducirá el ancho de banda efectivo del bus PCI cuando dos dispositivos PCI estén funcionando simultáneamente. Esto ocurre debido a que las grandes transferencias de datos son mucho menos frecuentes y el control del bus cambia rápidamente, incrementando la sobrecarga.

La mayoría de distribuciones Linux incluyen un conjunto de herramientas llamada pci-utils que permiten ver y cambiar el temporizador de latencia del nuestros dispositivos PCI. Para ver la configuración de la latencia actual PCI, podemos teclear:

# lspci -v

Teclear este comando mostrará información muy detallada acerca de todos los dispositivos PCI. El ajuste de latencia PCI de cada dispositivo se muestra en la tercera línea, justo antes de la IRQ asignada.

Enfoque de la latencia PCI

¿Cómo se relaciona esto con mi problema de sonido distorsionado? Bien, mi sonido se estaba distorsionando debido a los ajustes de latencia PCI que tenía, la tarjeta V550 dominaba el bus PCI cuando realizaba aceleración 3D. He aquí el porqué. Mi V550 es una tarjeta AGP 2X, así que cuando quité el AGP (para incrementar la estabilidad), ¡reduje el ancho de banda de la tarjeta a la memoria principal en un 75%! Dado que mi V550 estaba intentando transmitir la misma cantidad de datos a través del bus PCI más lento, el bus estaba alcanzando el 100% de uso, y ello causaba problemas a mi hardware de sonido. Los dispositivos de sonido son muy susceptibles a problemas de latencia PCI debido a que la memoria intermedia de datos (buffer) en los mismos es muy reducida y necesitan que les lleguen todos los datos antes de que se agote la misma. Con mis ajustes, la V550 estaba usando demasiado ancho de banda PCI como para permitir a la tarjeta de sonido recibir datos. Así pues, escuchaba el sonido distorsionado debido a que la memoria intermedia de la tarjeta de sonido se quedaba sin datos.

Hay dos posibles soluciones a este problema. La primera y la más obvia de ellas sería usar el comando setpci para reducir la latencia del temporizador PCI de mi tarjeta V550. Esto ocasionaría que compartiese el bus PCI más a menudo, permitiendo a mis otros dispositivos transmitir sus datos con menor latencia. Intenté esta solución con el comando setpci y funcionó. De todos modos, decidí no seguir este camino dado que quería maximizar el rendimiento ya bastante reducido de las 3D en mi tarjeta, en lugar de disminuirlo aún más.

Decidí intentar una segunda opción con el mayor rendimiento posible. En lugar de reducir la latencia del bus PCI en mi tarjeta V550, incrementé la latencia PCI de todos mis dispositivos al valor relativamente alto 176 (los dispositivos normalmente usan por defecto un valor alrededor de 32, excepto para mi V550 que tenía un valor por defecto superior a 200). Entonces configuré la latencia del bus PCI para los dispositivos sensibles a dicha latencia al máximo valor, 248. Esto resolvió el problema, como había esperado, permitiendo a la tarjeta de sonido recibir grandes porciones de datos por el bus de una pasada, permitiéndole maximizar el uso del bus y evitando que la memoria intermedia se quedase sin datos. Al mismo tiempo, mis otros dispositivos podían transmitir datos en cantidades suficientes como para no ocupar todo el bus, pero suficientemente grandes como para manejar el bus eficientemente. Estaba encantado con esta solución dado que había sido capaz de resolver mi problema con el sonido mientras que al mismo tiempo había incrementado el ancho de banda efectivo del bus PCI en mi máquina de desarrollo. He aquí una pequeña lista de los trucos que las macros de inicio del sistema realizaban para lograrlo:

# "apertura" del bus PCI permitiendo que todos los dispositivos puedan
# transmitir grandes fragmentos de datos, incrementando el rendimiento
setpci -v -d *:* latency_timer=b0

# maximizar los temporizadores de latencia para la red y el audio,
# permitiéndoles transferir más datos en cada turno, para prevenir las
# condiciones de exceso/falta de datos en la memoria intermedia

setpci -v -s 00:0f.0 latency_timer=ff
setpci -v -s 00:0e.0 latency_timer=ff

En la primera linea, la opción -d *:* indica a setpci que aplique este ajuste a todos los dispositivos PCI. La opción latency_timer=b0 ajusta el temporizador a 176 (b0 es en hexadecimal 176). Las opciones -s en las dos últimas líneas especifican el dispositivo PCI al que afectarán según el bus/ranura y la función, en lugar de por el fabricante y la ID del dispositivo. Estos son los primeros números que se indican para cada dispositivo cuando se teclea lspci. El valor ff especifica un temporizador de latencia de 256, que setpci redondea a 248. Si se están teniendo problemas con el temporizador de latencia PCI, se necesita experimentar con lspci y setpci para encontrar los valores óptimos para nuestro sistema. Si nuestro hardware puede manejarlos, los valores del temporizador de latencia del sistema mayores son mejores.

Recursos

Espero que se haya encontrado mi solución de problemas hardware tan instructiva como lo fue para mí. Estoy esperando pacientemente a la siguiente versión de controladores de NVIDIA, para ver si resuelven mis problemas relacionados con la inestabilidad AGP. A continuación hay varios recursos relacionados con NVIDIA que pueden resultar interesantes.

• Leer el anterior artículo de Daniel de esta serie, Guía de estabilidad hardware Linux, Parte 1, donde muestra cómo diagnosticar y reparar problemas con la CPU, así como comprobar los defectos de la RAM.
• Comprobar los Controladores acelerados para Linux de NVIDIA.
• Si se está tratando de diagnosticar un problema hardware relacionado con nuestra tarjeta gráfica NVIDIA, hay que asegurarse de comprobar PUF GeForce. Tiene mucha información relacionada tanto con Windows como con Linux.
• Para más información relacionada con la resolución de problemas nVidia, comprobar la Guía nVidia de Sven Vermeulen.
• Quizá quiera comprobarse el proyecto Linux Powertweak. Powertweak permite configurar los parámetros del temporizador de latencia PCI (además de otras cosas) usando una interfaz basada en GTK y en la consola.
• Visitar PC Power and Cooling para adquirir cosas como los mini disipadores/ventiladores y el Video Cool.
• Comprobar la serie de refrigeradores Lasagna de Tennmax, que en mi experiencia tienen mayor capacidad para enfriar que Video Cool, aunque funcionan produciendo un poco más de ruido.

Acerca del autor

Daniel Robbins vive en Albuquerque, Nuevo Méjico. Fue el Presidente/CEO de Gentoo Technologies Inc., el Arquitecto Jefe del Proyecto Gentoo y contribuye como autor de varios libros publicados por MacMillan: Caldera OpenLinux Unleashed, SuSE Linux Unleashed, y Samba Unleashed. Daniel se ha visto involucrado en el mundo de las computadoras de algún modo desde segundo grado cuando se expuso al lenguaje de programación Logo y a una potencialmente letal dosis de Pac Man. Ésto probablemente explica porqué ha sido un artista de gráficos en SONY Electronic Publishing/Psygnosis. Daniel disfruta pasando el tiempo con su mujer Mary y con su hija, Hadassah. Se puede contactar con Daniel en Daniel Robbins.