Вышел Memtest86+ v6.00

Ждем ебилдов!

Флатпаков же

Точно!

добавлена поддержка UEFI; добавлена поддержка x64 Long Mode Paging; реализована поддержка до 256 ядер CPU […]

Зачем они добавляют то, что давно уже есть в ядре Linux? Не проще сделать тест памяти на базе ядра?

Сделать велосипед на базе боинга? Отличная идея!

Годная вещь, авторам всех благ.

Иногда правда требует гонять сервак непрерывно неделю, чтобы выявить проблему, но всё же.

Зачем они добавляют то, что давно уже есть в ядре Linux? Не проще сделать тест памяти на базе ядра?

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

Годная вещь, помогла диагностировать проблемы с оборудованием минимум пару раз в жизни.

Так же. Хотя гоняю на работе уже недели 2 как :). И именно EFI-версию (докинул в комплект к rEFInd-у). Как раз помогло вычислить криво работающий слот на одном компе.

почему линукс сразу?

Исходники есть и поддержка современного железа. На базе винды сделать тест не получится - подсистема управления памятью мешать будет, так что придётся в ней покопаться, а исходников нет…

Проще говоря, в линукс ядре много чего лишнего для данной задачи

Ну и ладно - лишнее не использовать, сейчас же не то время, когда надо экономить ресурсы.

Насколько оно уступает платному Memtest86 Pro?

сейчас же не то время, когда надо экономить ресурсы.

гори в аду

нинасколько

Зачем они добавляют то, что давно уже есть в ядре Linux? Не проще сделать тест памяти на базе ядра?

Не проще. Каждый лишний байт программного кода увеличивает вероятность ее загрузки в страницу со сбойной ячейкой с последующими фальшивыми результатами теста.

Вот представь себе код (язык произвольный, главное суть улови):

put(address,1);
if (get(address!=1)) {printf("address ".address."failed");}

Работает примитивно, да ? Записал по адресу единицу, затем если с этого адреса не считалась единица - значит адрес сбойный.

Как думаешь, а что если при загрузке этого кода в память, блок "(get(address!=1))" загрузится в место со сбойной ячейкой, и этот сбой попадет как раз в то место которое я выделил жирным ?

И чем больше грузится в память, тем больше увеличивается вероятность подобной некорректной работы самого мемтеста.

Не, ну это понятно. Тест должен быть написан в пространстве ядра и с соответствующим обходом данной нехорошей ситуации.

гори в аду

Сравни размер бинарников мемтеста и ядра, много на этой разнице выиграешь?..

Бесполезная утилита, прохождение тестов никак не гарантирует что оперативка будет работать стабильно. Годится только чтобы выявить прям совсем битую память.

1024 KB MEMORY OK.

Это справедливо по отношении к любой проверке или обследованию. Надо - внезапно - думать головой.

Нет, не к любой

вероятность того что сбой заденет программный код и не вызовет при этом зависание, примерно такая же как метеорит упадет персонально на вас в населенном городе среди толпы :)

добавлена поддержка SDRAM;

Это как? Ее что выбрасывали? Или оно память старше DDR не поддерживало?

Не, ну это понятно. Тест должен быть написан в пространстве ядра и с соответствующим обходом данной нехорошей ситуации.

Ядро - это такая же программа, которая грузится в ОЗУ.

Это тут ни при чём. Ресурсы надо экономить. Всегда, если это не в ущерб функционалу. Иначе получается помойка в итоге.

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

вероятность того что сбой заденет программный код и не вызовет при этом зависание, примерно такая же как метеорит упадет персонально на вас в населенном городе среди толпы :)

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

Ага, ресурсы же бесконечные.

Если битая ячейка-две-три, то вероятность сегфолта крайне мала

Ну тест же и эти ячейки, в которых лежит код, тоже проверит.

Ну тест же и эти ячейки, в которых лежит код, тоже проверит.

Да. Но выше я показал вариант, когда этот механизм сам зафейлится.

В общем подключать сюда ядро - глупая идея.

Судя по списку изменений, мемтест уже сам превращается в ядро, я предложил только ускорить этот процесс и воспользоваться тем, что давно уже написано, а не изобретать свой велосипед)

сейчас же не то время, когда надо экономить ресурсы

Убейся ап стену :)

улучшена поддержка AMD pre-ZEN CPUs;
улучшена поддержка старых чипов nVidia и AMD;

Оно перестало зависать на 20%-22% многопоточных тестов на некоторых АМД процах, как было в 5х версиях на Phenom I 9650 и Phenom II x4 945 (с этой фигнёй я сам лично сталкивался, как с остальнымы - х.з.)?

Убейся ап стену :)

Непременно, если обоснуешь, зачем экономить ресурсы в программе-тесте памяти, если на машине исполняется только она одна =)

С ростом объёма неиспользуемого кода вероятность растёт. А в linux kernel используемом в качестве мемтеста объём неиспользуемого кода будет вполне приличным даже если выпилить все опциональные модули

# du -sh /boot/{vmlinuz-4.19.0-22-amd64,memtest86+.bin}
5,1M	/boot/vmlinuz-4.19.0-22-amd64
180K	/boot/memtest86+.bin

Конечно из ядра многое можно легко выкинуть (просто отключить сбору моделей ФС и прочего такого), но легко выключить можно не всё. И имей в виду что vmlinuz это сжатый образ, и сжат он хорошо (раз эдак в пять)

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

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

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

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

сейчас же не то время, когда надо экономить ресурсы

стрелять из пушки по воробьям — это не только про «ресурсы»

Ждем сборки новой версии флешки https://www.system-rescue.org/ с новой версией Memtest86+ UP: фичу реквест уже кто-то написал: https://gitlab.com/systemrescue/systemrescue-sources/-/issues/308

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

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

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

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

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

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

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

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

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

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

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

зачем экономить ресурсы в программе-тесте памяти, если на машине исполняется только она одна

Чтобы занимать меньше места и облегчить локализацию сбойных модулей.

вероятность того что сбой заденет программный код и не вызовет при этом зависание, примерно такая же как метеорит упадет персонально на вас в населенном городе среди толпы :)

Неделю работал с непонятными глюками и падениями браузера, пока сообразил проверить память. Линукс не повис ни разу.

Сравни размер бинарников мемтеста и ядра

Ядро 5.15.32 — 8910800 без модулей, мемтест — 178704. В 49,9 раз.

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

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