Tráfico del Núcleo #97 For 11 Dec 2000

Gracias van a las varias gentes que escribieron para reportar que la versión lista para imprimir se descompuso la semana pasada. ¡No hubo una sola flama en el montón entero :-)! Lo siento por no responder personalmente a cada email, pero los leí todos. El problema, finalmente, fue una falta de espacio de disco en uno de nuestros servidores CVS, y tomó un rato mientras lo componían. ¡Gracias por los reportes, compañeros!

There were 369 different contributors. 158 posted more than once. 147 posted last week too.

Rik van Riel dijo a Alan Cox, "aquí está una compostura para un bug cegadoramente estúpido que ha estado en 2.2 por eras (y del cual te he advertido algunas veces en los últimos 6 meses, y para el cual he hasta enviado algunos parches.)" Él explicó, "Este parche debe hacer a la MV de 2.2 un poco más estable y también debe componer las quejas de gente cuyo sistema quedaba inundado por "VM: do_try_to_free_pages failed for process XXX"" Ville Herva confirmó el problema, y describió "2.2.18pre19, funcionando por 8 días, la máquina ha estado inactiva por horas. Entonces, de repente, obtengo 30 veces "VM: do_try_to_free_pages failed for kswapd...", después 15 "VM: do_try_to_free_pages failed for xmms...", después "VM: killing process xmms" y eso se repite por ~10 processes incluyendo X." Pero él también preguntó, "Ví el parche global de MV de Andrea siendo re comendado como una solución para este problema, y ya lo he compilado (aunque no he arrancado con él aún). ¿Debo usar el parche de Rik o de Andrea?" Y también pidió saber si alguno de ambos entraría a 2.2.18. Rik replicó, "Sobre si cualquiera de estas mejoras entrarán en el próximo 2.2, no te molestes en preguntarme porque no tengo intenció de poner mucha atención a 2.2" . Aquí siguió algo de discusión técnica sobre el parche de Rik y su interacción con ext3.

Mohammad A. Haque reportó errores de ext2 "Freeing blocks not in datazone" durante uso normal en 2.4.0-test11. Neil Brown replicó, "Oh, bueno. No soy sólo yo y Tigran entonces. Primero estaba culpando a mi código raid5 por esto, pero si tú lo tienes y Tigran lo tiene (reportado http://boudicca.tux.org/hypermail/linux-kernel/2000week48/0257.html) entonces probablemente no soy yo." agregó, "Ahora solamente si tuviéramos una forma confiable de reproducirlo, podríamos iniciar una búsqueda binaria para el parche que produce la falta... pero solamente lo puedo reproducir en un núcleo parchado después de varias horas de pruebas de rendimiento." Andries Brouwer replicó, "Tú lo tienes todo al revés. Sería bueno si sólo fueran tú y Tigran. Desafortunadamente también me pega." Alexander Viro comenzó publicando parches, aunque Mohammad y Tigran Aivazian habían tenido problemas reproduciendo los errores aún en sus configuraciones iniciales. En un punto, Neil remarcó, "Corrí mi guión de prueba, que construye una variedad de matrices raid5 con números de unidades y tamaños de bloques variables, y corre mkfs/bonnie/dbench en cada matriz, y lo hizo durante cerca de 8 sistemas de ficheros, pero se ahogó en el 9o tratando de reservar muchos bloques en la zona de sistema (después de correr por cerca de una hora)." Alexander replicó, "Sangrientamente interesante. No veo nada reciente que pueda afectar las áreas en cuestión. Versiones interesantes a revisar: 11-pre5 y 11-pre6. Huele como corrupción del caché de memoria temporal, per no veo nada relevante." Después él añadió, " Los mensajes de error serían interesantes... Hasta ahora tenemos involucrados a _ambos_ 2.95 y 2.91, tanto raid como no raid. Tan sólo excelente de mierda..."

En un punto Neil descubrió que su reporte no estaba relacionado a los otros, diciendo a Alexander, "Resulta que mis datos son una falsa alarma. Era un bug en mi código raid5 - y de hecho no es un bug reciente - que estaba causando mi corrupción de sistema de fichero. Así que si tus primeros parches funcionario para todos los demás entonces los pueden ver como una buena forma para continuar. He compuesto mi falta fatal y ya no puedo reproducir los problemas nunca más. El parche se ha enviado a Alan."

