[1.79.3] Начиная с данной сборки УБУ, для кореектной работы МСЕ теперь требуется Python v3.7 или вышг. Также следует установить 2 библиотеки: - pip install colorama - pip install pltable
[1.75] Куча нововведений в папках Интел [1,72] MMTool К сожалению, невозможно предугадать какой муму отработает корректно. Поэтому используйте 2 разные версии мумутула - 5.0.0.7 как "mmtool_a4.exe" и 5.2.0.2x+ как "mmtool_a5.exe" Использование только одной версии не пригодно для многих бивисов на Aptio. [1.71] VROC Для обновления VROC with VMD требуется 2 файла, пример в папке Intel\VROC Штатные файлы RAID и sSATA укладываются, как обычно, в папку RSTe. MMTool Заложена поддержка 2-ух различных версий MMTool на перспективу. На данный момент используется одна версия, рекомендуется 5.0.0.7. Переименовать как "mmtool_a4.exe"
[1.70] IRST/IRST(e) Начиная с версии 1.70 пользователь самостоятельно подбирает нужные версии файлов для создания RAID массивов.
1) В послденее время опять участились жалобы на наличии вируса в пакете UBU, якобы МСЕ,ехе содержит вирус. Поэтому принято решение, что вместо ехе файла теперь будет py исхотдный Пайтона. Чтобы была корректная работа с микодами вам необходимо установить пакет Ptyhon версии 3.7 или выше. А также две библиотеки: - colorama - PLTable Как это сделать уаказано на ГитХабе в репе МСЕ. Вы можете юзать м ехе файл, но скачивать его будете самостоятельно. Если установите Пайтон то у вас появится возможность юзать другие приложения на Пайтон, которых очень много. 2) Все архивы с файлами теперь здесь https://mega.nz/#F!MSRDxSqR!5etS-te7ZqRQX9Zb25es_A 3) На данный момент рекомендуется использовать UEFITool v0.25.0 (и не выше), до выяснения
Соблюдайте Правила конференции и используйте поиск по теме. Мешающие чтению картинки и видео убирайте под спойлер. Сообщения с избыточным цитированием могут исправляться или удаляться без уведомления их авторов.
Последний раз редактировалось DeathBringer 22.02.2025 23:07, всего редактировалось 1045 раз(а).
Всем доброго времени суток. Intel выпустила обновление микрокода против Spectre для Ivy Bridge и Sandy Bridge У меня i7 2600k и материнка asus p8h67,как мне подсказали,вендор моей материнки уже устарел и на него врятли будут делать обновление биоса от микрокода. Может тут кто нибудь слепить эту обновку для моего 2600к? Спасибо заранее
К сожалению, это обновлялка загружает микрокод слишком поздно и защита от Spectre не активируется.
telemeh писал(а):
"Поговаривают" что использование VMware CPU Microcode Update Driver-а с новых микрокодом не даёт защиты от Spectre.
M$ для win7 выпустила обновление ядра (где проверяется наличие поддержи IBRS/IBPB/LFENCE в процессоре), но не выпустила новую базу mcupdate_GenuineIntel.dll (микрокод, который реализует и рапортует об этих фичах ) ? замкнутый круг ?
Последний раз редактировалось Mov AX _ 0xDEAD 14.03.2018 19:52, всего редактировалось 1 раз.
DeathBringer That makes sense to my as well as the OS shouldn't know about the microcode header with 0xFF revision, only BIOS. So why do OEMs do that trick then if their own BIOS does not have any other inserted ucode of the same CPUID/Platform combo? There must be a reason.
Member
Статус: Не в сети Регистрация: 28.09.2004 Откуда: Магнитогорск Фото: 78
DeathBringer Тепла тебе и света добрый человек! Слона я и не заметил (совсем старый стал) - реально стояло толко для чтения. Прописал "00" по адресам 1814F, 3C721, 3C724 - всё заработало с Apito 4 - проверил в версии UBU_v1_69_16.
Последний раз редактировалось DeathBringer 15.03.2018 19:31, всего редактировалось 1 раз.
Куратор темы Статус: Не в сети Регистрация: 07.08.2003
plutomaniac In BIOS of my motherboard microcode is loaded by three different modules. I've seen similar in many BIOS. I think in first module BIOS chooses microcode with 0xFF revision (for overclocking) or normal one. And "0xFF trick" is used to prevent updating microcode in other two modules. P.S. Now I made loading microcode in two step: in first step 0x07 revision of microcode is loaded, in second - microcode is updated to latest revision.
Последний раз редактировалось DeathBringer 15.03.2018 19:32, всего редактировалось 1 раз.
DeathBringer I see, that's pretty cool. So basically, if I understand properly, the goal is to load a microcode earlier to take advantage of something that shouldn't be allowed and then re-load a proper newer one once some settings are applied and cannot be changed until next reset. Indeed, at the 100-series BIOS with 0xFF, there is also a proper/newer equivalent CPUID/Platform microcode which presumably gets loaded later during BIOS stages.
#77
But of course that trick requires the use of microcodes which allowed something Intel doesn't want (HSW, SKL) and more importantly, support from the OEM to enable the trick at BIOS.
Member
Статус: Не в сети Регистрация: 18.02.2008 Фото: 0
Сижу работаю в Access, система сама резко выключается и через секунду снова включается. на этот раз с Mc 0x70 для KBL на Asus. примерно за неделю с этим Mc это впервые... Вторая система на MSI с Mc 0x70 для KBL стоит в майнинге и пока что стабильна, в отличии от постоянных выключений с 0x84 в течении суток. Подобное поведение систем хрен отследишь без аппаратных средств, а концы искать нужно дабы быть на 100% в чём то уверенным. логи OS естественно ничего не фиксируют. я короче хз что это за чудеса... но меня это уже бесит. Что может послать команду на резкое отключение системы и её последующий запуск. на Mc вообще как то не похоже, больше на сбой в ME.
Куратор темы Статус: Не в сети Регистрация: 20.04.2012 Откуда: Россия
jjxaker, при таком раскладе можно грешить от розетки, что выдала меньше 220В до мелкого кондара на любом изделии, а также на любой запущенный софт, что отработал в ребут.
Member
Статус: Не в сети Регистрация: 18.02.2008 Фото: 0
LS_29 Да в том то и дело это очень противная ситуация. конечно такие факторы как стабильное питание, софт, проблемы железа, можно откинуть сразу. но от этого не легче...
Куратор темы Статус: Не в сети Регистрация: 20.04.2012 Откуда: Россия
jjxaker, у мкня есть 2 прикола. 1 прикол это ноут от асус, тоже имеет привычку иногда ребутиться ни с того ни с чего. Я уже мозг спалил, так и не решил этой проблемы. А второй прикол еа одном компе сиабильно раз в полгода вышибает модуль памяти, мозг пожалел и затарил плашками про запас.
Куратор темы Статус: Не в сети Регистрация: 07.08.2003
Dex В большинстве случаев восстановление работоспособности инженерных процессоров в новых версиях BIOS не сводится к отключению какой-то блокировки. Поэтому это очень сложное исследование, по стоимости может даже превысить стоимость нового процессора.
Добавлено спустя 1 час 36 минут 36 секунд: jjxaker У меня система после отката на 0x22 (Haswell) работает стабильно. По крайней мере пока. Может, на "KBL на Asus" обновился микрокод в ОС? Текущую версию после загрузки операционки проверяли?
Member
Статус: Не в сети Регистрация: 18.02.2008 Фото: 0
DeathBringer писал(а):
У меня система после отката на 0x22 (Haswell) работает стабильно. По крайней мере пока.
Ну вот и я к второй системе претензий не имею после отката, как часы всё.
DeathBringer писал(а):
Может, на "KBL на Asus" обновился микрокод в ОС?
Не, я же его вырубил. отключение видно в ПО и реестре. Ну офис 2016 обновлялся, он точно такое делать не умеет. это уже фантастика была бы))) Просто вот оно вылезло и всё, и вот когда я снова поймаю эту проблему. через час, через сутки, через год! это просто печально когда проблемы не постоянны. Буду наблюдать дальше, что ещё остаётся то.
LS_29 писал(а):
ноут от асус, тоже имеет привычку иногда ребутиться ни с того ни с чего
Ну тут хотя бы можно грешить на то что чипсет отваливается. обычно в таких ситуация феном прогрели и всё ок. стандартная болячка
Последний раз редактировалось jjxaker 15.03.2018 13:11, всего редактировалось 1 раз.
Сейчас этот форум просматривают: seavovk и гости: 23
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения