Tráfico del Núcleo #117 For 7 May 2001

There were 386 different contributors. 185 posted more than once. 158 posted last week too.

Victor Zandy reportó, "Hemos encontrado que uno de nuestros programas puede causar corrupción en todo el sistema de la FPU (unidad de coma flotante) x86 bajo 2.2.16 y 2.2.17. Esto es, después de que corremos este programa, la FPU da resultados malos a todos los procesos subsecuentes." Él pudo confirmar esto en docenas de sistemas Xeon a 550MHz, y publicó algo de código para reproducir el efecto. Después, agregó, "Ahora hemos probado 2.4.2 y 2.2.19. 2.2.19 tiene el mismo problema. 2.4.3 no parece estar afectado." Richard B. Johnson publicó un programa simple para reinicializar la FPU, y remarcó, "Si esto lo "compone", no hay problema con la FPU, sino con la biblioteca de tiempo de ejecución 'C' que no inicia la FPU en un estado conocido antes de que la usa. Es posible para el núcleo sacar la vuelta al problema de la biblioteca 'C' limpiando la FPU después de cada fork(). La última vez que revisé (hace años), 'finit' era ejecutada durante el fork. Tal vez ya no lo es más porque toma muchos ciclos de máquina para completarse." Sugirió que si el programa no solucionaba el problema, que probablemente el hardware tenía la culpa. Victor replicó que no, reiniciar el FPU no tenía efecto, pero agregó, "Si fuera un problema de hardware, esperaría que el problema ocurriera bajo 2.4.2 así como 2.2.*, y estaría sorprendido de que pudiéramos reproducir consistentemente la conducta a través de nuestro cluster de 64 nodos." Richard replicó, "Entonces, si la FPU está bien, sólo has probado que el almacén donde se guarda el contexto de la FPU es sobreescrito. Más aún, una vez que ocurre la escritura inicial, todas las operaciones fnsave/frestore subsecuentes también encuentran la misma escritura espuria. --O algo de coma flotante que corre constantemente se ha colado en el núcleo." No hubo respuesta a esto, pero en un punto David Konerding preguntó si alguien tenía algún comentario sobre el reporte original del bug, y Alan Cox replicó, "Mistificación ompleta." Prosiguió, "El estado del procesador para la FPU es privado por tarea y cada tarea inicia su propio estado de FPU. En términos del estado de la FPU en sí actualmente no veo que hay que pueda ser dejado atrás."

Alguien más aquí rastreó las banderas del proceso en un programa intensivo en coma flotante en una máquina antes y después de que se pone el estado de la FPU con falta. Él tomó muestras periódicamente de /proc/pid/stat mientras el programa estaba corriendo.

Encontró que PF_USEDFPU siempre era establecido antes de que la máquina se descompusiera. Despúes encontró que se establecía cerca del 70% del tiempo.

Si no estoy equivocado esto de hecho puede causar corrupción GLOBAL de FPU. Aquí está porqué:

Asume por un momento que ya perdemos la bandera PF_USEDFPU de un proceso. Esto no sólo significa que el proceso actual no tendrá su estado guardado, también significa que el próximo proceso no tendrá el bit TS establecido. Esto a su vez significa que este nuevo proceso no tendrá PF_USEDFPU establecido y de repente tendremos un segundo proceso con un estado de FPU corrupto.

Victor: ¿Puedes intentar reproducir la corrupción de todo el sistema si añades una llamada explícita a stts(); justo en el final de __switch_to? Esto debe prevenir que la corrupción de la FPU se propague.

NOTA: Esto es sólo para probar mi teoría, no es y no trata ser una compostura para el problema actual.

Victor reportó, "Después de agregar esta llamada, no puedo reproducir la corrupción global. Aún hay corrupciones locales ocasionales de procesos pi individuales mientras pt está corriendo." No hubo respuesta.

Algo que salió en una de las discusiones en los corredores en el kernelsummit fue que muchos de los mantenedores de las arquitecturas encontrarían más conveniente si los ficheros de encabezado específicos a la arquitectura fueran movidos de include/asm-$ARCH a arch/$ARCH/include. Ya que _de cualquier forma_ usamos un enlace simbólico, no son necesarios cambios globales en las declaraciones de include, meramente tendríamos que cambiar el Makefile de

symlinks:

rm -f include/asm
( cd include ; ln -sf asm-$(ARCH) asm)

symlinks:

rm -f include/asm
( cd include ; ln -sf ../arch/$(ARCH)/include asm)

¿Alguien tendría un problema con este cambio? Haría un parche endemoniadamente grande para Linus, pero de verdad simplificaría las vidas de los mantenedores de arquitectura.

UML ya tiene un arch/um/include para encabezados privados que no están permitidos verse para el resto del núcleo.