Otras gentes también reportaron corrupción, pero ni uno consiguió aislarlo durante la discusión. Para más sobre corrupción de sistema de archivos en las series de desarrollo, vea BROKEN KCREF

3. Las Distribuciones De Linux Haciendo Cambios Incompatibles A Herramientas Del Sistema

Jeff V. Merkey publicó un parche para modutils, para hacer compatible al programa 'depmod' con los guiones de Red Hat y programas como Anaconda. En el curso de la discusión, él explicó que su parche había cambiado muy pocas cosas, mientras que la alternativa era cambiar todos los cientos de guiones que lo requerían. David Ford dijo, "Es aún un mal precedente. Anaconda debía haber sido escrito correctamente en primer lugar." Mohammad A. Haque agregó, "Yo hubiera hecho que Anaconda cambiara en lugar de hacer casos especiales en las utilidades estándar para cuenta de manejo de las distribuciones." Jeff argumentó, refiriéndose al manejo de interruptores alternativos de la línea de comandos de Red Hat en depmod, "si RedHat se ha estandarizado en este conjunto de interruptores, ¿por qué no agregarlos como alias de órdenes? Es un parche trivial." David Ford replicó, "Entonces deja que RedHat mantenga su versión de modutils. RedHat no es el estándar ni RedHat debe dictar a los autores, ni otras distribuciones y personas deben ser afectadas por los métodos de RedHat. Si no te gusta, reemplaza tu depmod con un guión que quite este indicador antes de llamar al depmod original."

En otro lado, Keith Owens (el que mantiene modutils) dijo, "Tengo un gran problema con Redhat. Ellos hacen cambios incompatibles a las utilidades, no envían parches de regreso a los que mantienen y entonces esperan que el resto del mundo siga su liderato. Los indicadores -i y -m para modutils no son el único ejemplo, recientemente encontré parches para IA64 y Sparc que han agregado al código de modutils y no se han molestado en decírmelo. Otras distribuciones son mucho mejores acerca de enviarme parches, Debian y SuSe en particular hacen lo correcto." Añadió, "el parche "-m -i" es innecesario. Consideren esto mi protesta contra los malos hábitos de los distribuidores, ellos crearon la revoltura con su falta de comunicación y ellos tienen que componerlo." Jes Sorensen replicó:

Pienso que estás señalando un problema muy válido. El mismo problema existe dentro del núcleo, lo veo muy seguido que alguien decide hackear un controlador y enviar el parche a Linus sin molestarse siquiera en Cc al autor una copia. Algunas veces esto es 'sólo' para hacerlo cumplir con el último núcleo de desarrollo pero Cc al que mantiene no es mucho esperar.

También quisiera convocar a la gente a contactar a uno de mantenimiento si quieren hacer cambios extensos a un fragmento de código que alguien más mantiene. No es poco común que el que mantiene ya tiene una idea acerca de cómo hacer algo y hasta puede haber trabajado en eso. Es un desperdicio de su tiempo (y el de otras gentes) tener dos desarollos en conflicto como lo que está sucediendo.

El Tráfico del Núcleo primero cubrió esto en BROKEN KCREF, cuando ni uno parecía muy esperanzado acerca de tener APM funcionando adecuadamente en la laptop 5000e de Dell. Por BROKEN KCREF, parecía que mientras los fabricantes estaban trabajando en un BIOS actualizado que pudiera resolver el problema. Esta semana, Brad Douglas reportó:

Alan, aquí está la información DMI que solicitaste. Perdón por el retraso.

El BIOS mostrado es un BIOS de prueba nuevo que tiene un APM *corregido* que recibí esta mañana. Realmente quiero tomar un segundo para agradecer a la gente en Compal (BizCom) por el corto tiempo de resolución una vez que nos dimos cuenta quién era la gente correcta para hablar con ella.

Una vez que reciba OK de Compal (y termine de probar), lo publicaré al sitio de soporte de Tuxtops para que todos lo descarguen.

