LINUX.ORG.RU

Вышел Memtest86+ v6.00

 

Вышел Memtest86+ v6.00

4

1

24 октября вышел релиз Memtest86+ v6.00 — утилиты для тестирования оперативной памяти.

Основные изменения:

  • добавлена поддержка UEFI;
  • добавлена поддержка x64 Long Mode Paging;
  • реализована поддержка до 256 ядер CPU;
  • добавлена автоматическое определение DDR4 & DDR5;
  • добавлена поддержка профилей XMP 3.0 (Extreme Memory Profile);
  • реализовано автоматическое определение AMD Zen 1/2/3/4;
  • реализовано автоматическое определение процессоров Intel вплоть до 13го поколения;
  • улучшена поддержка AMD pre-ZEN CPUs;
  • улучшена поддержка старых чипов nVidia и AMD;
  • добавлена поддержка SDRAM;
  • множество улучшений и багфиксов.

>>> Подробности

★★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от MrClon

В современных реалиях 180 Кб - это ноль, 5 и даже 25 Мб - это тоже ноль. Зачем выключать (ака «чистить ядро»)? Как этот неиспользующийся код помешает протестировать память?

x-signal ★★
()
Ответ на: комментарий от x-signal

Как этот неиспользующийся код помешает протестировать память?

Примерно так же как законы физики, логики, анатомии, физиологии и здравый смысл мешают тебе запихать свой собственный глаз в анус и внимательно изучить себя внутри. Ты уже достаточно тупняка написал, остановись.

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

Да ты похоже вообще не в теме, если сравниваешь законы реального и виртуального мира) Здесь возможно всё, даже то, о чём ты тут не постеснялся написать.

x-signal ★★
()
Ответ на: комментарий от x-signal

Безудержное счастье жителей «виртуального мира» нам ни к чему, у нас тут реальное электричество плывёт черес реальные полупроводники, обозначая содержимое реальных ячеек памяти.

token_polyak ★★★★★
()
Ответ на: комментарий от x-signal

Да ты похоже вообще не в теме

Я более в теме чем ты, тебе уже объяснили почему «лишний код» это плохо для тестировщика памяти, но ты не понял, так что остановись, хватит пороть чушь.

Здесь возможно всё, даже то, о чём ты тут не постеснялся написать.

Не путай «виртуальный» мир с фентези. «Возможно всё» в плохом фентези, где мир может невозбранно самому себе противоречить, потому что " магия", а законы логики и физики (пусть даже и выдуманные, но непротиворечивые) обязаны действовать и в «виртуальном» мире, иначе он тупо развалится. Который кстати никакой не виртуальный, но это уже мелочи.

Объясняю на пальцах — Мюнгхаузен не может поднять себя за волосы, программа не может проверять тот участок в котором она сама исполняется. Но при этом она должна как то это сделать, для этого она себя релоцирует. Но тут есть риск пропустить «плавающую» ошибку. В идеале она вообще должна уместиться в кэш и не занимать физическое ОЗУ на время проверки. Для обоих случаев, для уменьшения шансов пропустить плавающую ошибку, и для возможности целиком залезть в кэш, код должен быть крайне «сухим» и экономным, чего авторы memtest и добиваются собсно.

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

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от Jameson

программа не может проверять тот участок в котором она сама исполняется

Всё понятно, ты реально не шаришь…

x-signal ★★
()
Ответ на: комментарий от Jameson

программа не может проверять тот участок в котором она сама исполняется

Поэтому Memtest в процессе работы себя перемещает. Чем он больше, тем больше вероятность задеть сбойный участок.

question4 ★★★★★
()
Ответ на: комментарий от Jameson

Мюнгхаузен не может поднять себя за волосы

Ты опять пытаешься применить законы Ньютона к IT. Пойми, здесь работают совсем другие законы и правила ;)

x-signal ★★
()
Ответ на: комментарий от x-signal

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

Кончай постить тупняк. Если так хочешь тестировать память из линукса, используй юзерспейсовый memtester

MrClon ★★★★★
()
Ответ на: комментарий от x-signal

Предлагаешь двигать весь код работающего ядра туда-сюда по памяти, вместо того чтобы просто выкинуть весь этот код (99.9% которого для этой задачи нафиг не нужны)?

MrClon ★★★★★
()
Ответ на: комментарий от x-signal

А в х86 есть какой-нибудь On-Chip RAM, который можно использовать в качестве, собственно, ОЗУ, пока основная память не готова к работе?

apt_install_lrzsz ★★★
()
Ответ на: комментарий от apt_install_lrzsz

ЕМНИП как раз memtest86 славился тем что целиком в кэш умещался, при условии наличия кэша достаточного размера. Не знаю как с этим сейчас, но раньше это была его фича.

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

Ну вот тут выше по теме приводили пример размера memtest86 в 180k. На картинке в новости указан кэш четвёртого пня в 256k. Поэтому, думаю, даже сейчас всё неплохо.

Просто соображаю идею, как бы можно было корректно провести проверку ОЗУ реально используя при этом ядро целой настольносерверной ОС.

apt_install_lrzsz ★★★
()
Ответ на: комментарий от apt_install_lrzsz

Кажется нет. В любом случае инициализация памяти происходит где-то на ранних стадиях включение пекарни, так что сделать что-то до этого можно разве-что прошив свой BIOS. Другое дело что уже memtest86 с запасом влезает в кэш современных процов, теоретически можно уже после загрузки memtest86 в память и передачи ему управления, полностью скопировать нужный код в кэш проца и свободно тестировать всю память. Но я ХЗ позволяет-ли x86_64 в ручном режиме рулить серверным кэшем, или там что-то на манер линуксового дискового кэша

MrClon ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.