Смастерил наконец девайс для съёма данных с LPC,

Смастерил наконец девайс для съёма данных с LPC, опробовал его на заведомо исправной материнке - под руками оказалась только плата с FWH. Данные снались корректно (присутствуют поля START, IDSEL итд.) .
А вот при подключении к буку летит мусор в течении ~1мс. Возможно что косяки с подключением (наводки на провода например) Но что если действительно по LPC гонит мусор ? В таком случае очевидны проблемы с питанием ЮМ, ведь должно быть контроллер внутри южника реализован "железно", и структура шины в сигналах по линиям, должна присутствовать всегда - проблемы по питанию, кажется единственный случай когда возможны сбои в служебных полях.
Кто нибудь сталкивался в практике ремонта с подобным случаем, не беря в расчёт рассуждение о мусоре на LPC. Имею ввиду срыв обмена данными по LPC о котором я рассказывал в предыдущем сообщении ?

Уже всю голову сломал об этот бук, начинаю подумывать о поиске новой мат платы.

---------------------
Укоротив провода, идущие от LPC к "прицепу" удалось увидеть картину происходящего, сильно осложняет диагностику факт того что данные передаются блоками по 64 байта (то-есть нельзя узнать точный адрес перехода внутри этого 64 байтного блока, но с некоторой долей уверенности можно сказать что шина CPU-NB исправна upd: шина адреса-данных). Но в отличии от исправной системы, на этой материнке южный мост инициирует ретрейн, вплоть до 10 раз перезапрашивает каждый блок, случалось если в процессе старта ретрейнов происходит не очень много то инициализация доползала до поста D0

перезапросы явление вполне нормальное, так происходит и на десктопной материнке, видимо в чипсете не предусмотрен(не инициализирован) буфер данных для firmware read запросов, и для каждой DMI транзакции блок перечитывается (по количеству циклов можно примерно судить на сколько продвинулось выполнение программы относительно точки перехода) . в моём случае MCH возможно зависал при запросе от CPU на IO операцию - тк прошло всего 3 цикла чтения блока c адреса F000:E140 полагаю что зависание произошло какк реакция на первую попавшуюся команду OUT (запись в configuration space ADDRESS register) адресу F000:E16A, в документации сказано, что MCH генерирует DMI configuration cycle, только после записи IO configuration space DATA register - но кажется (опять таки только предположение) что за три цикла (по LPC) CPU не успевает дойти до второй команды OUT, так что отвал по линии #REQA[4] вполне вероятен. Я решил как следует прогреть MCH (оказалось что его до меня уже грели, под ним начал кипеть флюс) после чего мать стартанула.

в качестве бонуса в прикреплённом архиве дамп LPC во время неисправности (снятый без искажений), и программа для конвертации дампа в образ адресного пространства ( для просмотра в дизассемблере например). У кого возникнет интерес к LPC тестеру - пишите.