Linus Torvalds anunció 2.4.0-test12-pre2 y dijo, "Debido al nacimiento de mi tercera hija la semana pasada (sí, fuí ./ado), si me enviaron parches que no están en pre2, pueden muy bien considerarlos perdidos." Mucha gente ofreció sus felicitaciones, y Neil Brown preguntó en relación al núcleo, "¿Qué sucede con las cosas que entraron en 2.4.0test11-ac{1,2,3,4}? ¿Vas a "sincronizar" con Alan, o debemos enviar los fragmentos directamente a tí?" Alan Cox replicó:

Cuando Linus ponga pre3 comenzaré a enviarle cosas de mi árbol que prueben ser funcionales. Cosas que parezcan sospechosas y que necesiten más trabajo las mantendré en el árbol -ac y continuarán liberándose contra el código actual de Linus.

No me causa ningún problema si envías a Linus una copia, yo solamente lo retiraré de mis parches cuando aparezca en su árbol.

Alan me envía sus parches en pedazos pequeños de cualquier forma, y hace un buen trabajo al mantener las cosas separadas. Reenviarlo directamente a mí significa que Alan podría tan sólo retirar esa parte del parche - o que yo tendría el parche dos veces. Ambos de los cuales funcionan ok, mientras sea el _mismo_ parche.

Si has hecho modificaciones desde que enviaste la cosa a Alan, deberías sincronizar con Alan también - sólo para asegurarse de que no acaben aplicando aplicando las cosas antiguas a través de Alan.

Kurt Garloff reportó un ciclo infinito en modutils-2.3.21, donde PPP sobre ethernet recursaba sin fin en la función build_stack(). Incluyó el fichero 'modules.dep' para producir la conducta, y agregó, "Hay una dependencia circular de pppoe en pppox en pppoe en ... modprobe tiene código para detectar esto en build_stack(), pero parece no funcionar. La dependencia anterior es desechada y la nueva es tomada. Y revisa por dependencias de nuevo :-("

Keith Owens (el que mantiene modutils) replicó, "El código del núcleo está descompuesto. Las dependencias circulares no tienen sentido, el que mantiene pppoe coincide y yo pensé que ese bug estaba compuesto." Rod Stewart replicó, "Está compuesto en test10/11." Con respecto al código de modutils, Keith también agregó en el mismo mensaje:

Las dependiencias circulares no tienen soporte, ni son correctamente detectadas. El código existente para recorrer las relaciones inter módulos, incluyendo dependencias, alias, prueba, prueba-todo, declaraciones de antes y después es un relajo. Tan sólo creció durante los años con casos especiales siendo añadidos y no es robusto.

En modutils 2.5 el código completo será descartado y reemplazado con un algoritmo de recorrido de grafo estándar con detección de ciclos y rastreo hacia atrás en lugar de código de casos especiales. Esto podría cambia la conducta de modutils en casos raros y no quiero cambiar su conducta justo antes de que el núcleo 2.4 sea liberado. Tengo una lista de cambios que podrían descomponer la compatibilidad hacia atrás esperando por modutils 2.5, éste es uno de ellos.

Kurt dijo que él miraba hacia adelante a modutils 2.5, pero sintió que aún antes de esa versión liberada, "la conducta actual no es aceptable, ya que puede matar a la máquina por sólo ser invocado por kmod. Trataré de hacer que tenga sentido el código y asegurar que modprobe no se volverá loco, por detectar ciclos (si puedo hacer eso de alguna forma sin descomponer cosas) o por limitar la profundidad de la recursión. Te enviaré un parche." Publicó un parche la tarde siguiente, agregando, "Como la generación de dependencias me pareció de hecho bastante grande para mí, realmente no lo toqué. Solamente implementé el límite de recursión para prevenir que el proceso modprobe tome toda la memoria del sistema ..."

