Barrapunto

Yo instalé el núcleo 2.4.15 y por fin lograba apagar de forma correcta mi portatil ante un "halt", algo que me había tenido sin cambiar el núcleo desde 2.4.9. El ieee1394, puerto de alta velocidad por el que meto el vídeo digital, no funciona de forma correcta, un problema que existe desde 2.4.6 :(

porque para mí los inusables, en cuestión de memoria, eran los menores al 2.4.9.
Tenía 128 megas de ram y con estos la swap se me llenaba a tope y cuando cambiaba de escritorio virtual me empezaba a rascar como un poseso para cargar, de swap, la imagen del fondo. Tenía que esperar, a veces 10 segundos a que se pusiera el fondo, en un Athlon a 1000. Y luego dicen de la lentitud de carga de Mozilla.

Desde que puse el 2.4.11 en adelante con el parche para la latencia soy más feliz y, por lo menos a mí, el PC me va mucho mejor.

Ahora tengo el 2.4.15 con ext3 y me va perfecto. Lo he reiniciado 2 veces, una porque se fue la luz y el journaling funcionó de maravilla y otra porque me pasa una cosa curiosa.

Si le estoy dando mucha caña a las conexiones IP. Puede que tenga abiertas unas 500 a todas horas. Con el tiempo, una semana o así, no puedo salir al exterior. Cualquier intento de conectar a una web, enviar correo o entrar por ftp da un "connection timeout", pero el caso es que entrar a mi ordenador entran sin problemas.

Esto se arregla reiniciando, porque ni tirando la red abajo y descargando todos los módulos se arregla.

Me parece raro esto porque si fuera un problema generalizado del núcleo algunos sistemas en producción con multitud de conexiones simultáneas ya lo hubieran notado.

En esitis momentos ocupo Linux -2.4.15 + Andrea Arcangeli patch y todo va de maravilla Atte AcracK

Digo yo. Porque, como a los demás, a mí me va mucho mejor el 2.4.12 que el 2.4.9. En eficiencia y estabilidad, a veces lo tengo bastante cargado y no me ha hecho nunca nada raro.
Puede que hayas encontrado algún bug que aparece sólo en alguna configuración sw/hw concreta. En ese caso, deberías estudiar cúal es la causa y informar. Si te interesa que el núcleo mejore esto es lo mejor, mejor que criticar en público a los que se lo trabajan.
También puede que el problema este en otro sitio y sólo se haga patente con las nuevas versiones por cualquier razón.
Saludos.

Objetivamente hablando, y admitido por (casi) todos los desarrolladores importantes del núcleo de Linux. Aunque las versiones .5-.8 tampoco son la maravilla (de hecho, sé de unos cuantos RedHat 7.2 con kernel en esas versiones, y aunque son equipos de esritorio, si se deja más de un día encendidos, la swap se consume sin motivo aparente.

Puesto que el problema que describes parece ciertamente reproducible, yo te recomiendo intentar aislar el error, porque a lo mejor 2.4.10+ funcionan bien en general, pero tu caso tiene una particularidad que a los desarrolladores se les ha pasado por alto. Los desarrolladores pueden hacer pruebas sobre el hardware de que disponen y con cargas y usos para ellos habituales, el resto de hardware y usos de máquina los tenemos que probar nosostros. Y no sería ni mucho menos la primera vez que un usuario cualquiera le da un toque de atención a grandes "gurús" del kernel, porque en sus condiciones de trabajo las cosas no van como deberían.

Chico, quizás en máquinas de producción los kernel >2.4.9 vayan peor, pero en mi sistema "casero" la diferencia es exagerada. Antes del cambio en la VM el swapping era interminable. Le echaba la culpa al KDE, al Mozilla e incluso al flujo de las mareas... hasta que instalé la 2.4.13. Desde entonces, todo realmente bien. Mucho menos swapping, respuesta rápida, estabilidad 100%... como debe ser GNU/Linux.

Otro cantar es cómo empaquetan los kernels. Para mí es inaceptable que una "major release" ni siquiera compile, como la 2.4.14 o que salga con gordísimos fallos como la 2.4.15. La impresión que tengo es que los parches ya no se testean bien: ¿cómo si no es posible que pase esto?

Miramos a los usuarios de Windoze a veces con desdén riéndonos de sus contínuas visitas al Windows Update cuando resulta que cada vez que actualizo el kernel tengo que aplicar parches a los tres días.

--

La novia molesta, pero no impide.

Sé que el mismo Linus se quejó de que la versión del gcc que trae por defecto la RH 7.0 (no recuerdo cual, creo que un egcs) daba errores al compilar los kernels de la rama 2.4.

Es curioso tener en 2 máquinas la misma distribución, con el mismo kernel, sólo difieren en el hardware (PIII y Athlon) y que en una máquina nunca te haya dado problemas y en otra no sepas qué hacer para que deje de dartelos. Realmente eso me hace creer que hay hay algún tipo de problema con el hardware de mi equipo.

Ayer esta la utilizacion del bandwith de kernel.org a unos niveles q nunca habia visto...

q pasa? q a cada nucleo q sale la gente lo prueba... y ademas quieren ser los primeros en probarlos. Vale , se supone q los kernels deben de ir bien... pero esto no es una ciencia perfecta, y si te esperas dos dias antes de pillar lo ultimo de lo ultimo pues te ahorras problemas.

otra cosa es que la gente tenga problemas con el kernel q tiene y/o necesite un driver que solo viene en lo ultimo. y aun mejor... si lo que haces es pillar el ultimo kernel para testearlo, muchomejor :)

2.4.14 compila. Es lo que estoy usando ahora :-?... Aunque a alguien se le olvidó actualizar el módulo loop.o para que trabaje con el nuevo gestor de memoria. Es cosa de añadir dos líneas :-).

A mí, desde la 2.4.13 (creo), el módulo SCSI aic7xxx ya no se da compilado pq en un fichero hay algo así como un #include aicdb.h" y ese fichero no hay... No sé si viene mucho al caso, pero bueno... alguien sabe qué podría hacer? Intentar ponerme en contacto con alguien del desarrollo del núcleo? La verdad es que no tengo ni idea de qué hacer...

Yo te puedo decir, que el kernel 2.4.3 sí que me apagaba el equipo que tengo :) De hecho, es raro que a tí con el 2.4.15 se te apague el portátil sin más con el halt... Muy raro, porque a muchos de nosotros(Incluso yo), que lo hacíamos con el halt, se te apagaba el ordenador sin la intervención tuya... :-((((

Yo teniendo SuSE Linux, con kernel 2.4.10(que no me fío lo que hay para poder poner nuevos kenel's), pero, ya te digo.... Es fácil hacer funcionar si tienes bién los módulos validados y demás.. ¿No crees acs?

Te pasa con esta version del kernel de rh 2.4.9-13 ?

y qué me dices del 2.4.11? :P

La Red Hat 7.0 trae el gcc 2.96 que es una versión no oficial, y tiene varios bugs, como por ejemplo serios problemas con las instrucciones MMX.

Esos problemas, por ejemplo, causan que el mplayer de un segmentation fault nada mas ejecutarlo si se compila sobre RH70.

Esos mismos problemas pueden afectar tambien el kernel, puesto que tiene que lidiar con el salvado y restaurado de registros MMX, etc.

Expondré mi situación. Tengo un AMD 1200 con 512Mb RAM, y la verdad bajo mi debian sid y el kernel .13 es de lo peor que he visto nunca. Se consume toda la memoria física en 2 minutos, hay segv al cargar el XMMS, el KDE control center, el Xchat, y un largo etc. de aplicaciones. Volvere al viejo 2.4.8 porque parece bastante mas estable que cualquier 2.4.1? aunque el problema de la VM no se lo quita nadie . ¿Habéis probado los parches de alan cox para la VM? ¿Que opinión os merece?. Un saludo.

No es por ser los primeros, es por que son los primeros kernels que traen ciertas 'features' de serie: ext3, i8k (un modulillo para acceder a la bios de los dell inspiron)... sin tener que aplicar parches.

Yo he arrancado solo dos veces con la 2.4.15, durante la segunda fue cuando lei lo del bug. Ahora he vuelto a la 2.4.14-pre7 que parece que es sana y tiene soporte de ext3. Que por que compilo mi propio kernel en vez de usar los de la distribución? entre otras cosas, porque el hardware nuevo no es soportado por estos kernels.
Mi nuevo portátil gasta una maestro3 (que usa un driver experimental), un Lucent Winmodem (para el cual necesito otro driver especial), una GeForce2Go (un driver cerrado de NVidia), para controlar los ventiladores y los botoncitos del volumen necesito el modulo i8k, filesystem udf para el dvd y loopback y emulación SCSI para la regrabadora; el firewire, la pcmcia y los usb ni me los he mirado aun... pero ya tengo soporte en el kernel, para no haber de recompilarlo en el futuro.

Eso si, nunca he tenido problemas con el apagado automático en mis otras máquinas: basta con asegurarse de cargar el módulo de APM ;)

Miren, no entiendo nada. ¿Pero no era que los kernels con el segundo numero par eran estables?. Pense que con el 2.4.15 era el momento de pasarse de 2.2 a 2.4. Pero ahora veo que no.

Te cuento mi experiencia.

Tengo Sid, un Pentium II/400 con chipset Intel BX, y sistemas de ficheros Ext2 y ReiserFS.

Todo me va a las mil maravillas aunque mi memoria se llena, pero es porque arranco Gnome, Evolution y Galeon a la vez en sólo 80 Mb (y de vez en cuando también le doy al Gimp...)

Con los núcleos anteriores al 2.4.9 apenas podía moverme sin que se iniciara un overswapping del quince... Y, francamente, ahora estoy mucho mejor. Y mi sistema es completamente estable (a no ser que me ponga a jugar intentando hacer funcionar OpenGL Mesa con mi Voodoo2)

En cuanto se solucionen estas corrupciones de ficheros, me paso a 2.4.16 con ext3... Y listo.

Lo que sí me ha pasado en otros ordenadores es que ciertas opciones "experimentales" (como soporte para el último chipset de placa base, para que pille UDMA específico) empiezan a dar errores dejando frita la máquina.

Esta es mi experiencia y así la he contado.

Ciertamente son estables, pero la gente es humana y comete errores.

De vez en cuando sale alguna release de serie estable que pasa a ser rápidamente corregida por otra. Y es que ninguna versión es verdaderamente estable como aquella que tienes y sabes que funciona.

Como dice el dicho: si funciona, no lo toques. ;-)

Yo también tengo el 2.4.13 en un AMD a 1200 y 512 MB de RAM con Debian (mitad testing, mitad sid) y no tengo problemas. Supongo que dependerá también de otros factores. Saludos.

Tengo un AMD 1200 MHZ y 512 MB en RAM & EXT3 en debian SID con el kernel-2.4.16pre1 KDE-2.2.2 (despues de lo del pavo AARRGGHH!!!) y todo parece ir bien despues de abrir un rato aplicaciones konqueror, koffice, y no ha superado los 200MB saludos

He probado la 2.5.0 (si, con el bug XDD)
con mi 6x86MX a 200Mhz y 32MB de ram, y con el KDE abriendo varias aplicaciones a la vez, no solo no dio ningun fallo, sino que no lo hizo mal para ser la maquina que es.

Yo tengo un K7 a 1333 Mhz, 128 MB de RAM física, con 2.4.13 y Debian Sid estoy probando ahora mismo a cargar el sistema, tengo la swap rebosando y no experimento ningún cuelgue ni cosa rara, aparte de que está tirando un montón de swap, pero los tiempos de respuesta son más que aceptables (mi Seagate Barracuda a 7200 rpm se comporta muy bien ;-))

Te comento mi experiencia con el kernel 2.4.9, despues de 60 dias de uptime en mi servidor (casero) un dia por la mañana no podia entrar ni a la web, ni por ssh, ni nada de nada, ningun servicio respondia, resultado.,... botonazo

Cuando lo encendi tenia 9 errores en el syslog que decian: Bug at inode.c:677. En ese momento cambie al 2.4.14 y ya de paso le meti ext3 aprovechando el reinicio XD

De momento el 2.4.14 sin problemas de ningun tipo

Tienes alguna cache de DNS ?

sí, pero no parecen problemas de DNS porque si hago nslookups o pings me los resuelve bien y aunque trate de acceder a los sitios con la IP se queda esperando la respuesta del servidor del otro lado.

Tienes toda la razón... somos humanos y podemos cometer errores.

Yo modestamente reconozco que no sé como funciona el desarrollo del kernel. Pero me parece que antes de sacar una nueva version "estable" habría que revisarla un poco. No estamos hablando de pequeño bug sino algo muy serio. Esperemos que ahora que ya tenemos rama inestable, sea sobre esta las que se realize la mayoría de las innovaciones y se deje la serie 2.4.x como lo que es: una serie estable.

Mi trasto es un k7-1200 con 256 mb de ram, y corro una debian Sid. La cosa es q cuando meti el 2.4.13, aquello se volvio intratable. A los 2 minutos aproximadamente, el kernel empezaba a paginar brutalmente, es unas swap-storm q me recordaba a los primeros 2.4. Horrible. No podia arrancar las x, y como hiciera algo un poco fuerte en consola, entraba en el mamoneo del swap storm y normalmente no salia vivo. Volvi a un kernel anterior (no recuerdo cual, pero la vm era de Rik van Riel) y con ese aplique el parche ac7 de Alan Cox al 2.4.13, y tios... increiblemente mejor. No es perfecto, pero comparado con el 2.4.13 no habia color. Tengo q decir q no se debe juzgar la vm de Rik por el comportamiento de los 2.4.x con x 9. Esa vm es antigua. Los parches de Alan tienen una vm de Rik bastante mas mejorada. No se cual es la razon, pero Linus decidio no aplicar esos parches y pasar a la vm de Andrea Arcangeli, que no dudo de que pueda llegar a ser buena, pero que le falta bastante por delante. Jamas entraré en un club en el que admitan como socios a gente como yo (Griucho).

No se a que te refieres, yo tengo un controladora SCSI que utiliza el AIC7XXX y siempre he tenido que compilar el módulo. ahora con el 2.4.15 tambien, por cierto me va mucho mejor que con el 2.4.13-ac8, ya no se me queda colgado cuando paso de las X al modo consola varias veces seguidas.

Por favor, dile a los desarrolladores que no toqueteen mucho los muchos trozitos del kernel que me va a liar las versiones que debo usar.

Yo quiero un microkernel (como Hurd o como Mach) estable y muchos demonios a elegir la version que mas estable me parezca, aunque en realidad está en fase Alpha.

la gente lo prueba y envía los bugs. Si no lo probase nadie, pues la cosas como que no avanzaría.

No, esta no es una pregunta capciosa, solo tengo curiosidad por saber si FreeBSD tiene problemas similares con la VM. En otras ocasiones Linux ha tomado codigo BSD ( pilas TCP/IP ). Alguien sabe como va la VM en FreeBSD ?

En mi maquina uso Debian Sid, kernel 2.4.14 y siempre me gusta vivir a la ultima que sale, no me preguntes porque, es una especie de vicio.

Aparte de eso mi maquina hace de servidor web, de servidor de correo, samba y algunas cosillas mas, pero como es mi ordenador de casa me puedo permitir ciertas libertades.

Otra razon para ponerse el ultimo kernel es para ver si la cosa se estabiliza de verdad, de todos modos el ultimo kernel con el que tuve problemas fue el 2.4.10 (fallos de VM al hacer ciertos querys en una base de datos) y el 2.4.14 con el famoso bug del loop.c pero lo del loop tenia una solucion bastante facil.

En primer lugar, una aclaración. No sé que tiene que ver una "virtual machine" con "virtual memory". Que alguien me explique qué significa "la máquina virtual de gestión de memoria" que aparece en la cabecera de la noticia.

Yendo al grano, pienso que es un peligro generalizar. Obviamente, hay gente que tiene problemas con cada núcleo. Si no fuera así, cada núcleo sería perfecto y, salvo drivers, nada cambiaría. El hecho de que uno tenga problemas con un núcleo concreto, no significa que dicho núcleo tenga que ir a la basura.

Yo, con el único núcleo que he tenido problemas ha sido con el 2.4.13. El 2.4.14 me funciona de maravilla. De hecho, lo tengo instalado en un servidor de FTP que tiene, por ahora, un uptime de 19 días. También lo tengo en mi ordenador y sin problemas.

Los primeros núcleos 2.4.x, también me funcionaron sin problemas. Y como a mí, a mucha gente más. ¿Significa esto que estos núcleos son una maravilla?. Tampoco, puesto que se han ido corrigiendo

Antes de criticar cada nuevo núcleo que sale, lo que cada uno debería plantearse es la necesidad de estar siempre a la última. Si tienes máquinas sensibles, lo mejor es que utilices un núcleo que sepas que funciona y que no te haya dado problemas. Si quieres arriesgarte un poco, pues prueba los últimos núcleos.

Pienso que debemos ser conscientes que en Linux la depuración del sistema operativo recae muchas veces en sus propios usuarios. Por eso salen tantas versiones y tantos "prepatch". En un producto comercial, sería responsabilidad de la empresa hacer todos los tests oportunos, gastándose una pasta en ellos.

Por último, pienso que Linus, como cualquier otra persona, comete errores. Desde mi punto de vista, el error que ha cometido en esta versión ha sido hacer una versión final 2.4.15 sin que la gente probara durante unos días la pre9. Y no es la primera vez que saca una versión final a las pocas horas de la última versión "preX", y eso, para mí, es un error, ya que puedes estar introduciendo errores en la última versión preX, como ha ocurrido aquí.

Un saludo.

me "encanta" la política de Redhat con el gcc...
es que se gana tanto cuando algo se compila correctamente con el 2.96???

alguien sabe por que siguen esa política?
que pensais, vosotros, usuarios de redhat de esta política?

Vaya, tienes razón :-(. Pero no tengo una controladora de esas para hacer pruebas.

Vienen dos drivers para la misma: un "aic" old (que no viene eso de aicdb.h y que sí compila) y el de por defecto. ¿Probaste los dos?.

También puedes intentar usar db.h en vez de aicdb.h. No sé. Suerte :-)

Estaba pensando en esas dos alternativas, pero... mi vagancia me llevaba a esperar que en futuras versiones solucionaran el problema :). Bueno, intentar notificarlo a los desarrolladores estaría bien, pero no sé a kién hacerlos (sí, me repito :) ). Miré en el código fuente y no vi ninguna dirección de e-mail para ponerme en contacto...