Tráfico del Núcleo #102 For 12 Jan 2001

There were 464 different contributors. 207 posted more than once. 108 posted last week too.

Michael Chen notó que utilizar un Celeron como un chip P3 o P4 causaría una caída del sistema en las etapas tempranas del arranque. Explicó, "el problema se causa por el hecho de que el Celeron de Intel no tiene una barrera de memoria real,pero cuando escoges la opción de Pentium III, el núcleo asume que el procesador tiene una barrera de memoria real." Publicó un parche, pero Erik Mouw replicó:

Pienso que aquí hay algo de confusión en el nombre "Celeron". Hasta donde yo sé hay dos tipos de Celerons: el Celeron original basado en PII, o el más nuevo Celeron basado en PIII. Mi laptop tiene un Celeron basado en PIII (Coppermine), y arranca perfectamente bien sin tu parche.

Si estás usando un Celeron basado en PII, debes compilar el núcleo con el soporte para "Pentium-Pro/Celeron/Pentium-II". Ciertamente no debes tratar de correr un núcleo con soporte para P4 en un CPU "inferior", lee la documentación acerca de CONFIG_M386 en Documentation/Configure.help para más información.

No hubo respuesta a esto, pero Linus Torvalds también dijo que era un error configurar el procesador como un chip que no era. Dijo, "Todo el asunto de ser capaces de escoger el CPU para optimizar es que podemos optimizar cosas en el momento de la compilación." Varias gentes señalaron que algunos Celeron's estaban basados en el P3, y Erik explicó en cierto punto, "La confusión es porque Intel reusó el nombre Celeron para un CPU completamente diferente. Ambos Celerons tienen las mismas características que el CPU en el que estaban basados, pero con menos memoria caché. Escogiendo PIII para el nuevo Celeron basado en PIII te dará por lo tanto ligeramente mejor desempeño."

En otro lado, Kai Henningsen sugirió que el núcleo debería detectar CPUs mal configurados en el momento de arranque. Tim Wright replicó, "si escoges el tipo de procesador erróneo, tal vez ni siquiera puedas quejarte. Esto es un asunto de usuarios. Todas las distribuciones de las cuales tengo conocimiento arrancan felizmente en cualquier máquina x86, porque contruyen el núcleo para el denominador común más bajo. Algunas detectan el tipo de CPU e instalan un nucleo adecuado subsecuentemente. Así... la única forma en que puedes entrar en este embrollo es si construyes un núcleo tú mismo y escoges las opciones erróneas. Hay muchas maneras de producir un núcleo que no arranca. La expectativa es que si quieres ir y construir tu propio núcleo, necesitas saber qué estás haciendo :-)"

Linus sugirió tener una opción booleana "Optimizar para el CPU actual" durante la configuración. A varias gentes les gustó la idea, y Riley Williams publicó un parche para hacelo. Pero Alan Cox dijo, también en respuesta a Linus, "Si hacemos eso yo preferiría ver un make autoconfig que hiciera casi todo de proc/pci etc 8)" . Linus replicó:

Buen punto. No tiene caso agregar una nueva opción de configuración, tan sólo debemos tener un nuevo configurador en su lugar. Por supuesto, no puede manejar muchas de las preguntas, así que aún tendrá que regresar a preguntar.

Eso _sería_ eventualmente una buena adición. Es un proyecto más grande que lo que yo había vislumbrado, pienso.

Si alguien (¿tú? pista, pista) quiere hacer esto, yo seré muy feliz - yo mismo lo puedo hacer, pero como es mi cumpleaños se supone que debo alejarme de la computadora pronto y ser social, o Tove estará molesta.

Y tú no quieres que Tove esté molesta.

Marcelo Tosatti replicó, "Ok, lo haré porque amo a Tove." Rik van Riel intercedió entre Marcelo y la más oscura noche, diciendo:

Marcelo, deberías comprarte unos lentes ;)

Tove != Tux

Es ok y probablemente seguro amar a Tux, el bonito pingüino tierno que todos aman.

De cualquier forma, amar a la (¿¿ 6 veces ??) campeona finlandesa de karate, que resulta que está casada con Linus es probablemente algo un poco menos seguro ...

Siempre hay problemas con algún hardware, pero mi recomendación personal para una tarjeta sería definitivamente las series Ethernet Pro 100 de Intel (82557)

There are always problems with some hardware, but my personal recommendation (82557).

Al contrario de las tarjetas tulip (que son bastante buenas también), no hay un millón de versiones diferentes de ella. Hay unas cuantas, pero no es un gran relajo. Rinde bien, y es estable. Está bastante bien documentada (aparte de las extensiones mágicas), y es común.

Como dije, algunas personas tienen problemas aún con esta tarjeta. Nadie sabe por qué, pero por lo menos el controlador es mantenido activamente etc, así que aún yo no estoy nervioso acerca de recomendarla.

Apuesto que otros tendrán otras recomendaciones, pero hasta ahora personalmente he tenido por lo menos buena suerte con el eepro100.

La 3c905C es una NIC bien fabricada y muy rica en características que en este momento parece tener menos reportes de problemas que la eepro100, 8139 o tulip.

Disponible en PCI, Cardbus, Mini-PCI. Una versión de interfaz dual PCI acaba de ser liberada (3c982), aunque aún tenemos que escuchar de alguien que la pruebe con Linux.