Tigran Aivazian reportó felizmente, "Sólo para hacer saber a la gente que 2.4.0-test12-pre3 se comporta mucho mejor que versiones anteriores en mi máquina de 6G de RAM. No solamente /proc/mtrr está mostrando correctamente todos los 6G en caché para escritura anterior sino también llegué hasta nunca tener que levantar/apagar una de las interfaces eepro100 para lograr que trabajaran -- algo que tenía que hacer en todas las versiones previas. (sin david-mtrr.patch)" Y Boszormenyi Zoltan replicó:

¡Excelente! :-))))

Dicho sea de paso lo que contiene test12-pre2/3 es el trabajo de David Wragg, actualizado al código de CPUID de HPA que está en test11. Linus me atribuyó incorrectamente todo el parche en test12.log.

John Fremlin reportó que la tarjeta de sonido Yamaha OPL3-SAx "está actualmente descompuesta para la gente cuyos BIOS la activaban con ISA PnP, ya que el núcleo ahora decide desactivarla." Él había enviado un parche al que lo mantiene un mes antes, sin respuesta. Publicó el parche (contra 2.4.0-test10-pre6 y test12-pre3) de nuevo a linux-kernel, y explicó, "Este parche implementa la prueba ISA PnP y activar/desactivar para la OPL3-SAx. Como yo no tengo las especificaciones para esta tarjeta, solamente sé que esto funciona para mí; de cualquier forma, no debe descomponer ninguna configuración ya que la prueba PnP solamente inicia si los parámetros del recurso no son dados como argumentos de módulo. Ahora debe ser posible compilar el controlador directamente dentro del núcleo." Scott Murray replicó, "Como el que mantiene en cuestión, me disculpo. He estado remiso en introducir un parche en 2.4 debido a estar enfocado en un nuevo trabajo. Mi plan actual es tomar el Viernes libre y trabajar en pegar todas las composturas que la gente me ha enviado juntas en un parche. Debo admitir, de cualquier forma, que he estado corriendo núcleos 2.4.0-test por algún tiempo y no he tenido ningún problema activando mi tarjeta OPL3-SA3 en la forma antigua con isapnp." Encontró algunos problemas con el parche de John, y reiteró que intentaría lograr un parche comprehensivo pronto.

9. Rarezas De struct De Tiempo Atrás Longtime struct Weirdness And Doc Bug; True Fix Planned For 2.5

Richard Pries publicó un parche, y explicó, "Actualmente, mmc_ioctl() en cdrom.c se le pasa una estructura cdrom_msf cuando ioctl() es llamado con CDROMREADRAW, CDROMREADMODE1, o CDROMREADMODE2 como su segundo argumento. Esta estructura no provee el almacenamiento temporal requerido para leer los datos, y no corresponde a la estructura que cdrom.h dice que hay que usar con estas llamadas ioctl(). Este parche reemplaza la estructura cdrom_msf con una estructura cdrom_read (como está especificado en cdrom.h). Las pruebas preliminares indican que este parche funciona para unidades IDE y SCSI." Pero Jens Axboe replicó, "Seguro apuesto que funciona, pero acabas de descomponer todos los programas que actualmente usan cualquera de los ioctls anteriores. Esto lo he sabido por años... Puedes hacer todo lo que quieras con cdrom_msf, es solamente más batalla. Para 2.5 introduciré variantes más nuevas de los ioctls anteriores y los mantendré tal cual por compatibilidad, desecharlos no es una opción. " Añadió, "¡Aunque tomaré un parche que corrija el comentario!" En otro lugar, bajo el Subject: [Patch] Correct cdrom.h comments., Richard publicó un parche para corregir los comentarios confusos en cdrom.h que lo habían conducido a su parche anterior. Jens le agradeció y lo aplicó.

Minutos después de que slashdot publicara su artículo diciendo que el llamado de Transmeta estaba limitado a cerca de 300 computadoras Fujitsu, corrí a Fry's y compré una Sony PictureBook PCG-C1VN. Gracias a los cielos por esos horarios de Navidad extendidos creo, mientras rezaba que las afirmaciones acerca de los problemas de Crusoe fueran así de limitados mostraran ser verdad.

Este dispositivo es la única computadora disponible comercialmente en el mundo que usa un procesador hecho por Transmeta (un 600MHz TMS5600, escalamiento 03). Pensé seguramente que habría una pequeña subcultura de usuarios de Linux PictureBook en transmeta asegurándose que esta combinación en particular funcionara.