Esto significaría moverlo, lo cual no es un gran problema.

No hubo respuesta a esto, pero Jes Sorensen también replicó al mensaje inicial de Matthew, diciendo, "No veo que ahorraría, excepto por el hecho de que solamente tienes que correr diff -urN una vez en lugar de dos cuando quieres enviar a Linus un diff grande. ¿O me falta algo?" Y Pavel Machek replicó, "Ahorrar un diff urN está bien, además puedes distribuir tu arquitectura con más facilidad como fichero tar y además es más fácil de poner sólo tu arquitectura en cvs. Me gusta." Fin Del Hilo De Discusión.

Fabio Riccardi anunció la primera versión de X15, un servidor de web de espacio de usuario que él afirmo que era más rápido que TUX basado en el núcleo. Dió un vínculo al fichero tar, y muchas gentes lo probaron. De hecho no pareció ser tan rápido o más rápido que TUX, pero Ingo Molnar señaló que X15 no cumplía completamente con el RFC 2616 ya que hacía caché de los campos de datos. Citando la sección 14.18, donde se lee, "El campo Date del encabezado general representa la fecha y hora en la cual el mensaje fue originado, [...] Los servidores de origen DEBEN incluir un campo de encabezado Date en todas las respuestas," Ingo señaló que X15 no manejaba esto correctamente. Agregó, "Yo también consideré el caché del campo de Date para TUX, y lo evité debido exactamente a este detalle, no violar ese 'DEBEN' en el RFC. Puede ser esperado razonablemente de un servidor web que tenga un campo Date: con 1 segundo de exactitud. El caché de encabezados en X15 le da una ventaja contra TUX, obviamente, pero en mi opinión es una práctica cuestionable. Si el caché de encabezados fuera permitido entonces podríamos hacer el truco obvio de hacer sendfile() de respuestas web completas (primero el encabezado, después el cuerpo)."

Fabio replicó que deshabilitaría el caché de encabezos y vería cómo afectaba eso el rendimiento. Ingo replicó que no debía haber mucha diferencia de velocidad, pero agregó, "haría los resultados más comparables con TUX." Fabio confirmó que sólo había un pequeño impacto en el rendimiento, y dió un vínculo a la nueva versión. Varias gentes estaban impresionadas, y el hilo de discusión se desvaneció.

Lee Mitchell reportó, "La reproducción de mp3's bajo 2.4.4 (SMP) resulta en ráfagas de sonido sobrepuestas en la música que se está reproduciendo." 2.4.3 no tenía el problema. Publicó la información de su sistema:

Tarjeta Madre	Gigabyte GA-6BXD
CPU(s)	2 x 400 MHz PII
RAM	128MB
Tarjeta de Sonido	Creative AWE64-Gold
Tarjeta de Red	3Com 3c905-B
Tarjeta SCSI	Adaptec 2940
Tarjeta de Gráficos	Matrox G200 Millenium AGP
Captura de Video	Hauppauge WinTV Go (bttv)
Dispositivos USB	Phillips PCA646WC Webcam

Núcleo	2.4.4 (SMP)
Debian	2.2
versión de gcc	2.95.2 20000220 (Debian GNU/Linux)

Mike A. Harris confirmó el avistamiento del mismo problema cuando corría xmms en su núcleo UP 2.4.2-2 de Red Hat, así como en 2.4.4 estándard compilado tanto UP como SMP. Aunque el problema ocurría sólo después de media hora o una hora. Sucedío en su K6-III 300MHz y en su Compaq Proliant ML530 Xeon 1Ghz dual. De cualquier manera, no pudo reproducirlo en demanda. Steven Walter también confirmó ver una conducta muy similar, pero no cuando escribía directamente a /dev/dsp. En otras palabras, no cuando usaba xmms. Con él el programa esd activaría el problema. Describió su sistema UP:

PCChips M599LMR
1 x AMD-K6/2 500MHz
128MB RAM
C-Media
Núcleo 2.4.4
Debian 2.2
gcc versión 2.95.2 20000220 (Debian GNU/Linux)

Gregoire Favre también confirmó haber visto un problema similar, aunque sólo con la salida de su tarjeta DVB-s, y no con el programa esd. Describió su sistema:

UP
PIII
Asus p2b-ls
gcc versión 2.96 20000731 (Linux-Mandrake 8.0 2.96-0.49mdk)
Mandrake 8.0
raiserfs
ext2(boot)
ningún parche en el núcleo...

Lee Mitchell también confirmó el problema con esd, pero no dio ningún detalle de su sistema. Steven pidió que por favor si alguna persona no experimentaba el problema diera un paso al frente. Pierre Rousselet replicó, "esd funciona para mí con cualquier 2.4.x incluyendo 2.4.4 Pentium III, BE6, ES1370, devfs, Xfree-4.0.3/GNOME esound-0.2.22. Timidity también está bien." Steven notó que la versión de Pierre de esd era más nueva que la suya, y dijo que la actualizaría y probaría de nuevo. No hubo respuesta.

H. Peter Anvin preguntó quién estaba manteniendo el sistema de ficheros ISO9660, y Alexander Viro replicó, nadie. Preguntó si H. Peter quería ofrecerse como voluntario, y H. Peter replicó, "Estaba esperando evitarlo. Realmente no tengo los ciclos. De cualquier forma, haré algo de trabajo de mejoramiento." Andries Brouwer también dijo que él no era el mantenedor pero recientemente había hecho algo de trabajo en esa área, y estaría feliz de revisar cualquier problema de desarrollo que surgiera.

Anders Peter Fugmann y algunos de sus compañeros de clase habían decidido escribir un controlador para una tarjeta CANbus ISA ( AROS: A-858D PCCAN -x ver. 1.12). Preguntó si ya se había hecho algún trabajo en algo así, y si sería necesitado un controlador. Mark Clayton replicó en privado que él estaba muy interesado en soporte CAN, y solicitó más información sobre la tarjeta en cuestión. Anders replicó con un vínculo a la página inicial de Kvaser, y agregó, "Contactaremos a Kvaser para obtener la Especificación técnica. No puedo garantizar que nos será permitido publicarla, pero si lo estamos y está interesados, puedo enviarle un enlace cuando y si la tenemos." En otro lugar, David Woodhouse también replicó al primer mensaje de Anders, diciendo, "Ve el Proyecto Laboratorio Linux en http://www.llp.fu-berlin.de/. Parece que recuerdo que ahí había controladores CAN en cierto punto." Fin del Hilo de Discusión (mr).

Ronny Haryanto probó 2.4.4 y encontró que el controlador tulip moría en su tarjeta LinkSys LNE100TX v4.1 después de 5 minutos. La pudo hacer funcionar de nuevo con 'ifdown' e 'ifup', pero 5 minutos después moría de nuevo. Reportó que no había tal problema en 2.2.18. Jeff Garzik preguntó si 2.4.3 funcionaba, y Ronny replicó que sí, lo hacía. Agregó, "Muy mal que no puedo usar 2.4.3; necesito 2.4.4 debido al bug del juego de chips VIA." En este punto Jacob Luna Lundberg reportó que él había estado viendo un problema similar en su tarjeta idéntica, pero solamente en núcleos anteriores a 2.4.4; de hecho, 2.4.4 era el primer núcleo que no se descomponía de esa forma, dijo. El hilo de discusión se detuvo aquí.

Erik Hensema preguntó acerca del significado del número mayor de versión del núcleo Linux. Quería saber si el siguiente núcleo estable sería 2.6 o 3.0, y porqué. Agregó, "Esto haciendo esta pregunta porque pienso que no va a haber un núcleo que sea tan diferente al anterior como es 2.0 comparado con 1.2. Como un pequeño recordatorio: 2.0 nos trajo SMP, módulos, soporte multiplataforma (¿1.2 soportaba Alpha? No lo recuerdo), soporte a cuotas, soporte de MD, dispositivo loop, por mencionar unos cuantos." Oliver Neukum replicó que el número de mayor versión dependía completamente de Linus Torvalds, o como Oliver lo puso, "Nuestro gran y valiente líder hablará con el pingüino de más allá del cielo." George Anzinger sugirió que si el código de usuario tuviera que ser reenlazado para que funcionara con el núcleo, sería el momento para un nuevo número de versión.


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

1.	19 Apr 2001 - 30 Apr 2001	(37 posts)	Corrupción de Coma Flotante En 2.2
2.	22 Apr 2001 - 27 Apr 2001	(4 posts)	Reestructura Del Árbol De Código Específico A La Arquitectura
3.	27 Apr 2001 - 1 May 2001	(18 posts)	Servidor De Web Rápido De Espacio De Usuario
4.	28 Apr 2001 - 30 Apr 2001	(16 posts)	Corrupción De Sonido Bajo 2.4.4
5.	30 Apr 2001	(4 posts)	No Hay Mantenedor Del Sistema De Ficheros ISO9660
6.	30 Apr 2001 - 1 May 2001	(3 posts)	Controlador CANBus
7.	1 May 2001	(4 posts)	Controlador Tulip Roto O Compuesto En 2.4.4
8.	1 May 2001	(3 posts)	Números Mayores de Versión

Tráfico del Núcleo #117 For 7 May 2001

By Zack Brown

Translated By: Cristian Othón Martínez Vera