3com provee especificaciones completas sin ninguna restricción NDA, más un controlador GPLeado.

Tal vez más significativamente, la 905 tiene soporte completo de fragmentación/ensamblaje. Esto no se utiliza por el momento, pero los parches de Alexey de zerocopy-sendfile lo utilizan. Actualmente él tiene soporte de fragmentación-ensamblaje para acenic, 3c905 y sunhme. No sé cuáles sean los planes para dar sporte a otras NICs de 100 mbps.

El 3c59x.c del núcelo no es el controlador más rápido del mundo. En la lista de cosas por hacer para 2.5 es el soporte para MMIO, el mantenimiento de fragmentación-ensamblaje, uso opcional de poleo DPD y la implementación del filtro hash multicast en la tarjeta. Y la implementación del soporte de VLAN en la tarjeta si 2.5 se convierte en capaz de usar VLAN.

3c905c es un poco cara, creo. Las tarjetas pcnet32 también funcionan muy bien para mí y son menos caras. El 905c puede ser una mejor tarjeta (realmente no lo sé), pero las pcnet32 podrían ser más efectivas en costo, dependiendo de tus necesidades (He visto tarjetas basadas en pcnet32 vendiéndose por $15-20 dólares, y compré un paquete de 10 nuevo (de tarjetas HP NightDirector 10/100) por cerca de $36 dólares, incluyendo envío, en eBay.)

En cualquier caso, las tulips han sido más problemáticas para mí que 8139, pcnet32, o 3c509c (cuya confiabilidad son todas comparables en mi experiencia). Nunca he tratado la eepro100, creo. (También, estoy hablando en términos de mis experiencias entre todos los SO bajo los cuales he usado las tarjetas, no sólo bajo Linux, aunque mis experiencias Linux son similares a las experiencias que he tenido en todos.)

Linus Torvalds retiró el sistema de nombrado '2.4.0-test', y anunció el 2.4.0-prelelease, diciendo:

Ok. No hice el 2.4.0 en el 2000. Rudo. Lo intenté, pero tuvimos algunas cosas de último minuto que necesitaban compostura (pe las listas de páginas sucias etc), y lo mejor que puedo hacer es hacer una preliberación.

Hay un 2.4.0-prerelease fuera, y es básicamente eso. Quiero que la gente lo pruebe por un rato, y quiero dar a otras arquitecturas la oportunidad de alcanzarlo con alguno de los cambios, pero lean mis labios: no más recuentos. No hay "prerelease1", para convertirse en "prerelease2" y así seguir.

Una cosa que otras arquitecturas querrán alcanzar son los cambios para manejar máquinas de +2GHz, que debido a cuestiones de desbordamiento causaron que "loops_per_sec" se convirtieran en "loops_per_jiffy". Y otras arquitecturas no han tenido mucha oportunidad de sincronizarse conmigo debido a otros fuegos a apagar.

Denle su peor. Después de que se recuperen de estar crudos, por supuesto.

Adam Sampson señaló que los módulos drm tenían símbolos sin resolver, y publicó algo de salida del enlazador. Linus publicó un parche, y Adam y Frank Jacobberger reportaron éxito completo; pero Keith Owens advirtió:

Eso se descompondrá para cualquiera compilando una tarjeta DRM en el núcleo y compilando una segunda tarjeta DRM como un módulo. drmlib.a tendrá una personalidad dividida, será compilado dos veces, una para el núcleo y otra para el módulo, y cuál versión de hecho queda enlazada dependerá de la fase de la luna. Ya sea que solamente una u otra quede compilada para el núcleo, lo cual es de donde vinimos.

A los que mantienen DRM: ¿Pueden borrar esta restricción de necesitar múltiples copias de la biblioteca? No tiene sentido de cualquier manera. Si construyes una biblioteca nueva con los mismos nombres de funciones entonces no puedes tener dos tarjetas DRM construídas dentro del núcleo, los nombres de funciones colisionarían dentro de vmlinux. Asi que tienes que usar nombres de función diferentes para una nueva biblioteca, pero entonces las tarjetas viejas pueden compartir la biblioteca antigua y las nuevas tarjetas pueden compartir la biblioteca nueva, p.e. no hay necesidad para que cada controlador tenga su propia copia de la biblioteca.

Recomiendo fuertemente que borren la restricción de tener copias múltiples de la biblioteca. Entonces el parche de Adam J. Richter hará el trabajo bien, haciendo a drmlib.a un módulo auxiliar.

Planeamos eliminar la necesidad de tener múltiples copias de drmlib.a y hacer el Makefile del núcleo completamente compatible con el sistema de make de 2.4 -- pero aún no hemos terminado este trabajo. Con este nuevo trabajo, de todas formas, el usuario final aún cargará un solo módulo (p.e., tdfx.o), justo como ahora. (Cargar un solo módulo del núcleo es una victoria significativa cuando se trata con usuarios finales: no hay posibilidad de salto de versión o de tener dos módulos que fueron compilados con opciones diferentes.)

