AMD corrige un error en sus CPU Zen 1 y Zen 2 por el cual Linux podía tardar varios minutos en iniciarse

Si algo caracteriza a Linux es por un mejor uso del hardware como SO, donde suele ser bastante más liviano que Windows en cosas tan simples, y tan complejas al mismo tiempo, como el arranque. Pero no siempre es así, y como cualquier SO enfrenta diversos problemas, fallos o errores, que a veces, tardan mucho en corregirse. Este es uno de esos casos, puesto que durante bastante tiempo un error aleatorio ha estado cabreando a muchos ordenadores de sistemas y usuarios. Y es que las CPU AMD Zen 1 y Zen 2 desde mayo de 2023 han enfrentado un error por el que Linux generaba un retraso en su inicio de hasta varios minutos.

Este es un error conocido y comentado por la comunidad, pero parece que, de alguna forma, ningún desarrollador estaba al corriente, pese a que ha habido quejas desde hace ya año y medio. Sea como fuere, el problema se ha hecho viral gracias a un empleado de Nokia, el cual hace un mes puso de aliviar que 10 servidores con EPYC estaban tardando "una vida" en iniciarse.

AMD corrige un error con sus CPU Zen 1 y Zen 2 en Linux había un retraso al iniciar el SO

AMD-Ryzen-7-9800X3D-consumo-y-rendimiento-en-Linux

La gran cantidad de correcciones y características nuevas que se van implementando en Linux no siempre aciertan, y hay que remontarse al año pasado, a Linux 6.11 en concreto, cuando AMD implementó una actualización del microcódigo derivada de una mejora para el SMT que tocaba todas sus CPU desde nada menos que 2017. Esta mejora masiva en cuanto a número de CPU a la que afectaba parecía ir realmente bien, pero la realidad fue otra para las CPU Zen 1 y Zen 2, que curiosamente, mostraron un problema aleatorio que dificultó su detección.

Y es que de los pocos segundos que tardaba en iniciar Linux en prácticamente cualquier CPU moderna este problema con el microcódigo hacía que todo se fuese a minutos, a veces, bastantes minutos. El empleado de Nokia lo explica así:

“Normalmente, ese tiempo de espera (un paso del proceso de arranque) sería de unos 12 segundos con una variación de solo 1 o 2 segundos entre arranques. Pero al aplicar el parche mencionado, la variación aumenta. La mayoría de los arranques no sufren ningún impacto, en algunos arranques el tiempo aumenta en unos pocos o decenas de segundos, y en casos extremos ¡incluso en varios minutos!”

El problema se ha parcheado este fin de semana para Linux 6.13-RC1

AMD-fTPM-Ryzen-Linux-Linus

El ingeniero de AMD que creó el microcódigo del SMT decía lo siguiente a finales de 2022 cuando denominó al parche correspondiente como "carga tardía en ambos subprocesos":

Actualmente, la lógica de aplicación del parche verifica si la revisión debe aplicarse en cada lógica de CPU (hilo SMT). Por lo tanto, en los diseños SMT donde el motor de microcódigo se comparte entre los dos hilos, la aplicación solo en uno de ellos, ya que es suficiente para actualizar el motor de microcódigo compartido. Sin embargo, hay parches de microcódigo que hacen modificaciones por hilo, consulte la etiqueta de enlace a continuación. Por lo tanto, elimine la verificación de revisión e intente aplicar en cada hilo.

Esto es lo que también hace la BIOS, por lo que este método está muy probado. Por cierto, cambie solo las rutas tempranas. En las rutas de carga tardía, no tiene sentido hacer modificaciones por hilo porque si es un caso como en el bugzilla a continuación (eliminar una bandera CPUID), el kernel no puede ir y desutilizar las características que ha detectado que están allí. Para eso, uno debería usar la carga temprana de todos los modos".

Sobra decir que el problema afecta por igual a las CPU Ryzen o EPYC, tanto en Zen 1 como en Zen 2, donde ahora tras este parche para Linux podrán vaciar el búfer de la TLB después de aplicar el nuevo microcódigo, terminando con ello con este caso en concreto.