Гигабитный Ethernet на отладочной плате ML402 (Marvell 88E1111 + Virtex-4)., В режиме 1Gbs время от времени пропадает передача. Опции

[bms]

На отладочной плате ML-402 собрал проект гигабитного эзернета. На борту этой платы есть Virtex-4 (на нем собрал кору MAC-а и её обвязку) и микросхема физического уровня фирмы Marvell 88E1111. Все в принципе работает, но время от времени передача данных с ML-402 в комп отваливается, причем под подозрением микросхема физического уровня, т.к. ПЛИС шлет в PHY нормальные пакеты (смотрел ChipScop-ом).
Эффект проявляется следующим образом.
Идет нормальная работа, пакеты отправляются с ML-402 и нормально принимаются компом. Это длится довольно долго, затем программа wireshark показывает, что входящих пакетов нет.
Лампочки на ML-402 показывают, что все в порядке, передача идет, скорость в порядке, если есть входящие пакеты – моргает соответствующая лампочка “RX”. Но реально в комп ничего не идет, точнее может что-то и идёт, но например битое. И сетевуха это дело отбрасывает. Через несколько десятков секунд такой "работы" микросхема физического уровня сама сбрасывается (о чем говорит характерное гашение/зажигание контрольных светодиодов) и нормальная передача восстанавливается.
Что особенно интересно. Если в момент аварии попытаться вручную сбросить PHY – это не помогает. Хотя по всем признакам сброс происходит (опять же характерное помаргивание светодиодами).
Аварийная работа случается раз в 15-30 минут и только в режиме 1000BASE-T, в режиме 100BASE-T все работает без проблем.

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

Кто-нибудь сталкивался с подобным эффектом?

Сейчас думаю – может сетевуха компа по каким-то причинам не выдерживает длительную эксплуатацию в гигабитном режиме… хотя это конечно маловероятно. Тем более что поток данных который в неё сыпется совсем не плотный всего около 5Мбит/с. Но с другой стороны ручной сброс PHY работу не восстанавливает - значит есть вероятность, что проблема не в PHY, а на другом конце...

Буду благодарен любым идеям.

[Sujan]

есть Virtex-4 (на нем собрал кору MAC-а и её обвязку) и микросхема физического уровня фирмы Marvell 88E1111.
Буду благодарен любым идеям.

Насколько я знаю гигабитная кора у xilinxа платная и по этому в тестовых проектах она работает какое то ограниченное время (вроде минут 10).
Но тогда возникает вопрос: почему после некоторого простоя она опять начинает работать?

[Dimonira]

Насколько я знаю гигабитная кора у xilinxа платная и по этому в тестовых проектах она работает какое то ограниченное время (вроде минут 10).
Но тогда возникает вопрос: почему после некоторого простоя она опять начинает работать?

А почему бы и нет? Достаточно гадить лишь иногда, чтобы уже отбить желание пользоваться
Тем более, что восстановление работы происходит после сброса, что объясняет причину восстановления.

Угу. Кора плтаная и её специфика мне известна. Но дело в том, что мне попался как раз оплаченный вариант Так что с этим все в порядке.

Вы так уверены? Судя по поведению очень похоже именно на эту причину. Даже если за кору оплачено, надо же ещё чтобы "информация" об оплате дошла до корки

Ещё как вариант предлагаю последить за автонегоциацией. Не слетает ли она?

Вообще тема для меня актуальна, т.к. буду применять 88Е1111.
Так что сообщите результаты, плз.

[bms]

Вы так уверены? Судя по поведению очень похоже именно на эту причину. Даже если за кору оплачено, надо же ещё чтобы "информация" об оплате дошла до корки

Я тут уже писал выше, что работоспособность коры я проверял отдельно. Она рабочая. Кроме того, как я уже говорил, симптомы были такие, что PHY сбрасывается - кора НЕ УМЕЕТ СБРАСЫВАТЬ PHY. Значит её сбрасывает кто-то другой, а сделать это может только комп - заново запустив процесс автонегоциации.

В итоге все оказалось намного проще чем я думал.
Для начала я взял еще одну плату ML402 и организовал на ней ловлю "плохих" пакетов. Т.е. гонял данные с платы на плату (без участия компа). За день проверки не было НИ ОДНОЙ сбойной посылки.

Вывод следовал сам собой. Был взят ДРУГОЙ комп с гигабитной картой. И на нем обмен происходил без сбоев. Так что моя первоначальная гипотеза о "плохой сетевухе" подтвердилась. Попробовал обновить драйвера и что интересно процент сбоев даже несколько вырос .
Версия у меня такая - сетевуха явно гнилая. Видимо в процессе работы у нее что-то там слетает, она вдруг все полноценные пакеты начинает считать битыми, либо просто зависает и через какое-то время сбрасывается/либо её сбрасывает ОС.
Это как раз и объясняет, почему ни выключение питания, ни полный сброс ML-402 не восстанавливал работу - плата-то работала нормально, а вот получатель время от времени впадал в транс. И пока он сам себя за уши не вытаскивал - пакеты стучались в мертвого клиента.

Такие дела.

[D Mike]

...
Версия у меня такая - сетевуха явно гнилая. Видимо в процессе работы у нее что-то там слетает, она вдруг все полноценные пакеты начинает считать битыми, либо просто зависает и через какое-то время сбрасывается/либо её сбрасывает ОС.
...
Такие дела.

напиши пожалуйста тип трансивера на твоей "битой сетевухе" хочу проверить совместимость так как у National DP83865 были проблемы совместимости с некоторыми производителями.

[bms]

напиши пожалуйста тип трансивера на твоей "битой сетевухе" хочу проверить совместимость так как у National DP83865 были проблемы совместимости с некоторыми производителями.

трансивер такой: PC82573V (Intel)

[Victor®]

трансивер такой: PC82573V (Intel)

Хм... Ничего плохого не могу сказать про Intel, но как раз есть
4 платы в формате PCI/104-Express на этом чипе.
С одной платой неприятные проблемы...
Под Виндой работает, под Линуксом нет, точнее может заработать,
если подождать какое-то время, включить выключить... вообщем - танцы с бубном.

Хм... Ничего плохого не могу сказать про Intel, но как раз есть
4 платы в формате PCI/104-Express на этом чипе.
С одной платой неприятные проблемы...
Под Виндой работает, под Линуксом нет, точнее может заработать,
если подождать какое-то время, включить выключить... вообщем - танцы с бубном.

P.S.
Пардон, чип несколько другой - PC82537L, но по-моему чипы отличаются очень незначительно.
По предварительным данным - потреблением.