Tenho alguns sistemas de servidores incorporados baseados em i7-4700EQ que requerem hyperthreading. Tudo está bem, exceto que, em raras ocasiões, o sinalizador de hyperthreading no CMOS é desativado. Enquanto o hardware ainda estiver em minha posse, posso simplesmente reiniciar, entrar no CMOS e corrigir a configuração. (Todas as outras configurações no CMOS permanecem boas, incluindo a hora/data, então acho que não é a bateria.)
No entanto, uma vez implantado, não há acesso ao console. Se a configuração do CMOS for perdida, o equipamento poderá ser “consertado”, mas isso parece muito trabalhoso para um problema muito simples.
Meu entendimento é que o kernel do Linux lê o BIOS apenas para inicializar as variáveis do kernel. Isso está correto?
Se isso estiver correto, existe uma maneira de dizer ao kernel do Linux para ignorar o que o BIOS relata e simplesmente ativar o hyperthreading no kernel?
Se possível, existe uma maneira fácil (por exemplo, configuração da linha de comando do grub) de fazer isso? Caso contrário, se possível, mas difícil, ignorar o que o BIOS diz e ativar o hyperthreading pode ser conseguido modificando a fonte do kernel e recompilando?
Embora eu não achasse que funcionaria, já tentei em /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash maxcpus=8 nr_cpus=8"
seguido do uso do update-grub e da reinicialização. (Também tentei configurar maxcpus e nr_cpus individualmente.)
Encontrei vários exemplos de como desabilitar o hyperthreading em um sistema em execução e depois reativá-lo. Mas não são exemplos de ativação se o kernel pensar incorretamente que um humano desativou intencionalmente o hyperthreading.
Finalmente, eu poderia alegar “hardware quebrado”, mas isso não vai vencer nenhuma “guerra” por si só. Se não for possível forçar a ativação do hyperthreading apesar do BIOS, essa é uma resposta válida - e a resposta será útil para mim se incluir evidências/explicações do porquê.
Responder1
Isto não é inteiramente verdade como regra geral.
Exemplo 1:SMIOs manipuladores de interrupção do firmware (também conhecido como BIOS) ainda são executados após a inicialização do kernel, em um nível de privilégio mais alto que o kernel. Você está convidado a tentar lutar contra o SMM; não espere que o Linux esteja particularmente interessado em ajudá-lo.
Exemplo 2: O firmware de “inicialização segura” pode ser autoatualizável, mas geralmente não é considerado uma boa ideia permitir que o sistema operacional sobrescreva o firmware com uma imagem arbitrária. Portanto, antes de inicializar o sistema operacional/bootloader, o firmware deve definir um sinalizador de hardware para evitar gravações no chip do firmware. Uma vez definido, não deverá ser possível desmarcar o sinalizador sem reinicializar. Ou algo assim. Isso surge porque é claro que alguns firmwares negligenciaram fazê-lo corretamente... um exemplo éaqui.
Não sei se permitir o SMT é outro exemplo ou não.
É indesejável lutar contra o firmware. É especialmente indesejável lutar contra o firmware se o seu sistema operacional (Linux) não estiver tentando oferecer suporte a você. (Por exemplo, comoluta contra o firmware sobre comandos ACPI ATA. Ou, de forma mais construtiva, o Linux ignora as informações de estado C do BIOS ACPI, se estiver rodando em uma CPU Intel para a qual já conhece informações precisas de estado C).
(Além disso, seu objetivo ainda pode não ser seguido se a regra geral for aplicada. Você pode precisar do BIOS para informar o layout, por exemplo. E pode haver razões pelas quais você não gostaria de assumir que o layout é estático. Ou seja, razões pelas quais não é uma boa ideia corrigir o kernel para ignorar as tabelas ACPI fornecidas pelo BIOS e, em vez disso, usar as tabelas ACPI que você capturou ao inicializar com todas as configurações desejadas do BIOS).
Mesmo que seu objetivo seja possível, acho que você entraria em detalhes específicos de hardware. Seria muito impressionante se você encontrasse uma maneira de habilitar o SMT no kernel, que fossenãoespecífico de hardware. Eu não confiaria inteiramente em uma resposta para esta pergunta como canônica, se ela não especificasse que foi testada em uma placa-mãe e versão de firmware correspondentes, e você não especificou quais são.
Com base nisso, não creio que os desenvolvedores Linux tentarão apoiá-lo aqui. Não é um problema muito comum.