Tengo algunos sistemas de servidor integrados basados en i7-4700EQ que requieren hyperthreading. Todo está bien excepto que, en raras ocasiones, el indicador de hyperthreading en CMOS se desactiva. Mientras el hardware todavía esté en mi poder, puedo simplemente reiniciar, ingresar al CMOS y arreglar la configuración. (Todas las demás configuraciones en CMOS permanecen buenas, incluida la hora/fecha, así que creo que no es la batería).
Sin embargo, una vez implementado, no hay acceso a la consola. Si se pierde la configuración CMOS, el equipo podría "repararse", pero eso parece mucho trabajo para un problema muy simple.
Tengo entendido que el kernel de Linux lee el BIOS solo para inicializar las variables del kernel. ¿Es eso correcto?
Si eso es correcto, ¿hay alguna manera de decirle al kernel de Linux que ignore lo que informa el BIOS y simplemente habilite el hyperthreading en el kernel?
Si es posible, ¿existe una manera fácil (por ejemplo, configurar la línea de comando de grub) para hacer esto? De lo contrario, si es posible pero difícil, ¿se puede ignorar lo que dice el BIOS y habilitar el hyperthreading modificando la fuente del kernel y recompilando?
Si bien no pensé que funcionaría, ya lo intenté en /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash maxcpus=8 nr_cpus=8"
seguido con el uso de update-grub y el reinicio. (También intenté configurar maxcpus y nr_cpus individualmente).
He encontrado numerosos ejemplos de cómo deshabilitar el hyperthreading en un sistema en ejecución y luego volver a habilitarlo. Pero no ejemplos de habilitación si el kernel piensa incorrectamente que un humano deshabilitó intencionalmente el hyperthreading.
Finalmente, podría decir "hardware roto", pero eso no va a ganar ninguna "guerra" por sí solo. Si no es posible forzar la habilitación del hyperthreading a pesar del BIOS, esa es una respuesta válida, y la respuesta me será útil si incluye evidencia/explicaciones de por qué.
Respuesta1
Esto no es del todo cierto como regla general.
Ejemplo 1:SMILos controladores de interrupciones del firmware (también conocido como BIOS) aún se ejecutan después de que se inicia el kernel, con un nivel de privilegio más alto que el kernel. Eres bienvenido a intentar luchar contra SMM; No espere que Linux esté particularmente interesado en ayudarlo.
Ejemplo 2: El firmware de "arranque seguro" puede ser autoactualizable, pero generalmente no se considera una buena idea permitir que el sistema operativo sobrescriba el firmware con una imagen arbitraria. Por lo tanto, antes de iniciar el sistema operativo/gestor de arranque, el firmware debe configurar un indicador de hardware para evitar escrituras en el chip del firmware. Una vez configurada, no debería ser posible desarmar la bandera sin reiniciar. O algo así. Aparece porque, por supuesto, algunos firmwares no lo hicieron correctamente... un ejemplo esaquí.
No sé si permitir SMT es otro ejemplo o no.
No es deseable luchar contra el firmware. Es especialmente indeseable luchar contra el firmware si su sistema operativo (Linux) no intenta soportarlo. (Por ejemplo, comocombate el firmware sobre los comandos ACPI ATA. O de manera más constructiva, Linux ignora la información del estado C del BIOS ACPI, si se está ejecutando en una CPU Intel de la que ya conoce información precisa del estado C).
(Además, es posible que su objetivo aún no se cumpla si se aplica la regla general. Es posible que necesite que el BIOS le indique el diseño, por ejemplo. Y puede haber razones por las que no quiera asumir que el diseño es estático. Es decir, razones por las cuales No es una buena idea parchear el kernel para ignorar las tablas ACPI proporcionadas por el BIOS y, en su lugar, usar tablas ACPI que capturó al iniciar con todas las configuraciones deseadas del BIOS).
Incluso si su objetivo es posible, creo que entraría en detalles específicos del hardware. Sería muy impresionante si encontraras una manera de habilitar SMT en el kernel, eso fuenoespecífico del hardware. No confiaría completamente en que una respuesta a esta pregunta sea canónica, si no especifica que se ha probado en una placa base y una versión de firmware coincidentes, y usted no ha especificado cuáles son.
Sobre esa base, no creo que los desarrolladores de Linux intenten ayudarlo aquí. No es un problema muy común.