Ciber SLasH писал(а):
1) что я делаю не так, раз скрипт выводит ошибки на рабочем ноутбуке
К сожалению это сложный вопрос. Более того с ноубуками с дискреткой я даже пользовательского опыта не имел, поэтому гадать не буду, а опишу ситуацию на десктопных видеокартах.
Для корректной работы теста - необходимо:
- чтоб *попытка* инициализации видеокарты уже была выполнена ранее. Попытка должна дойти до инициализации памяти. Что будет дальше после того как память инициализируется - не очень важно. В случае проблемной памяти будет какая-то ошибка, но память останется инициализированной.
Скорее всего у вас этого не произошло - (предположу что POST на ноутах не инициализирует карту, так что надо инициализироваь через драйвер - см ниже.) - чтоб драйвер не занимался активным использованием карты. (то есть не было активных вычислений или рендеринга). При нерабочей памяти этот как правило не проблема, т.к. инициализация драйвера как правило не удаётся.
Если драйвер всё же поставился, создал "устройство" /dev/fb0 и переключил карту в режим графического фреймбуфера - то при проблемах памяти в этом фреймбуфере будут визуальные полосы/точки. Для определения их адресов можно использовать тот же скрипт, но тестировать не системную память, а область видимую на экране. Команда такая (8 - количество мегабайт):
MEM=fb0 ./direct-mem-test.py 0 8
Тут много нюансов, например максимальный объём зависит от разрешения и мигуающий курсор вносит ложные ошибки. Зато тест наглядно видно)
Теперь про инициализацию - то что более актуально по конкретно вашей ситуации:
Инициализировать память карту можно несколькими способами:
- на этапе POST на основе кода VideoBIOS (материнки с BIOS инициализируют так только первую карту, с UEFI - вроде бы все карты). Если карта нерабочая есть риск зависания. Если зависания не случилось и загрузка прошла дальше - память инициализировалась, можно тестировать. Если зависло - то вставлять второй картой, и пробовать другие варианты (я думаю что на ноуте инициализация не прошла. Может быть можно включить какой-то параметр в BIOS, чтоб дискретка была включена сразу).
- при помощи установки драйвера.
Вначале выгружаем все загруженные ранее драйвера, если такие вдруг есть:
rmmod nvidia_uvm
rmmod nvidia_drm
rmmod nvidia_modeset
rmmod nvidia
rmmod nouveau
rmmod amdgpu
(может и в одну команду можно, но не уверен, сейчас не могу проверить)
Для nvidia это
modprobe nouveau modeset=1
илиmodprobe nouveau config=NvForcePost=1 modeset=1 nofbaccel=1 runpm=0 noaccel=1
На рабочих картах подойдёт и тот и другой. А на не рабочих - что один, что другой могут завесить систему.
Для того чтоб nouveau инициализировал карту - нужны файлы динамически загружаемых firmware в подпапках внутри /lib/firmware/nvidia/gp102/
SystemRescueCD - крайне специализированный дистрибутив, в нём этой папки может и не быть.
Если это роняет систему (на карте с проблемами) - то можно попробовать 2-3 раза, бывает что везёт.
Другой вариант - доставить из репозитория дистрибутива пакет с официальным драйвером nvidia (зависит от дистрибутива, на SystemRescueCD я думаю это невозможно), и попробовать инициализирвоат с его помощью:
modprobe nvidia #драйвер загружается в память, но ничего не инициализирует
nvidia-smi #реальная инициализация после первого запроса от приложения
Он тоже на проблемных картах вешает систему, субъективно чаще nouveau - предполагаю что можно как-то через mods-367, но это открытый и для меня вопрос
По моей статистике среди карт с проблемами памяти треть карт проходят post без зависаний, ещё треть инициализируются через драйвера с 2-3 попытки, а оставшаяся треть виснет что не делай(
Только после такой инициализации скрипт сможет обащаться к видеопамяти.
Ciber SLasH писал(а):
И ещё в конце какие-то ошибки в коде самого скрипта...
Это не ошибки, это "авариайное завершение" после того как найдена ошибка видеопамяти. Короче, не обращать внимания, криво, но поведение ожидаемое.
Ciber SLasH писал(а):
3) как правильно выбирать адрес памяти (в выводе их 3 шт.)
В выводе "lspci -v | less" нашёл NVIDIA и адреса памяти: f6000000 (32-bit, non prefetchable) [size=16M], e0000000 (64-bit, prefetchable) [size=256M], f0000000 (64-bit, prefetchable) [size=32M].
Какой адрес выбирать?
Выбирать самый большой диапазон - size=256M - адрес выбрали правильно.
Ciber SLasH писал(а):
2) возможно ли сделать вывод процентов работы скрипта (не понятно, работает скрипт или всё повисло). Хотя бы просто писать в консоль: 10% 20% ... 100%
4) как-то выбрал объём видеопамяти 2048 (2Gb) и скрипт ругнулся на число
Скрипт примитивный - тестит только то что *УЖЕ* замаплено на системную память. Обычно это 64-512МБ - это как раз число из lspci. В процессе реальной работы драйвера переключают на какую область памяти это мапится или как-то ещё обращаются к видеопамяти и т.п. Таким образом *всю* видеопамять память так проверить нельзя. По факту скриптом имеет смысл проверять 8-16МБ, если они исправны - то драйвер поставится и актуальны будут другие тесты. Ситуация что "первые адреса в чипе памяти работают", а "дальнейшие не работают" и при большом использовании видеопамяти будут проблемы - теоретически возможна, но частой уж точно не является - в своей практике ни разу не встретился. Вывод отсюда такой - больше чем 16МБ при отсуствтвии ошибок тстировать смысла нет. 16МБ тестируются сравнительно быстро.
Вообще скрипт работает ощутимое время не потому что делает много работы, а просто потому что не особо оптимально написан - там 80% времени занимает подсчёт битов ошибок, а не работа с памятью. Так что добавлять вывод прогресса смысла не вижу, актуальней чуть ускорить, но при <= 16МБ и в этом мало смысла на мой взгляд. Должен за 0.5-2 минуты укладываться.
Для теста бОльшего/всего объёма памяти + одновременно с тестом на коректность и стабильность - использую
https://github.com/ihaque/memtestCL (требует наличие успешно инициализировавшегося драйвера).
Пункт меню из grub4dos такой (взят из "systemrescuecd-x86-5.3.1.iso\boot\grub\grub-531.cfg"):
