[khach 40]

А существует ли микросхема супервизора резета, которая бы запустила переконфигурацию ПЛИС по переднему фронту резета, а по заднему собственно событие сброса сформировала? Конечно это можно собрать на логике, но будет некрасиво. И честно говоря, платы, которые не приходят в начальное состояние ( с перезагрузкой ПЛИС)  по кнопке резета, немного  достали, особенно в серверном корпусе с удаленным администрированием, где передернуть питание целая проблема. А раз в год оно все таки зависает.

[Raven 11]

А перезагружать FPGA по активации Warm Reset вы не пробовали? Это помогло бы продвинуться на шаг в локализации проблемы - если все заработает, значит при Warm Reset без перезагрузки FPGA не все приходит в требуемое начальное состояние в паре RC - FPGA (пока так, осторожно, хотя ставки на FPGA в этой паре как на источник проблем все же выше).

[makc 213]

33 минуты назад, Raven сказал:

А перезагружать FPGA по активации Warm Reset вы не пробовали?

Пробовал. Никакого эффекта это не даёт, точно также происходит попытка поднять линк (судя по LTSSM) и далее застревает в Disable или где-то ещё.

35 минут назад, Raven сказал:

Это помогло бы продвинуться на шаг в локализации проблемы - если все заработает, значит при Warm Reset без перезагрузки FPGA не все приходит в требуемое начальное состояние в паре RC - FPGA (пока так, осторожно, хотя ставки на FPGA в этой паре как на источник проблем все же выше).

Судя по состоянию LTSSM линк начинает передёргиваться (меняется состояние LTSSM) ещё накануне начала активного уровня на сигнале PERST#, но на хороших платах это завершается состоянием L0, а на проблемной никуда не идёт. Поэтому пока складывается впечатление, что проблема кроется где-то в самом начале работы (при первичном установлении линка) и далее, после перезагрузки (warm reset) она себя проявляет в полный рост. Завтра попробую посравнивать последовательность смены состояний LTSSM при холодном старте на разных платах и может быть это прольёт свет на происходящее. Правда непонятно, что с этим можно будет сделать в случае чего, т.к. никаких настроек у ядра на этот счёт нет, а по-другому повлиять на процесс поднятия линка я возможности не вижу.

54 минуты назад, khach сказал:

А существует ли микросхема супервизора резета, которая бы запустила переконфигурацию ПЛИС по переднему фронту резета, а по заднему собственно событие сброса сформировала? Конечно это можно собрать на логике, но будет некрасиво. И честно говоря, платы, которые не приходят в начальное состояние ( с перезагрузкой ПЛИС)  по кнопке резета, немного  достали, особенно в серверном корпусе с удаленным администрированием, где передернуть питание целая проблема. А раз в год оно все таки зависает.

Есть большой шанс, что ПЛИС не успеет выполнить реконфигурацию, т.к. на некоторых платах длительность PERST# при тёплой перезагрузке бывает около 10-15 мс. Т.е. это в итоге будет выстрел себе в ногу. 😞

[khach 40]

16 минут назад, makc сказал:

Есть большой шанс, что ПЛИС не успеет выполнить реконфигурацию, т.к. на некоторых платах длительность PERST# при тёплой перезагрузке бывает около 10-15 мс. Т.е. это в итоге будет выстрел себе в ногу.

А это важно? Вроде все равно при старте ядра ОС большинство устройств по новой инициализируют драйвера. Так что короткое время инициализации важно только для устройств  с возможностью загрузки с них ОС- накопителей, сетевых.

[makc 213]

13 минут назад, khach сказал:

А это важно? Вроде все равно при старте ядра ОС большинство устройств по новой инициализируют драйвера. Так что короткое время инициализации важно только для устройств  с возможностью загрузки с них ОС- накопителей, сетевых.

Да, на некоторых мат.платах происходит отключение слота, если на момент выхода из ресета в слоте не было нормально работающего устройства. И чтобы снова всё заработало приходится выключать/включать машину. Чем вас не устроили управляемые по сети розетки? Можно без проблем организовать удалённый перезапуск с полным выключением, если в BIOS настроить автовключение при подаче питания.

[RobFPGA 30]

15 hours ago, makc said:

Есть большой шанс, что ПЛИС не успеет выполнить реконфигурацию, т.к. на некоторых платах длительность PERST# при тёплой перезагрузке бывает около 10-15 мс. Т.е. это в итоге будет выстрел себе в ногу

Вообще то при горячем ресете не должно быть реконфигурации FPGA.  

[makc 213]

5 минут назад, RobFPGA сказал:

