khach 43 19 ноября, 2023 Опубликовано 19 ноября, 2023 · Жалоба А существует ли микросхема супервизора резета, которая бы запустила переконфигурацию ПЛИС по переднему фронту резета, а по заднему собственно событие сброса сформировала? Конечно это можно собрать на логике, но будет некрасиво. И честно говоря, платы, которые не приходят в начальное состояние ( с перезагрузкой ПЛИС) по кнопке резета, немного достали, особенно в серверном корпусе с удаленным администрированием, где передернуть питание целая проблема. А раз в год оно все таки зависает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Raven 11 19 ноября, 2023 Опубликовано 19 ноября, 2023 · Жалоба А перезагружать FPGA по активации Warm Reset вы не пробовали? Это помогло бы продвинуться на шаг в локализации проблемы - если все заработает, значит при Warm Reset без перезагрузки FPGA не все приходит в требуемое начальное состояние в паре RC - FPGA (пока так, осторожно, хотя ставки на FPGA в этой паре как на источник проблем все же выше). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 222 19 ноября, 2023 Опубликовано 19 ноября, 2023 · Жалоба 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 43 19 ноября, 2023 Опубликовано 19 ноября, 2023 · Жалоба 16 минут назад, makc сказал: Есть большой шанс, что ПЛИС не успеет выполнить реконфигурацию, т.к. на некоторых платах длительность PERST# при тёплой перезагрузке бывает около 10-15 мс. Т.е. это в итоге будет выстрел себе в ногу. А это важно? Вроде все равно при старте ядра ОС большинство устройств по новой инициализируют драйвера. Так что короткое время инициализации важно только для устройств с возможностью загрузки с них ОС- накопителей, сетевых. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 222 19 ноября, 2023 Опубликовано 19 ноября, 2023 · Жалоба 13 минут назад, khach сказал: А это важно? Вроде все равно при старте ядра ОС большинство устройств по новой инициализируют драйвера. Так что короткое время инициализации важно только для устройств с возможностью загрузки с них ОС- накопителей, сетевых. Да, на некоторых мат.платах происходит отключение слота, если на момент выхода из ресета в слоте не было нормально работающего устройства. И чтобы снова всё заработало приходится выключать/включать машину. Чем вас не устроили управляемые по сети розетки? Можно без проблем организовать удалённый перезапуск с полным выключением, если в BIOS настроить автовключение при подаче питания. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
RobFPGA 34 20 ноября, 2023 Опубликовано 20 ноября, 2023 · Жалоба 15 hours ago, makc said: Есть большой шанс, что ПЛИС не успеет выполнить реконфигурацию, т.к. на некоторых платах длительность PERST# при тёплой перезагрузке бывает около 10-15 мс. Т.е. это в итоге будет выстрел себе в ногу Вообще то при горячем ресете не должно быть реконфигурации FPGA. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 222 20 ноября, 2023 Опубликовано 20 ноября, 2023 · Жалоба 5 минут назад, RobFPGA сказал: Вообще то при горячем ресете не должно быть реконфигурации FPGA. Я об этом и говорю, только другими словами. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 222 20 ноября, 2023 Опубликовано 20 ноября, 2023 · Жалоба Проверил появление 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). На ещё одной сбоящей плате была непонятно какая прошивка и после перепрошивки актуальной версией всё стало работать корректно, при учёте правильный показателей при обратной прозвонке. 1 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ivanii 3 20 ноября, 2023 Опубликовано 20 ноября, 2023 · Жалоба Странно что с такими повреждениями что то нормально работало. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 222 20 ноября, 2023 Опубликовано 20 ноября, 2023 · Жалоба 17 минут назад, Ivanii сказал: Странно что с такими повреждениями что то нормально работало. Странно - не то слово. Поэтому и не думалось, что в этом может быть проблема. Но тем не менее факт остаётся фактом - причина в этом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flood 13 22 ноября, 2023 Опубликовано 22 ноября, 2023 · Жалоба On 11/20/2023 at 5:04 PM, makc said: Странно - не то слово. Поэтому и не думалось, что в этом может быть проблема. Но тем не менее факт остаётся фактом - причина в этом. Интересный вопрос - как при работе с PC оценивать количество ошибок в PCIe линке? Понятно же, что при таких повреждениях линк еле дышал и должны были сыпаться символьные ошибки и перепосылки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 222 22 ноября, 2023 Опубликовано 22 ноября, 2023 · Жалоба 1 минуту назад, Flood сказал: Интересный вопрос - как при работе с PC оценивать количество ошибок в PCIe линке? Понятно же, что при таких повреждениях линк еле дышал и должны были сыпаться символьные ошибки и перепосылки. Да, должно было быть множество ошибок. Но мне не удалось найти в документации на процессор/хаб возможности их посмотреть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Raven 11 22 ноября, 2023 Опубликовано 22 ноября, 2023 · Жалоба 2 hours ago, makc said: Да, должно было быть множество ошибок. Но мне не удалось найти в документации на процессор/хаб возможности их посмотреть. Но на FPGA стороне тоже должны быть подобные ошибки, а там их посмотреть можно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
makc 222 22 ноября, 2023 Опубликовано 22 ноября, 2023 · Жалоба Только что, Raven сказал: Но на FPGA стороне тоже должны быть подобные ошибки, а там их посмотреть можно. Учитывая, что в моём случае больше всего пострадал передатчик, то эти ошибки увидеть не получится. Со стороны приёмника были события приёма неверного символа и т.п., но всё это происходило в момент поднятия линка после ресета, поэтому на них никто не обратил внимание. А в процессе работы на них не смотрели, т.к. не было причин подозревать в проблемах физику. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Raven 11 22 ноября, 2023 Опубликовано 22 ноября, 2023 · Жалоба 54 minutes ago, makc said: Учитывая, что в моём случае больше всего пострадал передатчик, то эти ошибки увидеть не получится. Со стороны приёмника были события приёма неверного символа и т.п., но всё это происходило в момент поднятия линка после ресета, поэтому на них никто не обратил внимание. А в процессе работы на них не смотрели, т.к. не было причин подозревать в проблемах физику. Но это повод смотреть на такого рода ошибки в будущем, имея в виду возможность дефекта той же категории, что в вашем случае. А случай действительно интересный. Ведь получается, что объективные показатели аномальности дефектной платы все-таки были - в виде повышенного кол-ва ошибок на линке. Просто до них никто не добрался. Хотя метод обратной прозвонки тоже доказал свою полезность (и к нему все равно пришлось бы прибегнуть для вынесения окончательного вердикта). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться