обнаружен новый процессор

[dibr]

     Или вот, скажем, компьютеры.

Я ведь почему раньше злой был в жеже сейчас мало писал? Потому что у меня велосипеда не было меня опять компьютерное железо радовало!
     Вот написал я две с половиной недели назад, что три дня боролся, чтобы "домашний сервер" не вис. И как оказалось, поторопился - он, сволочь, после этого всё равно вис,

Comments

[crazy_blu]

CPUID Data Tab

[dibr]

И чего? При протирании подолом майки у процессора изменяется CPUID?

[crazy_blu]

Могу предположить (полностью доку читать лень).
1. Вообще то "энергонезависимый" таймер есть везде, в том числе и на процессоре. Always Running APIC Timer (ARAT) capability. Несовпадение таймеров проца и BIOS == процессор меняли.
2. Батарейка не только питает BIOS. Резко выросшее напряжение какой-либо ноги == сигнал что процессор меняли. К примеру.

CPUID отдает очень много инфы по внутренностям процессора.

[dibr]

1. В принципе, верю - для этого, правда, нужно подтянуть к процессору питание ещё и от той самой батарейки, но если им зачем-то понадобился "таймер в процессоре" - то почему бы и нет.
2. А вот это как раз непонятно: ладно, если такое "обнаружение факта извлечения" можно влёгкую сделать как побочный эффект чего-то штатного (того же автономного таймера), и другое дело - если для этого нужно делать отдельную специальную цепь - как для "контроля не дёрнулось ли питание ножки". Для этого надо иметь какую-то мотивацию - а я не понимаю, зачем это могло бы понадобиться... :-)

[crazy_blu]

Ну вот "зачем" как-раз понятно. Каждый процессор со своим таймингом (так-же как и DIMM/DDR), к каждому нужно донастроить свои временные настройки, иначе работать не будет.

[dibr]

Что, неужели прямо вот каждый экземпляр процессора со своим таймингом, и под это нужно подстраиваться, причём не просто "считав CPUID и временные/частотные параметры, и выставив тайминги соответственно" (тогда хватило бы сохранения CPUID в nvram и сравнения сохранённого и текущего при загрузке), а как-то тонко и индивидуально?

Я всегда считал, что если CPUID и "прошитые в камень" тайминги нового процессора в точности совпадают с CPUID и таймингами старого, то и перенастроек не требуется - это если не тот же камень, то как минимум "такой же". А тогда не нужно и плотное слежение за сокетом, достаточно помнить cpuid и тайминги.

[crazy_blu]

Я так понимаю, всем занимается северный мост. Опрашивает чипы DDR, CPUID процессора, PCI-шину... Логика разная.
Как пример - тут у Интела интересовался, как делятся инструкции (микрокод) для параллельных потоков в ядрах процессора. Так вот они там не меряют очередь для каждого ядра, а бросают "наугад". Выяснено что это наиболее удачный по производительности вариант, на задержках по синхронизации задержки получаются больше.
Это про внутренние ядра, не про те, что видны снаружи :)

Так что логика работы везде разная. Видимо такую посчитали удобнее. Следить, не вынимали ли процессор, а если да - не заниматься сравнением насколько они похожи с предыдущим, а просто инициализировать времянки заново.

[tyomitch]

Разве не проще при каждой загрузке инициализировать тайминги, и сэкономить эту отдельную специальную цепь?

[dibr]

Нет :-)
Пользователь мог задать свои тайминги (и не только тайминги), отличные от дефолтных, поэтому при смене процессора неплохо бы напомнить о необходимости посмотреть на эти установки (пусть даже это дефолт, который не трогался), и подтвердить, что юзер не против.
Но почему сменой процессора считается не смена процессора (легко просекаемая по CPUID), а вот это вот вставление-вынимание - я не понимаю.

[tyomitch]

Если известно, что
а) юзер намеренно поменял настройки
б) юзер намеренно заменил процессор
-- то неужели юзер сам не выставит настройки для нового процессора, буде ему это надо?

[dibr]

Ты предполагаешь какого-то идеального пользователя, который никогда не забывает, что подкручивал что-то в биосе, и всегда предвидит последствия своих (и чужих) действий на два шага вперёд. А создателям биоса важно, чтобы пользователь НЕ СМОГ пройти мимо настроек при замене процессора, даже если сам пользователь про это забудет или решит забить.

Вот и вся разница подходов :-)

[dibr]

Забавная логика. Ну да, впрочем, "они так решили" - имеют право, в конце концов.