El kernel de Linux bloquea microcódigo problemático de Granite Rapids y el uso de APX
Antes de la rc4 de Linux 7.3 se ha fusionado un lote de correcciones x86 que evita machine checks en Xeon 6, arregla FRED en Panther Lake y frena las instrucciones APX en builds nativos.
Linux 7.3-rc4 todavía no ha salido, pero el árbol del kernel ya ha recibido el lote de correcciones x86/x86_64 que quedaba pendiente. Son tres frentes distintos: microcódigo de Intel Xeon 6 capaz de provocar un machine check, el soporte de FRED en Panther Lake que rompe juegos, y las compilaciones con -march=native que emitían instrucciones APX que el kernel no sabe usar.
El primero es el que más consecuencias tiene en producción. Intel Xeon 6 «Granite Rapids» recibe la revisión de microcódigo 0x1000405, que introdujo cambios internos en la interfaz de comunicación entre microcódigos de los que dependen las revisiones posteriores. Cargarla en un equipo que no venía ya con ella puede terminar en un machine check exception. El kernel ahora se niega a cargar 0x1000405 o cualquier revisión superior si el sistema no está ya en 0x1000405, tanto en la carga temprana como en la tardía. El parche está marcado para backport a las versiones estables.
La página de especificación de Intel recoge el caso como GNR98, la posibilidad de MCE con las versiones de microcódigo afectadas, y suma GNR101, por una revisión mínima de actualización en runtime incorrecta en el microcódigo 0x1000423 de Granite Rapids.
FRED en Panther Lake y el lío de APX
Intel FRED en Panther Lake también entra en el paquete: hacía que algunos juegos se colgaran o se congelaran al correr bajo Wine / Steam Play.
El otro arreglo toca a quien compila su propio kernel con optimizaciones nativas. Con CONFIG_X86_NATIVE_CPU y -march=native, el compilador empezaba a emitir instrucciones APX que usan los registros R16 a R31, los EGPR de Advanced Performance Extensions, en plataformas Intel que todavía no han llegado. El kernel no está preparado para sacar partido de APX, así que esas compilaciones montaban estragos en los sistemas de ingeniería de Intel. Ahora, al hacer un build nativo, el kernel bloquea explícitamente el uso de APX y de EGPR hasta que esté listo para aprovecharlos.
Todo esto viaja en el pull request que se fusionó antes del corte de la rc4. Para quien administre Granite Rapids, lo relevante es que la prevención del machine check llega también a las ramas estables, así que aparecerá en las distribuciones sin esperar al 7.3 definitivo. Y quien compile kernels a medida con -march=native debe saber que su build ya no aprovechará APX aunque el compilador quiera: es una salvaguarda, no un retroceso.