Bueno, alas, parece que linux-2.4.0-test12-pre3 se congela duro mientras lee las direcciones de registro base del primer dispositivo PCI (el "host bridge"). De hecho, pienso que el problema es algún tipo de interrupción de administración de sistema que ocurre cerca de ese momento, ya que el punto exacto donde el printk se detiene llega antes mientras agrego más printk's. Con menos printk's el printk se detiene mientras la dirección base del 6to registro de configuración está siendo leído; com más printk's se detiene en el seguno, y se detendrá en diferentes lugares con diferentes arranques, por lo menos con los núcleos no-tan-de-fábrica que yo generalmente uso. También apagar las interrupciones durante este código no tiene efeto, así que no pienso que esté causado directamente por algo en el PictureBook sazonando el procesador con interrupciones inesperadas (pienso que podría tener que ver con el disco flexible basado en USB).

Además de los resultados de los printk's de depuración que agregé de un linux-2.4.0-tset12-pre3 algo modificado construido para CONFIG_M386, también intenté linux-2.4.0-test12-pre3 "prístino". Cuando lo construí con CONFIG_M386 (que ha sido históricamente la forma de tener un núcleo que corra en todos los procesadores x86), no obtuve salida u otra actividad aparente después de que el cargador de arranque salta hacia él. Cuando es construido con CONFIG_MCRUSOE, se cuelga después de imprimir "PCI: Probing PCI Hardware", justo como nuestros núcleos (que, curiosamente, pasan este putn aún cuando son construídos con CONFIG_M386). En caso de que alguien sea curioso, he puesto el fichero .config de la construcción CONFIG_MCRUOSOE prístina en ftp://ftp.yggdrasil.com/private/adam/linux-crusoe/.config.

Mis intentos iniciales para encontrar un manual del procesador de tms5600 en el web o en el sitio web de Transmeta aún no se han convertido en dada, y entiendo que el tms5600 incluye el puente norte. Así, asumo que éste podría ser el primer lugar para buscar por ideas acerca de cualquier rareza que ocurre durante el inicio de PCI del host bridge.

Un pecado que estoy cometiendo en estas versiones es que yo las estoy construyendo con gcc-2.95.2, aunque no pienso que este sea el tipo de conducta que un bug optimizador es capaz de producir.

Si alguien está usando Linux 2.4.0-test en una Sony PictureBook PCG-C1VN (la versión Transmeta), estaría interesado en por lo menos tratar de contruir desde de su fichero .config

H. Peter Anvin explicó, "Es un ligero bug en el código de prueba de PCI de Linux que se activa cuando hay actividad DMA durante la prueba PCI. Linus ya tiene una compostura para esto; espero que será en el próximo preparche." Y Linus Torvalds también replicó a Adam:

Esto se debe a un bug de Linux, cuando deshabilitamos el puente norte mientras hacemos las pruebas de ventana PCI.

[ De hecho sospeché por un rato que lo habíamos descompuesto en Transmeta, pero después de platicar con y doble revisión de las especificaciones PCI, resultó que Linux realmente estaba en falta. Oh, bien. A cualquier lado donde volteo, yo siempre tengo la culpa ;) ]

Lo que sucede es que la notebook Sony tiene soporte para Legacy USB en el BIOS, lo que causa eventos DMA USB varias cientos de veces por segundo. Cuando Linux hace la prueba PCI, Linux apagará los bits MEM e IO en el registro de órdenes PCI del dispositivo que prueba. Entonces sucede que de acuerdo a la especificación PCI, el apagar el bit MEM del puente host (aka "puente norte") desconecta al host del bus PCI.

Unos cuantos microsegundos después un evento DMA de USB legacy viene, pero ahora el puente host ya no reenvía más el DMA entre el bus PCI y la memoria, y la máquina se cuelga. Oops.

La solución más simple (que funciona) es borrar el traqueteo con los bits IO y MEM del registro de órdenes PCI en drivers/pci/pci.c: pci_read_bases().