Linus -- Por favor usa nuestro parche o el parche de Keith Owens como una bandita para resolver este problema hasta que podamos hacerlo en la forma correcta. Con cualquier parche que selecciones, por favor *NO* conviertas a drmlib como un módulo auxiliar separado -- esto solamente llevará a confusión del usuario (especialmente desde que nos movemos de regreso a una solución de un solo módulo pronto). Desde el punto de vista del usuario, no me preocupa que no puedas mezclar módulos con versiones en el núcleo, ya que la mayoría de los usuarios no hacen eso [y podríamos componer el fichero de configuración para prevenir esto -- es otra forma de curar este problema para el cual te enviaré un parche para mañana]. Estoy muy preocupado de que los usuarios nos verán movernos de 1 módulo DRM a 2 y después de regreso a 1 -- eso sería muy confuso para ellos.

Alan Cox dió su consentimiento en esto, diciendo, "Así con 3 tarjetas de video tengo 3 pedazos desperdiciados de ram sólo por una pequeña pequeña posibilidad de que alguien pueda lograr construir dos copias de la biblioteca con ksyms coincidentes. Eso no me impacta como un buen intercambio." No hubo más discusión en este subhilo.

Keith Owens anunció la última versión de modutils, en ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/modutils/v2.3. Agregó, "Asumiendo que no se encuentren problemas en modutils y asumiendo que el núcleo 2.4.0-prerelease sea seguido por el núcleo 2.4 oficial entonces esta versión de modutils será reempaquetada como modutils 2.4.0." Matthias Andree señaló que depmod dió una advertencia cuando lo invocó con la opción --version. Supuso que nada mas que la información de la versión debía salir realmente, y preguntó sobre esto. Keith replicó, "Accidente histórico. Quiero limpiar eso pero rompe la conducta existente; en algún lugar, alguien está sujeto a basarse en depmod -V actualizando modules.dep al mismo tiempo. modutils 2.5 limpiará mucho de la basura de compatibilidad hacia atrás, incluyendo éste. Pero no verás modutils 2.5 hasta que Linus inicie el núcleo 2.5 y comencemos el siguiente ciclo de desarrollo." Esto tuvo sentido para Matthias, aunque él sugirió documentar la conducta actual en la salida de --help y en la página man. Keith sintió que no lo ameritaba el problema, ya que toda la cosa cambiaría una vez que el núcleo llegara a 2.5; Matthias urgió, "Estaba sólo pensando en escribir -V "salida de versión en adición a la operación normal" en --help, nada más grande que 5 minutos." Pero no hubo respuesta.

Ari Pollak reportó, "Esto no ha sido compuesto por lo menos en un año que yo recuerde - en Documentation/devices.txt, dice que /dev/js* debe ser char-major-15*, pero en Documentation/joystick.txt dice que debe ser char-major-13. Estoy asumiendo que joystick.txt es el correcto, y devices.txt debe ser actualizado para reflejar esto.. antes de 2.4.0 sería bien." Robert Read replicó, "devices.txt necesita algo de actualización. Aún lista char-major-13 como la Bocina PC, pero 13 parece ser el mayor para el nuevo controlador de entrada, y el controlador de la palanca de juegos es ahora un menor de ése. ¿Ahora hay dos controladores Joystick o puede ser marcado obsoleto/borrado char-major-15?" H. Peter Anvin dijo, "Pienso que hay dos; por lo menos, el número permanecerá reservado por mucho tiempo," y dió un enlace al devices.txt actual. Robert y otros publicaron parches, y el hilo de discusión terminó.

En otro lugar, bajo el Subject: [PATCH] devices.txt bugs, Geert Uytterhoeven publicó un parche contra devices.txt, y explicó:

Este parche compone dos cosas:

Corrige los números menores para los dispositivos frame buffer. Tenemos espacio para 32 frame buffers desde hace un año, con más espacio para expansiones futuras a 256. (prometido para seguir por HPA el Fri, 24 Mar 2000 01:47:05 -0800).
Compone un error de tecla en los menores para la tarjeta serial A2232

El transporte a modo-usuario de 2.4.0-prerelease está disponible.

hostfs está con más mejoras. La escritura de ficheros realmente funciona ahora. La ejecución de binarios también funciona. Hay aún algo de corrupción de memoria, creo.

Compuse la caída de swapoff.

La entrada a las consolas y las líneas seriales es ahora mucho más general. Puedes conectarlas a ptys, ttys, y puertos ahora, con unas cuantas interfaces más por venir.

La página inicial del proyecto es http://user-mode-linux.sourceforge.net

La página de descargas del proyecto es http://sourceforge.net/project/filelist.php?group_id=429

Vedran Rodic reportó corrupción de sistema de ficheros con 2.4.0-prerelease. Él puso el registro completo del núcleo de la sesión en el web, y reportó que no había visto otros errores nuevos desde ese primer reporte. Daniel Phillips preguntó si era posible reproducir el problema, y Vedran replicó, "No puedo reproducir este problema fácilmente. Vee en los ficheros de registro que sucedió después de algunas horas de tiempo de funcionamiento." Fin del hilo de la discusión.

2.4.0prerelease-ac4

Compone bloque de CMOS para 2.4.x (Paul Gortmaker)
Actualizacinoes de DecNET (Steve Whitehouse)
Compostura de error de tecla en devices.txt (Roberto Nibali)
Fix 15-23bit direct colour in logos (Geert Uytterhoeven)
Corrige framebuffer en device.txt (Geert Uytterhoeven)
Pequeñas composturas en mkiss (Hans Grobler)
bloqueo de caché FAT para SMP ('manmower')
Compone bug de escritura después del final del disco (Jari Ruusu)
Más composturas de la construcción de iee1394 (Andreas Bombe)
Mejor compostura de enlace de atm (Jan Rekorajski)
Saltar dm9100's más antiguos del controlador tulip (yo)