Вообще то при горячем ресете не должно быть реконфигурации FPGA.  

Я об этом и говорю, только другими словами.

[makc 213]

Проверил появление DONE относительно фронта PERST# - от появления единицы на DONE до появления единицы на PERST# проходит около 200 мс при холодном старте. При теплой перезагрузке длительность активного уровня PERST# около 8 мс.

Проверил источники и с ними оказалось всё в полном порядке по всем без исключения номиналам.

В итоге решил прозвонить линии PCI-E методом обратной прозвонки (красный щуп мультиметра на земле, чёрным щупаю контакты) в режиме прозвонки диода и здесь начались чудеса.

У исправно работающей платы:

• на MGTREFCLK(P/N) и на MGTPRX(P/N) падение около 0,83 В;
• на MGTPTX(P/N) около 0,42 В.

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

• на MGTREFCLK(P/N) те же 0,83 В, что и у рабочей;
• на MGTPRX(P) падение около 0,43 В, на MGTPRX(N) падение около 0,25 В (явная аномалия);
• на MGTPTX(P) около 0,25 В, а на MGTPTX(P/N) около 0 В.

Итого: всё выглядит так, что на проблемной плате статикой прошило блоки приёма/передачи гигабитного трансивера ПЛИС, но не убило до конца. Когда-то был случай, когда прошило MGTREFCLK и в этом случае линк не поднимался даже при холодном старте (что логично). Здесь же линк работал, но только один раз и похоже после ресета приёмнику на мат.плате становилось совсем грустно и он отказывался видеть передаваемые платой TS1/TS2, т.к. LTSSM из Polling.Active уходит в Polling.Compliance. Удивляет только то, что после теплой перезагрузки на короткий миг там всё-таки проскакивает состояние L0, но из него уходит в Recovery из которого уже не возвращается (переходит в Disabled).

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

[Ivanii 2]

Странно что с такими повреждениями что то нормально работало.

[makc 213]

17 минут назад, Ivanii сказал:

Странно что с такими повреждениями что то нормально работало.

Странно - не то слово. Поэтому и не думалось, что в этом может быть проблема. Но тем не менее факт остаётся фактом - причина в этом.

[Flood 13]

On 11/20/2023 at 5:04 PM, makc said:

Странно - не то слово. Поэтому и не думалось, что в этом может быть проблема. Но тем не менее факт остаётся фактом - причина в этом.

Интересный вопрос - как при работе с PC оценивать количество ошибок в PCIe линке? Понятно же, что при таких повреждениях линк еле дышал и должны были сыпаться символьные ошибки и перепосылки.

[makc 213]

1 минуту назад, Flood сказал:

Интересный вопрос - как при работе с PC оценивать количество ошибок в PCIe линке? Понятно же, что при таких повреждениях линк еле дышал и должны были сыпаться символьные ошибки и перепосылки.

Да, должно было быть множество ошибок. Но мне не удалось найти в документации на процессор/хаб возможности их посмотреть.

[Raven 11]

2 hours ago, makc said:

Да, должно было быть множество ошибок. Но мне не удалось найти в документации на процессор/хаб возможности их посмотреть.

Но на FPGA стороне тоже должны быть подобные ошибки, а там их посмотреть можно.

[makc 213]

Только что, Raven сказал:

Но на FPGA стороне тоже должны быть подобные ошибки, а там их посмотреть можно.

Учитывая, что в моём случае больше всего пострадал передатчик, то эти ошибки увидеть не получится. Со стороны приёмника были события приёма неверного символа и т.п., но всё это происходило в момент поднятия линка после ресета, поэтому на них никто не обратил внимание. А в процессе работы на них не смотрели, т.к. не было причин подозревать в проблемах физику.

[Raven 11]

54 minutes ago, makc said:

Учитывая, что в моём случае больше всего пострадал передатчик, то эти ошибки увидеть не получится. Со стороны приёмника были события приёма неверного символа и т.п., но всё это происходило в момент поднятия линка после ресета, поэтому на них никто не обратил внимание. А в процессе работы на них не смотрели, т.к. не было причин подозревать в проблемах физику.

Но это повод смотреть на такого рода ошибки в будущем, имея в виду возможность дефекта той же категории, что в вашем случае. А случай действительно интересный. Ведь получается, что объективные показатели аномальности дефектной платы все-таки были - в виде повышенного кол-ва ошибок на линке. Просто до них никто не добрался. Хотя метод обратной прозвонки тоже доказал свою полезность (и к нему все равно пришлось бы прибегнуть для вынесения окончательного вердикта).