La compostura adecuada (la cual hemos discutido con Martin Mares y Richard Henderson es de hecho hacer la enumeración completa del bus primero, _sin_ hacer ninguna prueba de ventana (y por lo tanto sin tener que lidiar con los bits IO y MEM en el registro de órdenes), y cuando encontremos el controlador USB en ofensa que el BIOS ha dejado activo, lo matamos primero (ya lo tenemos en la sección de giros de PCI, es solo que los giros PCI son ejecutados muy tarde para componer este problema tal como está ahora).

Adam también había sugerido que Transmeta le consiguera a Linus uno de los PictureBooks, y Linus replicó:

De hecho, tengo uno, y había tenido uno por cerca de dos semanas, pero debido a la más nueva adición (humana) a la familia Torvalds no he tenido tiempo para depurar esto hasta antier.

¡NOTA! Obtener el núcleo 2.4.x arriba y corriendo es la parte fácil. La máquina también tiene un chip ATI Rage Mobility muy reciente en ella, y necesitas la muestra CVS de XFree86 más receiente para hacer que funcione (junto con un parche de una línea mío, a menos que ya halla entrado en el árbol CVS para ahora).

Aún entonces XFree86 hace algo malo con DPMS, y bloqueará el juego de chips gráfico cuando trata de apagar la pantalla plana. Solución: no habilites DPMS en XF86Config. Es un problema de XFree86, pero feliz y fácilmente solucionado.

Oh, y hay un bug en el controlador UHCI que te morderá (de nuevo porque la máquina tiene USB legacy habilitado por omisión - y al contrario de casi cualquier otra laptop por ahí, Sony no permitió que el código de USB legacy sea apagado en la configuración del BIOS), así que a menos que hayas aplicado los parches USB de la lista de correo electrónico USB, tan sólo se colgará ahí.

De cualquier forma, tengo esta máquina funcionando ahora, aunque no todo está a mi gusto. Al contrario de los picture-books más antiguos, por ejemplo, este tiene un WinModem. Ugh. Y el chip de sonido tiene soporte, pero solamente por el controlador ALSA (la versión OSS está muy descompuesta para ser usada).

Pero la cámara está cool, y funciona hermosamente (una vez que tienes a XFree86 feliz) gracias a Andrew Tridgell. (Si solo pudiera coaccionar al servidor X para que me dé una capa YUV podría reproducir DVD's con esta cosa).

Varias gentes le dieron a Linus algunos consejos sobre cómo hacer que las cosas funcionaran, y para el final del hilo de discusión él pareció que estaba teniendo buen éxito con eso.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	18 Nov 2000 - 30 Nov 2000	(12 posts)	Compostura Para Bug De Memoria Virtual De 2.2 De Tiempo Atrás
2.	22 Nov 2000 - 29 Nov 2000	(42 posts)	Más Corrupción De Sistema De Ficheros En 2.4
3.	26 Nov 2000 - 27 Nov 2000	(18 posts)	Las Distribuciones De Linux Haciendo Cambios Incompatibles A Herramientas Del Sistema
4.	27 Nov 2000 - 28 Nov 2000	(4 posts)	Nuevos Problemas De BIOS De APM Para Dell 5000e: La Saga Continúa
5.	27 Nov 2000 - 3 Dec 2000	(13 posts)	La Hija De Linus
6.	28 Nov 2000	(5 posts)	Ciclo Infinito De 'modprobe' En Controladores Con Bugs
7.	29 Nov 2000	(2 posts)	Reporte De Éxito Para Máquinas De Grandes Memorias
8.	29 Nov 2000 - 30 Nov 2000	(2 posts)	Mantenimiento Lento Del Controlador De Sonido Yamaha OPL3-SAx
9.	30 Nov 2000	(4 posts)	Rarezas De struct De Tiempo Atrás Longtime struct Weirdness And Doc Bug; True Fix Planned For 2.5
10.	1 Dec 2000 - 2 Dec 2000	(14 posts)	Linux En Chips Transmeta

Tráfico del Núcleo #97 For 11 Dec 2000

By Zack Brown

Translated By: Cristian Othón Martínez Vera