Re: [opensuse-es] No bajeis la beta 1 de la 11.1 y de la SLE 11, son peligrosas!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El día 23 de septiembre de 2008 15:27, Carlos E. R.<> escribió:
El 2008-09-23 a las 13:34 -0300, Juan Erbes escribió:
Te hacen un favor! Al menos tienes la oportunidad de poner una tarjeta mejor que la intel, ja ja ja!
Vaya manía que tienes con Intel. No hay ningún fabricante santo, hombre.
Esa supuesta falla en el driver está comprobada en condiciones de laboratorio? Cuantos casos hubo en que esa supuesta falla en el driver, les estropeó la tarjeta de red?
¡Y yo que se! Si miras el bug del kernel que puso Camaleón (que no sabemos si es el correcto), verás que bastantes. Lo que hace, aparentemente, es borrar del todo la eeprom, con lo que la tarjeta no sabe hacer nada; y en el bugzilla desconocen manera alguna de repararla. De supuesta falla, nada. A ver, que es Novell quien ha retirado la Beta, que no soy yo quien ha gritado "Que viene el lobo!". No van a retirar una beta ya publicada por un "supuesto fallo". Y todavía no han anunciado oficialmente que la hayan repuesto, oficialmente sigue quitada.
O fue un caso aislado, que en realidad se debió a otras causas, como una descarga electrostática, ya sea al desconectar el cable de red, o al instalar la tarjeta de red, sin las correspondientes precauciones referidas al las descargas electrostaticas.
No te has leido el bug del kernel.
La verdad es que no tengo mucha simpatia por los productos intel, pero tampoco me atrevo a pensar de que sean tan malos y que una tonta falla de programacion en el driver, los pueda dañar.
Mira, coge una CPU y cambiale la microporgramación inadecuadamente, a ver que pasa >:-)
En el texto que citas:
Yo no cité ningún texto aparte del anuncio oficial, en el cual no hay enlaces ni información técnica concreta.
Update: Check this page for a list of devices that use the e1000e driver. It may not be an exhaustive list. If you have an Intel PCI Express PRO/1000 gigabit Ethernet card, it uses the e1000e driver and you should avoid booting or using beta 1. Intel has instructions on how to identify your card. Aparecen 2 links: http://cateee.net/lkddb/web-lkddb/E1000E.html http://support.intel.com/support/network/sb/cs-008441.htm
En ninguno de ellos dice ni una palabra sobre esa falla. Al menos yo no la he visto.
Salu2
Creo que se trata de esto: https://bugzilla.novell.com/show_bug.cgi?id=425480 Bug 425480 - e1000e fails to load Severity: Blocker <================================ Priority: P0 - Crit Sit ] ------- Comment #7 From Karsten Keil 2008-09-21 12:31:10 MDT ------- ] ] I fear that the EEPROM was deleted. This may be the reason, the fix is ] e1000 related, but it seems that e1000e has the same reason. ] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif... ] ] I hope that Intel can help here and has a way to reprogram the EEPROM. Uno de los afectados es Andreas Jaeger, y no creo que este hombre reporte falsedades >:-) El #24 hace mención de que puede ser un problema relacionado con VMware y con un batazaco gráfico con pánico que termina sobreescribiendo la tarjeta. Pero Jaeger no usa vmware. Y el #35 niega que vmware tenga nada que ver. En el #43 dicen como hacer un backup de la eeprom por si te la cepillan. Mencionan una posible relación con Bug 57976, pero a ese no hay acceso. En el #52 se ve actividad por la gente de Intel. Van diciendo que no parece culpa del driver de Intel, sino de algún otro módulo del kernel, o incluso de X.org sobreescribiendo memoria que no es suya (no se sabe quien). Eso me parece todavía más gordo, porque se supone que es imposible. Y otros bugzillas quizás relacionados: https://bugzilla.novell.com/show_bug.cgi?id=426437 Bug 426437 - E1000E driver does not load or work for 11.0 installer https://bugzilla.novell.com/show_bug.cgi?id=408683 Bug 408683 - Networking stops after upgrade http://lkml.org/lkml/2008/8/8/123 http://lkml.org/lkml/2008/9/22/23 http://bugzilla.kernel.org/show_bug.cgi?id=11382 https://bugzilla.novell.com/show_bug.cgi?id=428180 Bug 428180 - e1000 not working on Lenovo X61s You are not authorized to access bug #428322. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjZ8nIACgkQtTMYHG2NR9WOPQCfTyAF7b51tYezMid07lNzSfIg LH8An3di2KCz3WOmPNaV+BTxr3Tvc9w+ =IfZI -----END PGP SIGNATURE-----
El 24/09/08, Carlos E. R. escribió:
De supuesta falla, nada. A ver, que es Novell quien ha retirado la Beta, que no soy yo quien ha gritado "Que viene el lobo!". No van a retirar una beta ya publicada por un "supuesto fallo". Y todavía no han anunciado oficialmente que la hayan repuesto, oficialmente sigue quitada.
Afectados también (aparentemente) Fedora, Mandriva y Ubuntu: Bug #263555: [intrepid] 2.6.27 e1000e driver places Intel ICH8 and ICH9 gigE chipsets at risk https://bugs.launchpad.net/ubuntu/+source/linux/+bug/263555 (...)
Van diciendo que no parece culpa del driver de Intel, sino de algún otro módulo del kernel, o incluso de X.org sobreescribiendo memoria que no es suya (no se sabe quien). Eso me parece todavía más gordo, porque se supone que es imposible.
Interesante... Je, un motivo más para no utilizar un entorno gráfico en los servidores >:-) Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 24/09/08, Carlos E. R. escribió:
De supuesta falla, nada. A ver, que es Novell quien ha retirado la Beta, que no soy yo quien ha gritado "Que viene el lobo!". No van a retirar una beta ya publicada por un "supuesto fallo". Y todavía no han anunciado oficialmente que la hayan repuesto, oficialmente sigue quitada.
Afectados también (aparentemente) Fedora, Mandriva y Ubuntu:
Bug #263555: [intrepid] 2.6.27 e1000e driver places Intel ICH8 and ICH9 gigE chipsets at risk https://bugs.launchpad.net/ubuntu/+source/linux/+bug/263555
Y en un punto se plantean quitar el CD de su versión alfa, como suse. [...] Pero no lo han hecho, gente ha perdido hardware, y varios betatesters declaran que jamás volverán a probar una versión de pruebas de ubuntu, porque U. se niega a retirar la beta (protegiendo a los usuarios) por no retrasar la fecha de publicación de la distro. Sorprendente.
Van diciendo que no parece culpa del driver de Intel, sino de algún otro módulo del kernel, o incluso de X.org sobreescribiendo memoria que no es suya (no se sabe quien). Eso me parece todavía más gordo, porque se supone que es imposible.
uno de los comentarios apunta a X con video de intel, sin especificar.
Interesante...
Je, un motivo más para no utilizar un entorno gráfico en los servidores >:-)
Casualidad que sean los graficos. A mi me resulta alucinante enterarme que una pieza de software (la que sea) pueda escribir sin que nadie se lo prohiba en espacio de memoria de un driver del kernel, o peor, en un dispositivo físico (que debería estár vetado para lo que no sea kernel). Creía que estaban mejor hechas las cosas :-( - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjaFiIACgkQtTMYHG2NR9WLRACdG+qMwHGBIpsxEq01BS0TeXv4 H18AnRsO/DvmdFUU7EwWCZ35E+jsMcR+ =99Ev -----END PGP SIGNATURE-----
El mié, 24-09-2008 a las 12:27 +0200, Carlos E. R. escribió:
-Casualidad que sean los graficos. A mi me resulta alucinante enterarme que una pieza de software (la que sea) pueda escribir sin que nadie se lo prohiba en espacio de memoria de un driver del kernel, o peor, en un dispositivo físico (que debería estár vetado para lo que no sea kernel).
Creía que estaban mejor hechas las cosas :-(
Los modulos, son Kernel, un modulo mal hecho, puede ser muy peligroso.
- Saludos
Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-24 a las 15:38 +0200, lluis escribió:
Creía que estaban mejor hechas las cosas :-(
Los modulos, son Kernel, un modulo mal hecho, puede ser muy peligroso.
¡Peor! El módulo de impresora no debe poder escribir en el módulo de puerto serie, por poner un caso. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjaU/4ACgkQtTMYHG2NR9Ua9wCaApxm/hDOMP48oAsB8zv5aTc3 QBgAnifWILbm4/eueN1N2MdCqpET+4cl =sfO4 -----END PGP SIGNATURE-----
Carlos E. R. escribió:
¡Peor! El módulo de impresora no debe poder escribir en el módulo de puerto serie, por poner un caso.
En el caso que pase eso, se produce un "comportamiento indefinido".. tal cual como dicen los estandares ;-) -- "A computer is like an Old Testament god, with a lot of rules and no mercy. " Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
El mié, 24-09-2008 a las 10:56 -0400, Cristian Rodríguez escribió:
Carlos E. R. escribió:
¡Peor! El módulo de impresora no debe poder escribir en el módulo de puerto serie, por poner un caso.
En el caso que pase eso, se produce un "comportamiento indefinido".. tal cual como dicen los estandares ;-)
O sea... ponte el casco, que esto esta jod..., bueno digamos negro. ;-) -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-24 a las 10:56 -0400, Cristian Rodríguez escribió:
Carlos E. R. escribió:
¡Peor! El módulo de impresora no debe poder escribir en el módulo de puerto serie, por poner un caso.
En el caso que pase eso, se produce un "comportamiento indefinido".. tal cual como dicen los estandares ;-)
Pues debería ser una excepción, segment fault, o como quiera llamarse. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjaWHIACgkQtTMYHG2NR9X+FACeJw1tYe9xU8RUfA/7SB+/WwvZ oBQAniW87pAxYDHiXCGCyymcDA5+dXGV =1q8m -----END PGP SIGNATURE-----
Carlos E. R. escribió:
Pues debería ser una excepción, segment fault, o como quiera llamarse.
bueno, "indefinido" es "cualquier cosa puede pasar" , generalmente es un segfault, bus-error etc.. pero eso no esta garantizado ;-) -- "A computer is like an Old Testament god, with a lot of rules and no mercy. " Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-24 a las 11:12 -0400, Cristian Rodríguez escribió:
Carlos E. R. escribió:
Pues debería ser una excepción, segment fault, o como quiera llamarse.
bueno, "indefinido" es "cualquier cosa puede pasar" , generalmente es un segfault, bus-error etc.. pero eso no esta garantizado ;-)
Pues que no esté garantizado es el problema precisamente >:-) - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjai9MACgkQtTMYHG2NR9UQ0ACgim+pFTovI8wMIMD8DPgDI+/Q SDMAoIgDrUI0mZCR2HFVaAC7NaJhXmda =smzI -----END PGP SIGNATURE-----
El mié, 24-09-2008 a las 17:10 +0200, Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-09-24 a las 10:56 -0400, Cristian Rodríguez escribió:
Carlos E. R. escribió:
¡Peor! El módulo de impresora no debe poder escribir en el módulo de puerto serie, por poner un caso.
En el caso que pase eso, se produce un "comportamiento indefinido".. tal cual como dicen los estandares ;-)
Pues debería ser una excepción, segment fault, o como quiera llamarse.
Desde el punto de vista hard.. no esta fuera de su espacio. Ahora, otras consideraciones. En una e2prom estan conviviendo parametros de funcionamiento y datos de usuario( MAC). Se ha borrado. Si se ha borrado, muy problabemente se puede reescribir. No nos rasgemos las vestiduras, que no se suiciden los betatesters, lo unico que hace falta es que Inte cuente que hay que escribir ahi. Hay otro problema sutil no mencionado, es solo un borrado ocasional??? Si es asi deberia ser recuperable. Se han escrito datos en la e2prom un monton de veces..... Eso ya huele peor, eso si provoca un error hard, la e2prom puede haber quedado inutilizada. Estaba pensando en montar un chiringuito de reparacion de tarjetas e1000.... Algun voluntario??? -- Saludos Lluis
Carlos E. R. escribió:
Creía que estaban mejor hechas las cosas :-(
Son hechas por seres humanos, por ende tienen errores como cualquier otra cosa. -- "A computer is like an Old Testament god, with a lot of rules and no mercy. " Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-24 a las 10:50 -0400, Cristian Rodríguez escribió:
Carlos E. R. escribió:
Creía que estaban mejor hechas las cosas :-(
Son hechas por seres humanos, por ende tienen errores como cualquier otra cosa.
A mi, cuando me enseñaron sistemas operativos, hace lustros, de lo poco que vi, me contaron cosas como que había zonas de seguridad, de manera que un proceso o subproceso no pueda escribir fuera de la zona que se le ha asignado. Así, un driver sólo puede escribir en su memoria propia y las zonas de i/o del dispositivo que controla, y nada más. Si intenta escribir fuera, se produce una excepción y se le paran los pies. Si necesita escribir en la zona de otro driver, necesariamente lo tiene que hacer pidiendoselo explícitamente al otro driver. Yo creía que eso ya estaba implementado y que era agua pasada hace lustros, pero por lo que veo, no es así. Que para evitar que alguien escriba en tu driver salvo tu, tienes que mirar en los drivers de los demás; va a ser que el kernel es un espacio común. Leches. Yo los errores los acepto, pero esto es sintoma de un fallo sistemático. No se si habrá algún sistema operativo que implemente esto, y me decepciona mucho. Es como cuando un empleado de una empresa comete una barbaridad, pero lo hace cumpliendo las normas de la empresa, luego no ha hecho nada malo. Resulta que como parche, la gente de intel ha tenido que declarar esa zona machacada como de sólo lectura, para que el kernel pete o diga Oops! si alguien trata de escribir. Pero si quien escribe es el X.org no va a toparse con ninguna limitación (eso dicen en el bugzilla) y no se detectará. Manda coj[censurado]. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjaWEIACgkQtTMYHG2NR9Xy2wCgh5/0fP6PWg2nYXA4hbwtIuwi YDoAnA0Vwu1vPkDYF2C+XexgvtKJAnRc =ZWU/ -----END PGP SIGNATURE-----
El mié, 24-09-2008 a las 17:09 +0200, Carlos E. R. escribió:
Es como cuando un empleado de una empresa comete una barbaridad, pero lo hace cumpliendo las normas de la empresa, luego no ha hecho nada malo.
No, no es eso. Hay limitaciones que vienen del hard. Un modulo mal hecho puede estropear muchas cosas. Y lamentablemente eso de los fallos sistematicos, es un tema peliagudo... Si quieres te mando la EN50128 que va de eso -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-24 a las 17:17 +0200, lluis escribió:
El mié, 24-09-2008 a las 17:09 +0200, Carlos E. R. escribió:
Es como cuando un empleado de una empresa comete una barbaridad, pero lo hace cumpliendo las normas de la empresa, luego no ha hecho nada malo.
No, no es eso. Hay limitaciones que vienen del hard. Un modulo mal hecho puede estropear muchas cosas. Y lamentablemente eso de los fallos sistematicos, es un tema peliagudo...
Si quieres te mando la EN50128 que va de eso
No, no es eso. Es un tema de la tabla de control de procesos, donde debe estar especificado, para cada proceso (y un driver es un proceso único, no el kernel en su conjunto): memoria accesible en w/r, r, x; puertos i/o accesibles r, r/w; etc. Cuando eso existe, la CPU no permite que ningún driver lea o escriba fuera de madre. Una vez hecho eso es totalmente imposible escibir fuera de madre, salvo claro, que un proceso se le mapee zonas que no son suyas: pero entonces tienes mal un proceso y además la definición de la tabla de procesos aparte (en plan apparmour). - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjai2gACgkQtTMYHG2NR9Xo+QCgkeKer66w8tOKATNnZl8U8Pj4 4KwAn2IWc8YA42R/lp/q1WPcYKCAtBCI =d5VP -----END PGP SIGNATURE-----
El mié, 24-09-2008 a las 20:48 +0200, Carlos E. R. escribió:
No, no es eso. Es un tema de la tabla de control de procesos, donde debe estar especificado, para cada proceso (y un driver es un proceso único, no el kernel en su conjunto): memoria accesible en w/r, r, x; puertos i/o accesibles r, r/w; etc. Cuando eso existe, la CPU no permite que ningún driver lea o escriba fuera de madre.
Una vez hecho eso es totalmente imposible escibir fuera de madre, salvo claro, que un proceso se le mapee zonas que no son suyas: pero entonces tienes mal un proceso y además la definición de la tabla de procesos aparte (en plan apparmour).
No me conozco el tema tan bien, como para poder discutirte, pero si eso solo es soft,no esta respaldado por el hard, no va. Si el hard me permite mapearme zonas en el anillo del kernel que no son mias..... El soft no podra hacer nada, al menos a priori. Como mucho soltar una alarma a posteriori -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-24 a las 20:55 +0200, lluis escribió:
El mié, 24-09-2008 a las 20:48 +0200, Carlos E. R. escribió:
No, no es eso. Es un tema de la tabla de control de procesos, donde debe estar especificado, para cada proceso (y un driver es un proceso único, no el kernel en su conjunto): memoria accesible en w/r, r, x; puertos i/o accesibles r, r/w; etc. Cuando eso existe, la CPU no permite que ningún driver lea o escriba fuera de madre.
Una vez hecho eso es totalmente imposible escibir fuera de madre, salvo claro, que un proceso se le mapee zonas que no son suyas: pero entonces tienes mal un proceso y además la definición de la tabla de procesos aparte (en plan apparmour).
No me conozco el tema tan bien, como para poder discutirte, pero si eso solo es soft,no esta respaldado por el hard, no va.
Claro, el procesador tiene que respaldar eso. Yo lo que te cuento es lo que me contaron que tenía que hacerse, hace ya unos cuantos años. Pero no se hace, y por lo que estoy viendo, ignoro si las CPUs lo soportan.
Si el hard me permite mapearme zonas en el anillo del kernel que no son mias.....
El soft no podra hacer nada, al menos a priori.
Como mucho soltar una alarma a posteriori
Ya. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjaj/YACgkQtTMYHG2NR9XoegCeJZc0coGMrFzBO8kLPJ5vtkfQ +CoAnRFAJDjaa+EQH2y8JSoTCPTVFQrr =sQcU -----END PGP SIGNATURE-----
Yo los errores los acepto, pero esto es sintoma de un fallo sistemático. No se si habrá algún sistema operativo que implemente esto, y me decepciona mucho.
No creo que sea un fallo sistemático, si fuera un concepto erróneo de
diseño estaríamos inundados de fallos de este tipo, de hecho se haría
imposible utilizar un computador con estos sistemas y todos sabemos que
eso no es así...
Creo que no hay que ser tan pesimistas con este BUG, que es a pesar de
lo grotesco tan sólo eso; una _modificación_ fallida del código que como
tantas otras tiene que ser depurada, corregida o eliminada.
Pienso que la causa real de estos fallos es la presión que impone el
mercado por tener un producto terminado y «novedoso» que oponer al
producto del otro. Es una tendencia que lamentablemente se siente que va
creciendo. Por ejemplo Ubuntu libera nuevas versiones cada 6 meses, pero
estas no pasan de ser RCs que recién después de 2 o 3 meses llegan a
consolidarse, para que al poco tiempo se venga la otra... Creo que se
están metiendo a una carrera que parece bastante contraproducente a la
cual no le veo mucho sentido.
--
Mauricio J. Adonis C.
Mauricio J. Adonis C. escribió:
Pienso que la causa real de estos fallos es la presión que impone el mercado por tener un producto terminado y «novedoso» que oponer al producto del otro.
En este caso, el problema real es el diseño del hardware en cuestion. -- "A computer is like an Old Testament god, with a lot of rules and no mercy. " Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
Es lamentable lo del problema de las tarjetas de red intel, pero de
cierta forma estamos aceptando que pueden haber problemas cuando
bajamos e instalamos una versiòn beta. pues para eso es, para hacer
pruebas...
Este sistema ha hecho de linux y el software libre lo que es y que
pase algo asì como el caso en cuestiòn, no debe hacer que nos neguemos
a seguir colaborando con el proyecto o proyectos similares.
es mi punto de vista,
saludos
El 24/09/08, Cristian Rodríguez
Mauricio J. Adonis C. escribió:
Pienso que la causa real de estos fallos es la presión que impone el mercado por tener un producto terminado y «novedoso» que oponer al producto del otro.
En este caso, el problema real es el diseño del hardware en cuestion.
-- "A computer is like an Old Testament god, with a lot of rules and no mercy. "
Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
-- R. Mauricio Masis V. PvPymes (Punto de Venta Para Pequeña y Mediana Empresa) Tel 243 9271 Ext 224 --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-24 a las 17:50 -0500, R. Mauricio Masís V. escribió:
Es lamentable lo del problema de las tarjetas de red intel, pero de cierta forma estamos aceptando que pueden haber problemas cuando bajamos e instalamos una versiòn beta. pues para eso es, para hacer pruebas...
Sí, pero. El riesgo que asumimos los que probamos es que dejen de funcionar los programas, o a lo peor que borren datos del disco entero. Lo que nunca te planteas es que destruyan hardware. Es decir, invertimos tiempo, no dinero. Vale, no es que lo quemen (esta vez, y que se sepa), pero sí se inutiliza. Y se supone que en teoría se podría volver a reflashear las tarjetas con los datos originales, pero... ¿de donde los sacas? Como no sea que Intel pueda saber los datos originales de cada una de esas tarjetas y pueda suministrarlos de manera fácil a todos los perjudicados, que son bastantes... Suelen ser portátiles, con la red integrada, no puedes cambiar la tarjeta. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjax90ACgkQtTMYHG2NR9VJZwCeOjRx6tLd6SnFb3FraDFaCeRa jIoAn3RWX6HNq3ey1JTozcV2XfGbo9oH =yCCu -----END PGP SIGNATURE-----
Carlos E. R. escribió:
Vale, no es que lo quemen (esta vez, y que se sepa), pero sí se inutiliza. Y se supone que en teoría se podría volver a reflashear las tarjetas con los datos originales, pero... ¿de donde los sacas? Como no sea que Intel pueda saber los datos originales de cada una de esas tarjetas y pueda suministrarlos de manera fácil a todos los perjudicados, que son bastantes... Suelen ser portátiles, con la red integrada, no puedes cambiar la tarjeta.
SUSE e intel estan trabajando en una herramienta de recuperacion, stay tuned ;) -- "A computer is like an Old Testament god, with a lot of rules and no mercy. " Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-24 a las 20:20 -0400, Cristian Rodríguez escribió:
SUSE e intel estan trabajando en una herramienta de recuperacion, stay tuned ;)
Eso son buenas noticias. Algo habían dicho antes. Aunque, por otra parte, todos los fabricantes de cosas flasheables debieran tener publicados procedimientos y datos para reponer los contenidos originales. Es cuestión de tiempo que a alguien le pase. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkja39AACgkQtTMYHG2NR9W/hgCeO71OFU4/RPU29MtWw3a+KAGu wocAn2JsqNW01G+VVBvJn257vPvpYI4C =gx7X -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-24 a las 18:43 -0400, Cristian Rodríguez escribió:
Mauricio J. Adonis C. escribió:
Pienso que la causa real de estos fallos es la presión que impone el mercado por tener un producto terminado y «novedoso» que oponer al producto del otro.
En este caso, el problema real es el diseño del hardware en cuestion.
Fíjate que algunos de los reportes apuntan a que un batazazo con entrada en pánico del servidor de X.org es el que provoca la escritura en la tarjeta de red, porque justo después del batacazo la tarjeta deja de funcionar. O sea, es un fallo cruzado. Existe la posibilidad de que ocurra cuando el vídeo también es de intel. Vete a saber si "algo" se confunde de pastilla y escribe en la de red pensando que escribe en la de vídeo... Puf. (siendo del mismo fabricante a lo mejor tienen métodos similares de escribir. O han contaminado código). Pero no está confirmado que sean del mismo fabricante. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjaxhgACgkQtTMYHG2NR9XfVwCeMKzRMqwT6uCxZ6PdCnru5c+0 sjYAoIeGGxrfDpk1kOimHQ2Wliiao9wm =NH/D -----END PGP SIGNATURE-----
El día 24 de septiembre de 2008 4:55, Carlos E. R.
No te has leido el bug del kernel.
No lo he leido. Sorry.
La verdad es que no tengo mucha simpatia por los productos intel, pero tampoco me atrevo a pensar de que sean tan malos y que una tonta falla de programacion en el driver, los pueda dañar.
Mira, coge una CPU y cambiale la microporgramación inadecuadamente, a ver que pasa >:-)
En el texto que citas:
Yo no cité ningún texto aparte del anuncio oficial, en el cual no hay enlaces ni información técnica concreta.
Update: Check this page for a list of devices that use the e1000e driver. It may not be an exhaustive list. If you have an Intel PCI Express PRO/1000 gigabit Ethernet card, it uses the e1000e driver and you should avoid booting or using beta 1. Intel has instructions on how to identify your card. Aparecen 2 links: http://cateee.net/lkddb/web-lkddb/E1000E.html http://support.intel.com/support/network/sb/cs-008441.htm
En ninguno de ellos dice ni una palabra sobre esa falla. Al menos yo no la he visto.
Salu2
Creo que se trata de esto:
https://bugzilla.novell.com/show_bug.cgi?id=425480 Bug 425480 - e1000e fails to load Severity: Blocker <================================ Priority: P0 - Crit Sit
] ------- Comment #7 From Karsten Keil 2008-09-21 12:31:10 MDT ------- ] ] I fear that the EEPROM was deleted. This may be the reason, the fix is ] e1000 related, but it seems that e1000e has the same reason. ] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdif... ] ] I hope that Intel can help here and has a way to reprogram the EEPROM.
Uno de los afectados es Andreas Jaeger, y no creo que este hombre reporte falsedades >:-)
El #24 hace mención de que puede ser un problema relacionado con VMware y con un batazaco gráfico con pánico que termina sobreescribiendo la tarjeta.
Pero Jaeger no usa vmware. Y el #35 niega que vmware tenga nada que ver.
En el #43 dicen como hacer un backup de la eeprom por si te la cepillan.
Mencionan una posible relación con Bug 57976, pero a ese no hay acceso.
En el #52 se ve actividad por la gente de Intel.
Ahora está un poco mas claro el panorama.
Van diciendo que no parece culpa del driver de Intel, sino de algún otro módulo del kernel, o incluso de X.org sobreescribiendo memoria que no es suya (no se sabe quien). Eso me parece todavía más gordo, porque se supone que es imposible.
Y otros bugzillas quizás relacionados: https://bugzilla.novell.com/show_bug.cgi?id=426437 Bug 426437 - E1000E driver does not load or work for 11.0 installer
https://bugzilla.novell.com/show_bug.cgi?id=408683 Bug 408683 - Networking stops after upgrade
http://lkml.org/lkml/2008/8/8/123 http://lkml.org/lkml/2008/9/22/23 http://bugzilla.kernel.org/show_bug.cgi?id=11382
https://bugzilla.novell.com/show_bug.cgi?id=428180 Bug 428180 - e1000 not working on Lenovo X61s
Segun dice uno de los links, la que no tiene el sufijo e, no estás afectada, ya que no lleva eeprom. De acuerdo al texto que pegaste, el hardware, no resultaria realmente, afectado, sino el firmware grabado en la memoria eeprom de la tarjeta. La mayoria de las tarjetas de red, tienen el firmware grabado en rom, pero se nota que esta por tenerlo grabado en eeprom, se ve afectada. Aun así, es bastante extraño, porque generalmente para reprogramar o borrar una eeprom, son necesarias tensiones de al menos 15 volt (al menos por lo que recuerdo de la vez que programe un microcontrolador PIC 16C84, aunque ahora viene la versión 16F, que es flash, como los microcontroladores de Atmel). Salu2 --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-24 a las 09:14 -0300, Juan Erbes escribió: ...
Segun dice uno de los links, la que no tiene el sufijo e, no estás afectada, ya que no lleva eeprom.
Puede ser. Pero es mejor tenerle miedo y comprobar varias veces.
De acuerdo al texto que pegaste, el hardware, no resultaria realmente, afectado, sino el firmware grabado en la memoria eeprom de la tarjeta. La mayoria de las tarjetas de red, tienen el firmware grabado en rom, pero se nota que esta por tenerlo grabado en eeprom, se ve afectada. Aun así, es bastante extraño, porque generalmente para reprogramar o borrar una eeprom, son necesarias tensiones de al menos 15 volt (al menos por lo que recuerdo de la vez que programe un microcontrolador PIC 16C84, aunque ahora viene la versión 16F, que es flash, como los microcontroladores de Atmel).
Bueno, la cuestión es que el driver puede escribirlo, aunque tenga que aplicar voltajes. En otro sitio hablan de la nvram, donde se guardan cosas como la MAC: lo pone todo a "0xFF". Y si usas una aplicación para regrabar la MAC, como corrige el checksumm, el driver piensa que todos esos bytes son correctos (que no lo están), y al intentar configurarse con esos datos pues puede pasar de todo. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjaNjkACgkQtTMYHG2NR9UiYgCeOPeuQcUlyCYRNzTPi8U5Y8Uo HgUAn39Wr67x1/vdwkcP8FZHQXQjhs4W =+/9u -----END PGP SIGNATURE-----
El mié, 24-09-2008 a las 09:14 -0300, Juan Erbes escribió:
Aun así, es bastante extraño, porque generalmente para reprogramar o borrar una eeprom, son necesarias tensiones de al menos 15 volt (al menos por lo que recuerdo de la vez que programe un microcontrolador PIC 16C84, aunque ahora viene la versión 16F, que es flash, como los microcontroladores de Atmel).
Juan, que la electrónica avanza mucho cada dia. Hay chips de eeprom y de flash hasta a 3.3 volts.
-- Saludos Lluis
participants (7)
-
Camaleón -
Carlos E. R. -
Cristian Rodríguez -
Juan Erbes -
lluis -
Mauricio J. Adonis C. -
R. Mauricio Masís V.