Большое спасибо!
Отвечаю поздно, т.к. ремонт затянулся на несколько месяцев из-за множественных физических повреждений и долгого поиска реально рабочей замены на gddr5 H5GQ8H24MJR R4C (китайцы прислали нерабочие модули, пришлось искать донора с мёртвым чипом).
После вашего ответа нашёл datasheet на элемент, в обвязке которого стоят эти резисторы.
Это clock generator - по всей видимости аналог Si51214, и 20-Омный R75 там выполняет роль "Series Termination Resistor".
20-омный у себя не нашёл, пришлось ставить 15-Омный. Опасался что не заработает, т.к. "Series Termination Resistor" отвечает за "шумоподавление" отражённых высокочастотоных колебаний, но по факту 15-Омный тоже заработал.
На этом про мою видеокарту всё.
В качестве благодарности хочу поделиться следующей информацией, интерес к которой вы проявляли на официальном youtube-канале.
Во-первых про "поиск неисправной микросхемы видео-памяти при помощи linux-утилит".
Уже несколько лет успешно это делаю для amd rx580/nvidia 10x0 без каких-либо секретных утилит, идея следующая:
Если после включения компьютера никаких нетривиальных команд на gpu не отправлять, то на некоторый диапазон физической памяти, соответствующий наибольшему PCIe BAR видеокарты, отображён довольно большой кусок видеопамяти, как минимум 64 МБ.
А значит выполняя операции чтения/записи со стороны CPU можно посчитать количество сбойных байт в этом диапазоне (хотя на более новых картах иногда ещё необходима хотя бы попытка инициализации драйвера).
Для проверки создан небольшой тривиальный скрипт на python3, проводящий такой тест видеопамяти -
https://raw.githubusercontent.com/galki … em-test.py
Скрипт для linux x64, потому что там проще всего работать с физической памятью из скрипта.
Обычно достаточно запустить как
python3 ./direct-mem-test.py b000000 8
для тестирования 8 МБ видеопамяти которая смаплена начиная с адреса b000000 (адрес можно посмотреть в выводе lspci -v)
Иногда требует микро-допиливаний под конкретные адреса и размеры памяти.
Скрипт посчитает количество сбойных байт и их долю среди всего протестированного объёма (не только, но остальное расписывать как минимум долго).
Возникает естественный вопрос как от этого перейти к тому, какой именно из модулей даёт эти ошибки, не зная соответствия между адресами и модулями.
Вот как: было замечено, что если во время работы активно потыкать земляным проводом через малоомное сопротивление на резисторы RESET или ZQ-контактов gddr5 - соответствующий модуль gddr5 начинает не работать целиком до следующей перезагрузки системы. После перезагрузки работает нормально, хотя теоретически так можно много что пожечь.
При этом в выводе программы количество ошибочных байт относительно общего возрастает в точности на ту долю которую составлял "вырубаемый" модуль среди всех.
Складывая вместе эти 2 факта получается следующая методика: если после "вырубания" модуля количество ошибок в программе возрастает на долю модуля целиком - значит он виноват. Если же на меньшее значение - вырубленный модуль уже содержал ошибки до его "вырубания".
При достаточном опыте - 15 минут на всё про всё.
Во-вторых про "что за ШИМ контроллер с маркировкой 08= был на видео с ремонтом 1060". https://www.youtube.com/watch?v=8VVQ4u-ASo8
Это Richtek RT7296F с маркировкой 08=??? https://www.richtek.com/assets/product_ … 96F-00.pdf
Корпус TSOT23-8
Насколько я понимаю, полный аналог MP1475 с маркировкой ADPG.
