Encuentran fallo en el microcódigo de los procesadores Intel Skylake y Kaby Lake

Desarrolladores de Debian han dado a conocer un error en el microcódigo de los procesadores Intel Skylake y Kaby Lake con hyper-threading activado, que podría resultar en problemas importantes para los propietarios y administradores de sistemas que trabajen con estos procesadores. Los problemas se dan en situaciones muy especificas y difíciles de reproducir para un usuario corriente.

[#1 lecheygalletas]

Yo estuve aquí.

[#2 jazcaba]

Yo soy administrador corriente?

[#3 Ovlak]

Un procesador i7 asi se convierte en un I5, ya que los i5 son i7 sin HT.
A lo tonto acaban de estafar el 50% del coste de un i7

[#4 pikutara]

#2 Si no sabes si lo eres es que lo eres.

[#5 --231265--]

No es algo novedoso, Intel suele suministrar microcódigo actualizado a los fabricantes, y éstos lo incluyen en sus bios. Por lo menos se puede solucionar con una actualización y no quedarte jodido como con los primeros Pentium ( es.wikipedia.org/wiki/Error_de_división_del_Intel_Pentium ).

En las bios de placas base anteriores a UEFI hay herramientas para parchear una bios con microcódigo actualizado, recuerdo haberlo hecho hace unos años para poder usar un Xeon socket 771 en una placa base socket 775.

[#6 --178580--]

Si lo he entendido bien, ¿sólo afecta a los i7? ¿Alguna lista de modelos concretos?

[#7 --231265--]

#6 Afecta a todos estos (6xxx, 7xxx):

ark.intel.com/products/series/95544/7th-Generation-Intel-Core-i7-Proce
ark.intel.com/products/series/88392/6th-Generation-Intel-Core-i7-Proce

Algún i5 de portátil que use hyperthreading probablemente también estará afectado.

La solución paliativa es desactivar el hyperthreading hasta que publiquen una actualización de la bios.

[#8 PussyLover]

#3 Hice bien de pillarme un i5.

[#9 Fibrizo]

"Los problemas se dan en situaciones muy especificas y difíciles de reproducir para un usuario corriente. "

Y la mitad de los meneantes están preocupados porque se creen especiales.

[#10 woopi]

Y hablando del tema ¿se desinflaron un poco las expectativas de los Ryzen? Hace nada se hablaba muchísimo de ellos.

#9 Bueno, también cuando el FDIV de Pentium, al principio INTEL minimizaba la cosa y decía que era improbable que afectara a ningún usuario. Al final tuvieron que cambiarlos.

[#11 gonas]

#9 ¿situaciones especiales? Seguro que no es difícil reproducir el error.

[#12 kampanita]

#8 Y yo amd

[#13 --50121--]

#10 Aquí uno con un Ryzen 1700, y bien inflado de expectativas cumplidas por el precio que me costó...gustazo de asignar más recursos de CPU a las máquinas virtuales, sin preocuparme porque se me ralentice nada.

[#14 frankiegth]

#5. No entiendo muy bien que puede tener que ver el microcódigo interno de la CPU con la BIOS de las placas base. ¿Es que el microcódigo de las CPUs de Intel se puede actualizar a traves de algunas BIOS de las placas base? Si puedes aclararlo se agradece.

[#15 frankiegth]

#8. Y yo en pillarme un i3, un Atom y un par de Core Duo.
#12. Prefiero Intel con sus úlitmas tarjetas gráficas integradas. ¿Qué tal son las tarjetas gráficas integradas de AMD? ¿Tienes alguna? ¿Sabes si las de AMD van bien con Gnu/Linux?

[#16 apetor]

#14 Sí, tanto en BIOS como en UEFI hay una etapa ( muy muy temprana ) donde se puede actualizar microcódigo "en caliente". Pero, si muy mal no recuerdo, creo que últimamente también se puede hacer despues, en fase de sistema operativo, desde un driver.

[#17 frankiegth]

#9. La 'situación especial' es tener el hyper-threading activado y con dos procesos lógicos activos en una misma CPU físca. Así de sencillo. Quitarle hierro a un problema no lo hace desaparecer.
_{(CC #10 #11)}

[#18 frankiegth]

#16. ¿En caliente significa que no queda la CPU reprogramada realmente? ¿Significa que se reprograma con cada nuevo arranque de la máquina, verdad? Si es así parece una solución un tanto chapucera.

[#19 apetor]

#18 Sí.

[#20 frankiegth]

#19. Pues eso crea una dependencia de la CPU respecto de la placa base que no tendría porque darse. Pensaba que las CPUs de Intel permitian la reprogramación interna del microcódigo interno de sus CPUs del mismo modo que se actualizan las BIOS de las placas base.
_{(CC #18)}

[#21 anv]

#18 Nadie ha dicho que no sea chapucero... de hecho, las partes parchadas funcionan más lento.

[#22 frankiegth]

#21. Creo que es mejor opción desactivar el hyper-threading y dejarse de historias.
#23. Pues no sé que decirte, prefiero una CPU segura a nivel de metal que estos parches a base de pegamento lógico.
_{(CC #16)}  

[#23 anv]

#22 Eso lo volvería más lento todavía... Pero windows no maneja demasiado bien el hyperthreading así que no se..

[#24 apetor]

#18 Sí. Tiene su sentido que sea así... una es la flexibilidad y evitar cargarse el micro si no funciona el update. Otra es que para ser permanente en el micro y en coste aceptable tendría que haber una EEPROM/FLASH que se actualizara y esta se cargara a una SRAM al arrancar; vamos, parecido a que lo haga la BIOS/UEFI ( que esta en una EEPROM/FLASH ) como lo hace ahora. No es una chapuza si entiendes que los procesadores son tan complejos que es difícil conseguir la perfección... así que con este sistema se consigue que se puedan arreglar cosas muy difíciles de prever en fase de pruebas por coste mínimo y de forma tan conveniente.

[#25 gonas]

#13 pues yo tengo un Ryzen 7 con 32MB de RAM y todavía estoy esperando a que saquen una BIOS que no de problemas.

[#26 gonas]

#10 Los Ryzen todavía no tienen finas las BIOS. Y todavía dan problemas con algun tipo de memorias.

[#27 logistark]

#17 bueno, no es tan sencillo, si lees el reporte original tienen que ser bucles de menos de 64 instrucciones y acceso a registros especificos.

Por lo que dicen, el patrón de código ese no es el tipico generado por gcc. Sino le estaría pasando a todo el mundo. Y les ha pasado a la comunidad de Ocaml por restricciones que impone este al gcc a la hora de genera código.

[#28 apetor]

#21 Es, simplemente, la solución menos mala. Más lento... sí, pero marginal. De hecho hay algunas mcupdates que mejoran el rendimiento.
#23 ¿ Qué versión de Windows ? uhmmm... no se.

[#29 kampanita]

#15 No, no tengo uso la tarjeta integrada, sigo con una GeForce 9500 que para lo que la uso yo me va genial. AMD hace ya mucho que se lleva bien con Linux, desde que liberaron el código de los drivers de nVidia

[#30 represaliado]

#17 Es más especial que eso, tiene que haber un bucle de menos de no-se-cuantas microoperaciones que esté usando unos registros concretos. Pero sí, yo no me fiaría de intel a la hora de calcular cuántos afectados hay...

[#31 anv]

#28 La verdad no se si lo han mejorado en el windows 10. La cosa es que desde el sistema operativo no se puede diferenciar entre un núcleo físico (un procesador de verdad) y uno lógico (uno que funciona como si fuera real pero comparte tiempo con otro). Al no diferenciarlos, windows trata trata de igual forma los físicos y los lógicos, y les distribuye el trabajo de igual forma.
El planificador de Linux, por el contrario, utiliza varios "trucos" para averiguar cuáles son físicos y cuáles lógicos, y trata de distribuir el trabajo primero entre los físicos. Los lógicos se tratan de dejar para cosas que consumen poca CPU. Siempre puede equivocarse pero al menos hace lo que puede.

[#32 lecheygalletas]

#1 tenía gracia cuando ha subido a portada con 50 votos y 1 comentario.

[#33 jesuscas]

Maldito i7

[#34 Jakeukalane]

El post original es muy chulo: news.ycombinator.com/item?id=14630183

[#36 pantulis]

#18 More or less, en Linux va así en el inicio www.kernel.org/doc/Documentation/x86/early-microcode.txt y por lo que he leído se puede hacer también "en caliente" con

echo 1 > /sys/devices/system/cpu/microcode/reload

En Windows parece que hay una capacidad parecida.

[#37 --50121--]

#25 Asus Prime-B350 Plus, RAM a 2933Mhz, sin problema alguno. De las MSI sí que he leído problemas.

[#38 gonas]

#37 ¿Cuánta RAM tienes? Con 16GB dan menos problemas. Con MSI no tienen ninguna configuración de 32GB soportada.

[#39 triturator]

#3 Pero si hasta los i3 tienen hyperthreading... Nivelazo de artículo

[#40 sillycon]

#22 No es un "parche a base de pegamento lógico", ahí hay un error de concepto.
Hoy en día las tablas de microcódigo de los Intel, la lógica del decodificador de instrucciones, están en una memoria flash interna. Es un sistema similar al de una FPGA. Es hardware, pero el cableado es reconfigurable.
Así que el "parche" no es tal, sino una nueva versión del microcódigo sin el bug.
Es como si al fabricante le compraras la CPU v1.001 en lugar de la V1.0

Por otra parte, tampoco entiendo muy bien la noticia porque bugs de microcódigo y sus actualizaciones las hay constantemente, y si han tardado años en detectarlo es que es prácticamente imposible reproducirlo.
En las distros principales de Linux se carga el microcódigo al arrancar, así que no hay problema de quedarse con una cpu desactualizada.

[#41 sillycon]

Esta noticia es un hype de libro que sólo sirve para crear alarma y confusión.
Actulizaciones del microcódigo de las CPUs hay constantemente, y no salen en los papeles.
Cuanto más tiempo lleva una CPU en el mercado más remotos y difíciles de reproducir son los bugs. En este caso han pasado años, así que que te toque el bug tiene que ser remotísimo. Es mil veces más inestable el sistema por el sistema operativo que por el hardware.
Ni se os ocurra deshabilitar el HT de vuestros procesadores. Vais a perder el 20% de velocidad por un puñetero hype sin ningún riesgo de alguien que quiere tráfico en su web.

[#42 --138738--]

#3 El microcódigo es actualizable, se creó precisamente para solventar este tipo de problemas. Una actualización de BIOS y listo.

Los i3, serie core m y Pentium G45XX también están afectados.

[#43 --138738--]

#15 Los i3 de 6ª y 7ª también están afectados.

[#44 --138738--]

#20 La alternativa antes era tirar la CPU, esta solución es bastante más rápida y efectiva.

[#45 --138738--]

#10 Son unos procesadores cojonudos por el precio que tienen, si el trabajo que realizas es muy dependiente del número de núcleos (edición de vídeo, renderizado 3d) puedes obtener el mismo rendimiento que las CPUs de gama alta de Intel a la mitad o menos de precio.

[#46 apetor]

#31 De donde te sacas eso ? Desde XP/W2K3 El scheduler y otras partes son HT-aware. Te puedo pasar hasta documentación, y de ahi fue mejorando pero vamos. Localidad de TLBs, caches y demas, incluidos.

[#47 apetor]

#40 No es una flash, es muchísimo mas rápida que una flash, y no es permanente, al reiniciar se va. En cuanto a que todo el microcódigo es así, nadie fuera de unos pocos en intel/AMD lo saben a ciencia cierta, pero se asume que no es así: a) el tamaño: si todo el microcódigo, aunque fuese solo de la fase de decodificación de la instrucción, tuviese que estar entera para todas las instrucciones, tela. No se, aquí puede ser que sea lo que dices, pero lo dudo. b) lo que parece que hacen es meter "excepciones" y donde hay una excepción hay microcódigo para "parchear" una instrucción en fase de decodificación o algún mecanismo que no necesariamente es de una instrucción concreta, sino de algún mecanismo o parte de una determinada circuitería.

[#48 apetor]

#36 Sí, mcupdate.sys era antes, ahora hay mcupdate_AuthenticAMD.dll y mcupdate_GenuineIntel.dll, que aunque parezcan ser de modo usuario, comprobado: son dlls de kernel ( parecido a un driver ). Curiosidad: la de AMD son 80KBs, la de Intel son 530KBs.

[#49 --50121--]

#38 Tengo con dos de 8GB, no compraré otros dos de 8GB hasta que la RAM vuelva a precios razonables, y no de timo como está ahora.

[#51 --543878--]

Estoy de acuerdo con #41. Me da pena porque considero que es una noticia interesante para el que quiera saber un poco más de como se solucionan este tipo de problemas, o para empezar que existen. Sin embargo el titular realmente sobra.

[#52 frankiegth]

#43. No hay problema, es un i3 de 2012 o anterior a ese año.
_{(CC #15)}