Я пытаюсь отключить все прерывания, включая NMI, на одном ядре процессора и поместить это ядро в бесконечный цикл с инструкцией JMP, нацеленной на себя (байт-код 0xEBFE
). Я пробовал это со следующим машинным кодом:
cli
in al, 0x70
mov bl, 0x80
or al, bl
out 0x70, al
jmp self (0xEBFE)
Я предположил, что отключение прерываний NMI также отключит сторожевой таймер, поскольку, согласно эта ссылка, сторожевой таймер является прерыванием NMI, но что произошло, когда я запустил этот код, примерно через 5 секунд мой компьютер обнаружил ошибку с кодом 0x101 CLOCK_WATCHDOG_TIMEOUT. Мне интересно, замечает ли Windows, что я отключил прерывания NMI, а затем снова включает их, прежде чем инициировать панику ядра. Кто-нибудь знает, как отключить сторожевой таймер в Windows 7?
@Joshua: высокоточное микротестирование - очевидный вариант использования для отключения сторожевого таймера. Но тогда запуск пустого бесконечного цикла кажется бессмысленным, согласен.
Теоретически можно загрузить Windows на меньшем количестве ЦП, чем есть в системе (конфигурация системы->загрузка->дополнительные параметры), но тогда нужно будет загрузить остальные ЦП вручную.
@AlexeyFrunze Я уже сделал это, я пытаюсь узнать больше о внутренностях своего оборудования, и именно поэтому я это делаю.
И каковы результаты этого, если они есть?
@AlexeyFrunze Я не совсем понимаю, о чем вы спрашиваете. Если вы имеете в виду результаты включения одного ядра, то оно успешно вешает систему без паники ядра.
Успешно? Это то, что вы делаете/ожидаете? Вешает всю систему, а не только этот процессор?
Я не думаю, что NMI являются проблемой здесь, я пишу ответ на это. Чтобы быть уверенным, если вы удалите маскирующий код NMI, будет ли сторожевой таймер по-прежнему проверять систему на наличие ошибок?
@MargaretBloom да, если я удалю код NMI, он все равно будет проверять систему на наличие ошибок с тем же кодом, на самом деле у меня изначально не было кода NMI, когда я впервые попробовал это.
@AlexeyFrunze Думаю, произошло недоразумение, я пытаюсь заблокировать одно ядро ни для чего другого, кроме как заблокировать одно ядро. Я хотел бы избежать того факта, что ОС вмешивается и проверяет систему на наличие ошибок. Что, если в будущем я захочу запускать код с отключенными прерываниями в течение длительного периода времени? Вот почему я чувствую, что мне необходимо изучать такие вещи.
Windows не совсем предназначена для этого. Напишите свою (мини) ОС. Или взломать линукс.
Так что это не HW WDT. Windows, вероятно, требует, чтобы каждый логический ЦП сообщал о своих тиках. Linux поддерживает горячее подключение ЦП, Windows должен тоже, но, возможно, только при паравиртуализации.
Я не думаю, что МЧС тут виноваты.
Внешние NMI устарели, их трудно маршрутизировать в системе SMP. Этот сторожевой таймер также устарел, он был либо вторичным PIT, либо ограниченным четвертым каналом основного PIT:
----------P00440047-------------------------- PORT 0044-0047 - Microchannel - PROGRAMMABLE INTERVAL TIMER 2 SeeAlso: PORT 0040h,PORT 0048h 0044 RW PIT counter 3 (PS/2) used as fail-safe timer. generates an NMI on time out. for user generated NMI see at 0462. 0047 -W PIT control word register counter 3 (PS/2, EISA) bit 7-6 = 00 counter 3 select = 01 reserved = 10 reserved = 11 reserved bit 5-4 = 00 counter latch command counter 3 = 01 read/write counter bits 0-7 only = 1x reserved bit 3-0 = 00 ----------P0048004B-------------------------- PORT 0048-004B - EISA - PROGRAMMABLE INTERVAL TIMER 2 Note: this second timer is also supported by many Intel chipsets SeeAlso: PORT 0040h,PORT 0044h 0048 RW EISA PIT2 counter 3 (Watchdog Timer) 0049 ?? EISA 8254 timer 2, not used (counter 4) 004A RW EISA PIT2 counter 5 (CPU speed control) 004B -W EISA PIT2 control word
Этого оборудования больше нет, его нет в современных системах. Я проверил свою машину, и у меня ее нет.
В чипсетах Intel его нет:
Есть только первичный PIT.
Современные таймеры — это таймер LAPIC и HPET (Linux даже прибегали к использованию регистров PMC).
Windows действительно поддерживает HW WDT, на самом деле Microsoft даже определила расширение ACPI: таблица ВДАТ.
Однако этот WDT может перезагружать или выключать систему только аппаратно, без вмешательства программного обеспечения.
// Configures the watchdog hardware to perform a reboot // when it is fired. // #define WATCHDOG_ACTION_SET_REBOOT 0x11 // // Determines if the watchdog hardware is configured to perform // a system shutdown when fired. // #define WATCHDOG_ACTION_QUERY_SHUTDOWN 0x12 // // Configures the watchdog hardware to perform a system shutdown // when fired. // #define WATCHDOG_ACTION_SET_SHUTDOWN 0x13
Microsoft установила довольно жесткие требования для этого WDT, поскольку его необходимо настроить как можно раньше в процессе загрузки, до перечисления PnP (т.е. перечисления PCI(e)).
Это не тот таймер, который проверил вашу систему на наличие ошибок. Кстати, у меня нет этого таймера (в моей системе отсутствует таблица WDAT), и я не ожидаю, что он будет найден на клиентском оборудовании.
Ошибка 0x101 связана с программным WDT, она возникает внутри функции в ntoskrnl.exe
.
Эта функция вызывается KeUpdateRunTime
и другой цепочкой вызовов, начинающейся с DriverEntry
:
Согласно Windows Internals, KeUpdateRunTime
используется для обновления внутреннего подсчета тиков Windows..
Я ожидаю, что за это будет отвечать только один логический процессор, хотя я не уверен, как именно Windows хранит время.
Я также ожидаю, что этот программный WDT будет реализован в режиме ведущий-ведомый: каждый ЦП увеличивает свой собственный счетчик, а разработанный ЦП периодически проверяет счетчики (или любую эквивалентную реализацию).
Кажется, на это намекает формулировка документации по проверке ошибки 0x101:
The CLOCK_WATCHDOG_TIMEOUT bug check has a value of 0x00000101. This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval.
Опять же, я не эксперт в этой части Windows (вероятно, пользователь MdRm), и это может быть совершенно неправильно, но если это не так, вам, вероятно, лучше последовать совету Алекса и загрузиться с одним менее логичным процессором.
Затем вы можете выполнить код на этом ЦП с помощью последовательности INIT-SIPI-SIPI, как описано в руководстве Intel, но вы должны быть осторожны, потому что процессор-выдатель использует пейджинг, а спящий еще нет (процессор запустится в режиме реального времени). Режим).
Инициализация ЦП может быть немного громоздкой, но в конце концов не слишком. Его кража может привести к другим проблемам помимо WDT, например, если Windows перенаправила прерывание только на этот процессор.
Я не знаю, есть ли API-интерфейс драйвера для отмены регистрации логического процессора, я ничего не нашел, просматривая экспорт hal.dll и ntoskrnl.exe.
Я не могу придумать ни одной веской причины для этого.