2.4.0prerelease-ac5

Resincroniza con el preparche de Linus prepatch en prueba
Compone rarezas de ciclos por jiffy (Geert Uytterhoeven)
Compuesto el parche de video perdido en -ac (Geert Uytterhoeven)
Compostura de una línea del controlador de microcódigo (Tigran Aivazian)
Compone recursión de reserva de página (Rik van Riel)
Compone problemas de ksyms de ACPI (Keith Owens)
Resincroniza correctamente composturas de ide-cd (Byron Stanoszek)
Limpia código LAPB (Hans Grobler)
Limpia código X.25 (Hans Grobler)
Composturas de advertencia general/bug menor (Arjan van de Ven)
Compone raza del controlador de bloques i2o (Arjan van de Ven)
Composturas de makefile/controlador acorn (Russell King)
Hace que cyberfb use pci_get_drvdata (Russell King)
Mata código redundante de temporizador ARM (Russell King)
Borra algunos hacks de ARM hacks de fbmem.c (Russell King)
Compone bugs de configuración con fusion, indentando (Andrzej M. Krzysztofowicz)
Maneja cambios de orden bootmem en arm (Russell King)
Actualización de SA1100 (Russell King)
Borra reinicio de codec extra del audio de i810 audio | debe componer VRA fallido en algunas placas (Anwar Payyoorayil)
Maneja flujos de ALI AGP (??)
Mezcla algunos de los cambios PPC (Cort Dougan)

No hubo respuestas, pero el día siguiente, bajo el Subject: Linux 2.4.0prerelease-ac6, Alan anunció:

2.4.0prerelease-ac6

Actualizaciones de IDE de Macintosh IDE (Geert Uytterhoeven)
Actualiza ksyms de 68k (Geert Uytterhoeven)
Compone ioctls de teclado de m68k (Geert Uytterhoeven)
Compone config.in de fbdev que permite PM2 modular (Geert Uytterhoeven)
Actualiza controladores ethernet de m68k (Geert Uytterhoeven)
Composturas Y2K 2.4 para el reloj de Amiga (Geert Uytterhoeven)
Compone controladores scsi sun/mac (Geert Uytterhoeven)
Compone el orden de inicio de fb (Geert Uytterhoeven)
Compone cosas misceláneas de Fix m68k (Geert Uytterhoeven)
Actualiza el controlador lance de m68k (Geert Uytterhoeven)
Compone restricciones de asm de m68k (Geert Uytterhoeven)
Compone la configuración de m68k (Geert Uytterhoeven)
Actualización serial de Amiga/soporte para consola serial (Geert Uytterhoeven)
Actualiza m68k para usar loops_per_jiffy (Geert Uytterhoeven)
Agrega funciones de soporte necesitadas por gcc (Geert Uytterhoeven)
Compone la administración de recursos amiga (Geert Uytterhoeven)
Limpia econet (Hans Grobler)
Más limpiezas de radio amateur (Hans Grobler)
Compone deadlocks irda/SMP (Marc Zyngier)
Más composturas de YAM (Hans Grobler)
Compone el bug de bloque de rio500 (Greg Kroah-Hartmann)
Compone fuga de almacén de memoria temporal raid (Neil Brown)
Bloque de knfsd adicional (Neil Brown)
Compone fuga de red isdn en un error (Arnaldo Carvalho de Melo)
Compone exportación de proc_get_inode (para comx) (Hans Grobler)
Compone error de bloqueo en get_swap_page (Marcelo Tosatti)
Compone más advertencias, y otras cosas que el nuevo gcc muestra (Arjan van de Ven)
Agrega tablas de dispositivo modular isapnp a controladores [Agregadas a ns558, serial, ide-pnp, cadet, 3c509,3c515, aironet4500,ne,sb1000, aha1542, NCR5380, ad1816, awe_wave, sb, ixj] (Bill Nottingham)
Resincronizar con preparche de Linus

Esta discusión inició suficientemente inocente, pero Rik van Riel y Andrea Arcangeli sólo no se llevan bien. Tal vez es por que están trabajando en dos versiones competidoras del subsistema de Memoria Virtual, tal vez vaya más allá. En esta encarnación en particular, Rik publicó una variante de un parche de rendimiento escrito originalmente por Andrea; agregó, "Se que probablemente esto no sea de mucha ayuda bajo cargas muy baja y muy altas, pero debe proveer una buena mejora bajo cargas medias..." Andrea lo corrigió, diciendo, "Debe proveer una mejora bajo gran carga del SVF (montones de ficheros bloqueados y no conservados referenciados todo el tiempo)." Pero Rik disentió, diciendo, "No realmente. Bajo grandes cargas del SVF, sólo revisamos en la lista dos veces y liberamos las entradas de cualquier forma." Andrea entonces arrojó la primera piedra, con, "Estás evidentemente equivocado." Continuó dando una explicación técnica de este punto, y discutiendo con agudeza de ida y vuelta por unos cuantos mensajes, hasta el punto que Andrea dijo, "Tus argumentos no tienen sentido." Rik finalmente lanzó un gancho, con, "Podría decir lo mismo de tí si me dejara hundir a ese nivel ;)</obflamazo>" . El dió su propia explicación técnica, a lo cual Andrea lo acusó de salirse del tema. Rik dijo que él sólo había estado argumentando contra el punto de Andrea; y agregó, "Desafortunadamente, parece que ignoras mis argumentos, así que vamos a terminar esta discusión." Andrea replicó, "No los he ignorado, lo que dijiste fue obviamente equivocado o fuera de tema." A lo cual Rik respondió agudamente, "Sin dar ningún argumento ;)"

