У меня есть несколько встроенных серверных систем на базе i7-4700EQ, которым требуется гиперпоточность. Все хорошо, за исключением того, что в редких случаях флаг гиперпоточности в CMOS отключается. Пока оборудование у меня, я могу просто перезагрузиться, зайти в CMOS и исправить настройки. (Все остальные настройки в CMOS остаются в порядке, включая время/дату, поэтому я думаю, что это не батарея.)
Однако после развертывания нет доступа к консоли. Если настройки CMOS потеряны, оборудование можно "отремонтировать", но это кажется большой работой для очень простой проблемы.
Я понимаю, что ядро Linux считывает BIOS только для инициализации переменных ядра. Это правильно?
Если это так, есть ли способ заставить ядро Linux игнорировать сообщения BIOS и просто включить гиперпоточность в ядре?
Если возможно, есть ли простой способ (например, настройка командной строки grub) сделать это? Или, если возможно, но сложно, можно ли игнорировать то, что говорит BIOS, и включить гиперпоточность, изменив исходный код ядра и перекомпилировав его?
Хотя я и не думал, что это сработает, я уже попробовал в /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash maxcpus=8 nr_cpus=8"
затем использовал update-grub и перезагрузился. (Я также пробовал устанавливать maxcpus и nr_cpus по отдельности.)
Я нашел множество примеров отключения гиперпоточности в работающей системе и ее повторного включения. Но не примеров включения, если ядро ошибочно считает, что человек намеренно отключил гиперпоточность.
Наконец, я мог бы заявить о "сломанном оборудовании", но это само по себе не выиграет ни одной "войны". Если невозможно принудительно включить гиперпоточность, несмотря на BIOS, это допустимый ответ - и ответ будет мне полезен, если он будет включать доказательства / объяснения, почему.
решение1
Как правило, это не совсем так.
Пример 1:СМИОбработчики прерываний прошивки (они же BIOS) продолжают работать после загрузки ядра, на более высоком уровне привилегий, чем ядро. Вы можете попытаться бороться с SMM; не ждите, что Linux будет особенно заинтересован в помощи вам.
Пример 2: Прошивка "безопасной загрузки" может быть самообновляемой, но обычно не считается хорошей идеей позволять ОС перезаписывать прошивку произвольным образом. Поэтому перед загрузкой ОС / загрузчика прошивка должна установить аппаратный флаг, чтобы предотвратить запись в чип прошивки. После установки флаг не должен быть снят без перезагрузки. Или что-то в этом роде. Это происходит, потому что, конечно, некоторые прошивки не делают этого должным образом... один пример:здесь.
Я не знаю, является ли разрешение SMT еще одним примером или нет.
Нежелательно бороться с прошивкой. Особенно нежелательно бороться с прошивкой, если ваша ОС (Linux) не пытается вас поддерживать. (Например, так как онаборется с прошивкой по поводу команд ACPI ATA. Или, что более конструктивно, Linux игнорирует информацию о состоянии C из ACPI BIOS, если он работает на процессоре Intel, для которого он уже знает точную информацию о состоянии C).
(Кроме того, ваша цель все равно может не быть достигнута, если применяется общее правило. Например, вам может понадобиться, чтобы BIOS указал вам схему. И могут быть причины, по которым вы не захотите предполагать, что схема статична. Например, причины, по которым не стоит патчить ядро, чтобы оно игнорировало таблицы ACPI, предоставленные BIOS, и вместо этого использовало таблицы ACPI, которые вы захватили при загрузке со всеми желаемыми настройками BIOS).
Даже если ваша цель достижима, я думаю, вы вдадитесь в подробности, связанные с оборудованием. Было бы очень впечатляюще, если бы вы нашли способ включить SMT в ядре, это былонетаппаратно-зависимый. Я бы не стал полностью доверять ответу на этот вопрос как каноническому, если бы в нем не было указано, что он был протестирован на соответствующей материнской плате и версии прошивки, а вы не указали, какие именно.
Исходя из этого, я не думаю, что разработчики Linux будут пытаться поддержать вас здесь. Это не очень распространенная проблема.