Комментарии 26
Интересный эффект:
Это парсер глючит или я чего-то недопонял?
В более хитрых случаях, слышал, что кроме банального «простукивания» ячеек памяти до бесконечности, этот инструмент использует некоторые специальные паттерны данных, на которых ошибки в работе DDR выявляются с большей вероятностью.
Вот кстати буквально вчера я с подобным случаем столкнулся.
Глюк был нестабильный: то появится, то нет. Грешил на сами диски, но нет: глюк появлялся независимо от того, с какого диска на какой копируешь данные. Запустил средство проверки памяти (windows 7) — выставил самый суровый режим, оно что-то там несколько часов попыхтело, никаких ошибок не нашло. Дальше мысль пошла уже в сторону софта: злобных вирусов (что вряд ли) или кривых программ-оптимизаторов (Intel Rapid Storage — но он уже лет семь без проблем и обновлений работает).
Для определенности решил погонять файлы туда-сюда под линуксом, загрузившись с флэшки. Если глюк воспроизведется — значит, проблема все-таки аппаратная. Ну и — просто для очистки совести — решил сначала запустить memtest86+, который на той же флэшке.
И таки да! Уже через пару минут вылезла ошибка (одиночная, маска 40000000 — т.е. сбоит как раз тот самый бит). Еще через минут 40, уже на другом тесте, вылезла опять ровно та же ошибка (сразу много раз подряд). То есть сбоит ровно один бит на всю планку, причем не каждый раз.
В этой истории меня больше всего напрягает то, что майкрософтовское «средство проверки памяти» работало дольше (несколько часов в самом тщательном режиме), а нашло ровно ничего.
Собственно, у меня тоже была отчасти похожая ситуация. Что-то вроде «в каждом четырёхбайтном (или восьмибайтном?) слове обнулилось по маске 0x0000ff00». Хотя, конечно, и близко не столь коварная, как в приведённой истории.
Кстати, пока ковырялся в коде, наткнулся на такие строчки (ссылку даю на свой "форк", потому что сам исходники качал с официального сайта вообще в архиве):
/* Now setup the test parameters based on the current test number */
if (v->pass == 0) {
/* Reduce iterations for first pass */
c_iter = tseq[test].iter/FIRST_DIVISER;
} else {
c_iter = tseq[test].iter;
}«Продвинутые пользователи мемтеста» об этом, наверное, и так прекрасно знали, а вот я лишь догадывался (что-то он как-то быстро, а потом как-то не очень).
Мне в этой истории кажется обиднее то, что корректность скопированных файлов не проверяется на лету (насколько это вообще возможно). Хуже тихой порчи данных ничего нет.
Кстати, 4 года назад на старой машине тоже оказался битый бит, который, падла, всегда отдавался системой Firefox'у. Грешил несколько недель на то, что это Бета-релиз падает :) Для смелых, у Windows тоже есть механизм пометить память нерабочей:
"bcd /set {badmemory} badmemorylist" — надо посмотреть, но ЕМНИП там не укороченные адреса 4КБ страниц, а полные используются (с выровненной позиции). Так компьютер у меня год и проработал, без нареканий. Хотел статейку-ликбез написать, но так и не дошел.
Кстати, иногда Memtest86+ при включенной многопоточной проверке зависает через 4-5 минут, причем при тестировании на одном ядре этого не происходит.
А плата с DDR2 у вас типа такая?
Вроде, она и есть. Могу посмотреть в списке заказов точную ссылку, но, если ничего не напутал в первой статье, то ссылка такая: https://ru.aliexpress.com/item/1892377255.html (надеюсь, это не считается рекламой)
было как то, синий экран иногда, изредка. MemTest86+ и прочие тесты не показывали ничего.
еще бывало создание большого архива винраром и последующая проверка его целостности показывала ошибки.
вынул одну планку, архивы стали делаться без ошибок.
воткнул обратно, вынул другую, опять ошибки.
на MemTest86+ надейся, но и сам не зевай.
он выявит только если совсем крякнулась память.
С другой стороны, если оставить его гонять тесты несколько часов подряд — он неплохо находит даже редко встречающиеся ошибки.
Собрать-то собрал: https://gist.github.com/atrosinenko/f61a4865f35e4702ae3a1f8a49aee71e
Вот с проверкой работоспособности — сложнее. Если что, собирал вот так:
$ apt-src install memtest86+
$ cp memtest86+
$ patch -p1 --ignore-whitespace < ../memtest.patch
$ dpkg-buildpackage --build=binary
$ cp debian/memtest86+/boot/* ..То есть, этот MemTest включает в себя патчи из текущей Ubuntu.
Уточните, пожалуйста, откуда взят оригинал: с memtest.org, из дистрибутива или откуда-то ещё. Просто логично было бы накладывать этот патч именно поверх имеющихся в работающей версии.
Ваш собирал так:
ddrelease64.exe if=/dev/zero of=mfloppy.img bs=1024 count=1440
ddrelease64.exe if=memtest86+.bin of=mfloppy.img seek=0 conv=notrunc
и запускал с загрузочной флешки с GRUB4DOS
А оригинальный MemTest у меня вообще не собрался — жалуется на тучу отсутствующих символов. По поводу зависаний — я попробовал запустить в QEMU, и он тоже иногда подвисает изрядно (а иногда — намертво).
Зато я понял, что не компилирующийся с аналогичными ошибками мой порт с ARCH=i386 — это не я сломал, а "оно само". Более того, в итоге у меня есть буквально штук пять дебиановских патчей, один из которых всё чинит, и нужно просто понять, как. Так что спасибо за вопрос! :)
На счёт изначальной просьбы: честно скажу, перспектива "удалённой" отладки SMP-кода с соответствующим чтением хитрых спецификаций на x86 меня несколько пугает. :) У меня у самого, как ни решу проверить память, SMP-режим вечно вис, и я его не использовал. Я бы вам посоветовал во-первых, убедиться, что поведение обеих версий воспроизводимо (в том смысле, что различия в поведении — это не просто "шум"). Во-вторых, было бы логично как-нибудь запихнуть в параметры запуска MemTest опцию "btrace". У меня в GRUB 2 это выглядит как "linux16 /boot/memtest86+.bin btrace", а потом "boot".
Оказывается, btrace постоянно требует нажать клавишу, чтобы продолжить, я же был уверен, что у меня ввод по serial-порту принципиально не работал — оказывается, он у меня "принципиально работал", причём независимо от того, есть ли реальный ввод… В общем, btrace может быть не совсем удобен для отладки "отдалённой" ошибки.
А, и ещё: у MemTest есть немало параметров командной строки, в частности, один из них позволяет задать список тестов, поскольку сделать это при включённом btrace вы вряд ли сможете. Ссылку вновь даю на свой форк, просто потому, что не знаю, где выложена референсная версия в распакованном виде.
1, 7 — Ок
2, 3, 4, 8 — Зависание
5, 6, 10 — Перезагрузка
9, 11 — Не дождался
Более того, у U-Boot, вроде бы, тоже имеется встроенная команда вроде memtest или что-то такое (прямо в загрузчике). Но попробовать всё-таки было интересно. Ну и MemTest, по слухам, и правда "умный", хотя видел упоминания из серии "MemTest нагружает память не так сильно, как хотелось бы (ссылка на статью с более продвинутым алгоритмом), но вот test номер N очень близок" (кстати, возможно именно этот тест был полностью на ассемблере, и я его пока так же полностью и закомментировал). Впрочем, MemTest можно было бы использовать как удобную стандартную оболочку для запуска "вот этого всего" из теоретических статей.
Хабр — торт.
Часть 6: Портирование MemTest86+ на RISC-V