En este punto, Alan Cox entró y los jaló a esquinas opuestas, diciendo, "Podrían los dos llevar este debate a alt.flame" .

Ludovic Fernandez publicó un parche contra 2.4.0-prerelease, para hacer al núcleo preentivo. Rik van Riel replicó, "Pienso que sería algo bueno para comenzar a probar una vez que 2.5 sea bifurcado." Hubo algo de discusión técnica del parche, y en un punto en otro lugar, Nigel Gamble dijo:

No me di cuenta que seguías trabajando en eso. ¿Sabías que yo también? Nuestra versión más reciente está en:

ftp://ftp.mvista.com/pub/Area51/preemptible_kernel/

aunque debo aún poner un parche para 2.4.0-prerelease (pronto llegará). Debemos probablemente reunir nuestros esfuerzos en esto para 2.5.

Ludovic explicó, "Estaba en vacaciones y tuve un poco de tiempo para matar... Revisando tu README, pareces mucho más avanzado que este simple parche." Él coincidió que reuniendo sus esfuerzos sonaba como la forma de seguir. Sugirió que ellos investigaran algunas pruebas de evaluación posibles, y agregó que tal vez la discusión había comenzado a salirse del tema para linux-kernel. Pero Daniel Phillips intercedió:

¡No! No está fuera del tema. Y espero que no deseches ese simple parche, siempre será útil para hacer pruebas de realidad en el rendimiento del sistema lindo, y quien sabe, tal vez sea útil por su propio derecho.

La moda actual es usar dbench:

ftp://samba.org/pub/tridge/dbench

Pienso que esto es bueno para tu parche porque es inherentemente paralelo. Números interesantes de tareas son, p.e., 1, 2, 10, 50. Por supuesto dbench no es la última palabra en pruebas de evaluación pero ha sido bastante útil hasta ahora. Probablemente quieres ago totalmente relacionado al cpu también. ¿Qué tal dbench con ramfs?

En un movimiento unánimemente aclamado por la prensa especializada y los analistas de la industria como un signo seguro de daño cerebral incipiente, Linus Torvalds (también conocido como el "padre de Linux" o, más comúnmente, como "masa-para-cerebros") decidió que suficiente es suficiente, y que las cosas no mejorarían por tener a la misma gente probándolo una y otra vez. En corto, 2.4.0 está ahí fuera.

Ansiosamente esperado por los últimos demasiados meses, 2.4.0 trae a la mesa muchas mejoras, ninguna de las cuales viene a la mente del exhausto coordinador de la versión liberada en este momento. "Es mejor", fue la única cita imprimible. Presionado por detalles, Linus mostró su dentadura y siseó a los reporters, la mayoría de los cuales repentinamente recordaron que deberían mejor cubrir "Casa y Jardinería" que la industria de TI de cualquier forma.

De cualquier forma, diviértanse. Y no se molesten en reportar ningún bug en los siguientes días. No me importará de cualquier forma.

En v2.4/test-kernels:

patch-2.4.0-prerelease.gz - parche de test12 a la preliberación

prerelease-to-final.gz - parche de la preliberación a la final.

Y aparentemente tomará algún tiempo para que se sincronicen los servidores ftp: cuando moví los test-kernels del directorio v2.4 principal no pensé en el hecho de que los guiones de espejo tardarán algo de tiempo tan sólo sincronizando todo (el hecho de que _yo_ lo hice con un simple "mv" en las copias maestras no significa que los servicios de espejo serán capaces de hacerlo ;)

Justo ahora la sincronización de la copia maestra ha alcanzado a los parches en el directorio test, lo cual significa que no debe tomar más de cerca de 15 minutos hasta que todo haya sido sincronizado - pero sospecho que si la gente aterriza en ftp.kernel.org solamente alentará las cosas aún más, así que traten de ver si pueden encontrar otros espejos que hayan entrado temprano y no sincronicen los test-kernels...

Una cosa que debe estar en la mente de todos es el famoso bug 'brown-paper-bag' que afectó a 2.2.0, como se cubrió en BROKEN KCREF. ¿Se encontrará un exploit similar para 2.4.0?

2.4.0-ac1

Resincronizar con Linus
Compone bug de compilación de serial (Bill Notthingham)
Limpia lapbether (Hans Grobler)
Compone manejo de endian en ne.c (Geert Uytterhoeven)
Compone manejo de umount de root (Chris Mason & Al Viro)
Trae a los controladores wan al inicio para 2.4 (Krzysztof Halasa)
Compostura de bloqueo del módulo (Oliver Neukum)
Mezcla los transportes a S/390 32/64bit | algunos bordes ásperos que limpiar aún - chicos pueden | cambiar los ifdefs de DMA ifdefs para coincidir con el estilo de 2.2.. (IBM)

Miles Lane tuvo algunos problemas compilando, y Keith Owens publicó una compostura de Makefile, agregando que el cambio podría prevenir que ACPI funcionara con versiones de símbolos de módulos; así que Miles no podría seleccionar las versiones de símbolos de módulos. Bill Wendling propuso tambíen otra solución, que funcionó bien para Miles. Bill replicó, "¡Grandioso! Solo quería que yo supiera dónde estaba siendo generada esta línea para que yo pudiera enviar un parche :)."

2.4.0-ac3

Agrega soporte para las tarjetas 3c905 más nuevas (Andrew Morton)
Retira campo sin uso de scc.h (Hans Grobler)
Borra cosas de sysctl muerto de econet (Hans Grobler)
Compone índices de documentación (Paul Gortmaker)
Compone la referencia después de liberar un skb en lance (Paul Gortmaker)
Limpia código appletalk (Hans Grobler)
Compone colgado de vesafb al arranque (David Wragg)
Compostura de 'reset_xmit_timer' de TCP (Dave Miller)
Limpia ubicación del cursor en menuconfig (Kirk Reiser)
Agrega wait.h includes faltantes a algunos asm/semáforos (Hans Grobler)
Limpieza de socket AF_UNIX (Hans Grobler)
Actualiza compostura de bloqueo de sd (Oliver Neukum)
Agrega bloqueo de módulo a las llamadas del coprocesador de audio (Chris Rankin)
Más limpieza menor de X.25 (Hans Grobler)
Compone caída de ioctl/scan scsi en memoria agotada (Douglas Gilbert)
Parches de soundscape (Chris Rankin)
Composturas de m68K fixes para estadísticas de mem y stram (Geert Uytterhoeven)
Establece MSG_TRUNC correctamente en sockets atm (Matti Aarnio)
Agrega infraestructura para autocarga de parport autoloading (Adam J Richter)
Hacer al controlador lp que use capable no el viejo suser() (Tim Waugh)
Compone raza de thread/unload en bloque i2o (yo)
Compone controladores para que usen asm/delay no linux/delay (Geert Uytterhoeven)
Más composturas de advertencias (Rich Baum)
Composturas de netfilter config/Makefile (Dave Miller)
Mezcla el controlador cs4281 actualizado y lo limpia | alguna limpieza mía, posiblemente lo descompuse ;) (Tom Woller)
Compone referencia de bagetlance de buffer liberado (Arnaldo Carvalho de Melo)
Pequeñas composturas de ISDN (Andrea Baldoni, Daniel Stodden)
Controlador ESS Maestro 3 (Zach Brown)

Algunas gentes señalaron que Alan había olvidado actualizar el número de versión EXTRAVERSION del Makefile de ac2 a ac3.

Aún el poderoso ftp.kernel.org ha caído bajo el efecto /. después de que ellos presentaron el anuncio:

http://slashdot.org/article.pl?sid=01/01/05/0049246&mode=thread

Ustedes probablemente no irán a tener mucha suerte para obtener ninguna fuente de ningún servidor esta noche. ¿Podría sugerir que aparezcan en Slashdot y den a los despistados algunas pistas para que tengan sus nuevos núcleos funcionando? Necesitan ayuda.

Scott Laird replicó, "mi espejo (ftp-mirror.internap.com, o ftp15.us.kernel.org) está solamente viendo 1-2 Mbps llenos de tráfico, de 10 Mbps disponibles en él. Sospecho que muchos de los espejos son similares." Después de un rato, Michael agregó:

Deduzco de la combinación de lo que leí en Slashdot y lo que las gentes respondieron aquí que los espejos están ligeramente cargados, pero los lectores de Slashdot no saben acerca de ellos porque no pueden leer la página inicial en http://www.kernel.org que los dirija a la lista de espejos.

Así que publiqué el algoritmo para calcular el URL a su espejo más cercano en Slashdot. Tal vez eso ayudará a algunos

Jon Masters preguntó acerca del estado de la criptografía para 2.4.0, y Marc Mutz replicó:

Un 2.4.0.1 debe estar en ftp://ftp.kernel.org/pub/linux/kernel/crypto/v2.4/. Pero ha sido retrabajado intensivamente. No he puesto mis manos en éste y estaré callado sobre hasta qué extensión este parche está listo para producción, pero recuerdo que el controlador de ciclo en 2.4.0 aún puede congelar tu máquina. Como la criptografía de kerneli se basa en el ciclo, esto contaría en favor "no lo hagas aún".

Por cierto: Te gustaría ingresar a linux-crypto@nl.linux.org (majordomo) si estás interesado en kerneli.

Jon estaba muy emocionado de conocer sobre la lista de correo, e ingresó en el instante.

El transporte de modo-usuario de 2.4.0 está disponible.

Fue actualizado a 2.4.0 y aquí está.

La página inicial del proyecto es http://user-mode-linux.sourceforge.net

La página de descarga del proyecto es http://sourceforge.net/project/filelist.php?group_id=429

Keith Owens anunció, "http://oss.sgi.com/projects/kdb/download/ix86/ contiene parches para kdb v1.7 contra el núcleo 2.4.0. No hay cambios significativos desde 2.4.0-test13 y 2.4.0-prerelease. Solamente se ajustó el parche al nuevo núcleo."

Por supuesto 2.4.0 corre en m68k también :-)

Lo siento, no hay cambios reales desde la última versión liberada, pero quiero tener algo fuera de la puerta tan rápido como sea posible. Hoy es mi último día de asueto, así que mis esfuerzos de desarrollo de Linux serán mucho más pequeños desde la próxima semana. ¿Alguien que lo tome de nuevo?

El parche es bastante corto. Parece que el periodo de tensión justo antes de una nueva versión liberada mayor es bueno para nuestra tasa de aceptación de parches. Es como un duelo: quién puede manejar el mayor estrés, y quién se rinde... Linus puede haber perdido esta vez :-)

Si puedes vivir sin arquitecturas `exóticas' (Atari, Mac, Sun3, ... :-), el parche es... pequeño.

¡Buena suerte! ¡Disfruten!

http://home.tvd.be/cr26864/Download/linux-m68k-2.4.0.diff.bz2

Samuli Kaski reportó que LVM no compilaría con la opción de configuración CONFIG_LVM_PROC_FS, y Alan Cox replicó, "Compuesto en -ac por eras. Linus no pensó que fuera lo suficientemente importante para 2.4.0 - lo cual comparado con 'se cae cuando yo..' creo que es suficientemente razonable." Fin De La Discusión.

2.4.0-ac2

Limpia controlador de strip (Hans Grobler)
Compone makefile de fore atm (Jan Rekorajski)
Compone mezcla errónea de lance m68k (Geert Uytterhoeven)
Compone errores de tecla de documentación de tty (Hans Grobler)
Compone construcción de ohci1394 (Arjan van de Ven)
Borra inicios muertos de lapbether (Hans Grobler)
Compostura temporal de Makefile para el problema del nombre de variable recursivo de acpi (Bill Wendling)
Más mezclas menores de S/390 (Ulrich Weigand)
Compone problema de construcción de DRM en ATI Rage 120/no AGP (Gareth Hughes)
Compone el establecimiento de la dirección mac en 8139too (Ben Greear)
Compostura de oops de AGP/limpieza de ALi (Bill Crawford)
Más limpieza de DECnet (Hans Grobler)
Últimas composturas de S/390 (Ulrich Weigand)
Compone el símbolo de arlan faltante (Hans Grobler)
Hace limpieza básica de IPX/SPX (Hans Grobler)

Octave Klaba preguntó si Alan tenía intención de liberar nuevos núcleos 2.2, o si planeaba trabajar solamente en 2.4 a partir de ahora. Alan replicó, "2.2.19 está aún cocinándose bien. Estoy apuntando para un mes o dos."

Josh Fryman preguntó si Linux había sido transportado exitosamente a la red de procesadores programable IXP1200 de Intel. Él había escuchado rumores que si lo había sido, pero no había podido conseguir algo definitivo. Russell King replicó, "Si así es. Mira en: http://www.netwinder.org/~urnaik/ixp1200_howto.html para más información sobre lograr que Linux esté corriendo.." Fin De La Discusión (mr).

Matthew Schumacher reportó que el núcleo 2.4.0 no compilaría cuando CONFIG_IP_NF_FTP fuera escogido durante la fase de configuración. David S. Miller señaló que tanto CONNTRACK como NAT completo tenían que ser activados también. Preguntó a Rusty Russell, "Rusty, ¿por qué las cosas de Config no refuerzan esto si es necesario cuando se activa el soporte para FTP etc.?" Rusty replicó, " Deja Vu: hemos pasado por esto antes. Pero alguien más jodi^H^H^H^Hcompuso los makefiles recientemente." Publicó un parche, que le pareció bien a David, y el hilo de discusión terminó.

He puesto un parche contra linux-2.4.0 para uClinux 2.4. Las plataformas con soporte están enumeradas a continuación, en el anuncio que fue enviado a la lista uClinux-dev.

Nos gustaría mezclarlo en el árbol de Linux principal en 2.5, así que hemos tomado una aproximación que toca tan poco como es posible del núcleo genérico :-)

Esta versión liberada incluye soporte para ColdFire MCF5307 y MC68328 de Motorola. El soporte de MCF5307 soporta destinos Lineo NetTEL y el 68328 soporta destinos XCoPilot.

Status:

El soporte de MCF5307 es el más completo. Incluye red y controladores para el NetTEL. Hay unas cuantas fugas de memoria y hay un bug en wait4().

El soporte para MC68328 ha sido traído adelante de test11, y aún tiene una pequeña rotura (la cosa de la tabla de vectores de interrupción se descompusieron en el camino). Compondremos esto en los siguientes días.

Usen gcc-2.95.2 configurado con --target=m68k-elf para construir estos destinos.

Muchas gracias a David McCullough que hizo el trabajo pesado moviendo esto hasta la liberación de mi trabajo temprano en test5, a Michael Leslie quien hizo la mezcla del trabajo de 68328 de Randy Buchanan. Y por supuesto a Linus y toda la comunidad que produjo la versión liberada de Linux 2.4.

Joe Pranevich dijo, "Este documento ya ha sido tomado por algunos sitios de noticias de Linux, pero realmente pertenece aquí. Esta es mi lista de nuevas características desde Linux 2.2, recolectadas al leer esta list, jugando con parches, y obteniendo información de la gente. Partes de esto no es técnico, pero hay alguna buena información aquí. Espero que aluien encuentre útil esta lista." Él incluyó su lista, la cual puedes encontrar en Linux Today. Jean-Christian de Rivaz tuvo una pregunta acerca de la sección "Redes Y Protocolos", en la cual Joe había dicho, "Debe ser mencionado en este punto que Linux es aún el único sistema operativo completamente compatible con el texto de la especificación IPv4." Jean-Christian replicó, "Estoy muy interesado acerca de la prueba de esto. Trabajo en un proyecto que necesita ser certificado. Cualquier información acerca del cumplimiento de Linux a alguna especificación es muy bienvenida." Andi Kleen replicó:

Por lo menos es muy dudoso. Hasta donde yo sé no se ha hecho recientemente una evaluación RFC1122/RFC1812 (desde 2.0 o algo así). También parte de estos RFCs han sido sobrepasados por RFCs posteriores que no han alcanzado el status de estándar Internet aún, así que no serían muy útiles de cualquier forma (el internet de hoy se ve muy diferente al de 1989 cuando 1122 fue escrito)

El mecanismo al cual se refiere el comentario (notificación asíncrona de error para UDP, que no está en el BSD tradicional) no es usada por el 99.9% de todas las aplicaciones por cierto ;)

Jim Olsen habí sido una víctima del BROKEN KCREF reportado hace poco. Él tenia alguna idea a partir de linux-kernel que el problema haya sido compuesto o por lo menos modificado, y preguntó, "¿Exactamente cúal núcleo debo usar para liberar a mi servidor de este asunto de MV? No estoy conforme (y siempre será así) con correr núcleos pre* en máquinas en producción, por lo que me gustaría permanecer con 2.2.18, pero quisiera saber si esto realment compone el(los) problema(s) con la MV. Si lo necesito, creo, pondré dudosamente un núcleo 2.2.19* en la máquina." Alan Cox, Rik van Riel, y Ville Herva señalaron que 2.2.19pre2 tenía la compostura final. Como Ville lo puso, "Está completo 2.2.19pre2 (que incluye el parche global vm-global-7 de Andrea Arcangeli que (entre otras cosas) compone esto.) puedes aplicar también el parche vm-global-patch a 2.2.18 si quieres."


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

1.	23 Dec 2000 - 1 Jan 2001	(22 posts)	Configuración Del CPU Y Autoconfiguración
2.	28 Dec 2000 - 4 Jan 2001	(62 posts)	Tove
3.	28 Dec 2000 - 1 Jan 2001	(13 posts)	Recomendaciones De Tarjeta De Red
4.	31 Dec 2000 - 4 Jan 2001	(24 posts)	2.4.0-prerelease: Aproximándose 2.4.0
5.	31 Dec 2000 - 3 Jan 2001	(6 posts)	El Futuro De modutils
6.	1 Jan 2001 - 2 Jan 2001	(10 posts)	Limpieza De devices.txt
7.	1 Jan 2001	(1 post)	Transporte De modo-usuario De 2.4.0-prerelease
8.	2 Jan 2001	(5 posts)	Posible Corrupción De Sistema De Ficheros En 2.4.0-prerelease
9.	2 Jan 2001 - 4 Jan 2001	(3 posts)	Parches ac Contra 2.4.0-prerelease
10.	3 Jan 2001 - 5 Jan 2001	(17 posts)	Rik Y Andrea: Cuando La Saga Regresa
11.	3 Jan 2001 - 4 Jan 2001	(25 posts)	Parche Preentivo Para 2.4.0-prerelease
12.	4 Jan 2001 - 6 Jan 2001	(15 posts)	2.4.0 Es Liberado
13.	4 Jan 2001 - 6 Jan 2001	(9 posts)	Parches ac Contra 2.4.0
14.	4 Jan 2001 - 5 Jan 2001	(3 posts)	Problemas Tratando De Descargar 2.4.0
15.	4 Jan 2001 - 6 Jan 2001	(3 posts)	Cryptografía En 2.4
16.	4 Jan 2001	(1 post)	Transporte De modo-usuario De 2.4.0
17.	4 Jan 2001	(1 post)	Depurador Del Núcleo Para 2.4.0
18.	5 Jan 2001	(1 post)	Linux/m68k 2.4.0
19.	5 Jan 2001	(2 posts)	Problemas Menores De LVM En 2.4.0
20.	5 Jan 2001 - 6 Jan 2001	(8 posts)	Alan Aún Mantiene 2.2
21.	5 Jan 2001	(2 posts)	Linux En El IXP1200 De Intel
22.	5 Jan 2001 - 6 Jan 2001	(5 posts)	Limpieza De La Configuración En 2.4.0
23.	5 Jan 2001 - 6 Jan 2001	(2 posts)	uClinux 2.4.0.0pre0 Liberado
24.	6 Jan 2001	(3 posts)	"El Maravilloso Mundo de Linux 2.4"
25.	7 Jan 2001	(7 posts)	Bloqueos "VM: do_try_to_free_pages": La Saga Termina Pacíficamente

Tráfico del Núcleo #102 For 12 Jan 2001

By Zack Brown

Translated By: Cristian Othón Martínez Vera