Ethernet отваливается

[_oligarch]

связал ПК с платой AT91SAM9260 по ethernet. Запустил драйвер qnet. Некоторое время плата отвечает нормально и qnet работает. Но иногда qnet отваливается и при этом пропадает пинг. Порой связь восстанавливается сама, но иногда приходится перегружать плату. В чем может быть проблема? Кабель обжат надежно. Пробовал и точка-точкой подсоединяться и через хаб. Проблема остается в обоих случаях.
Спасибо.
 

[mike]

в логах что?

[lestat]

Энергосбережение в самом AT91SAM9260 выключено ? Ещё может быть такое: у нас на AT91RM9200 было переполнение TX буфера, т.к. процессор медленный и не успевает отправлять данные. Посмотри на плате вывод ifconfig, и посмотри были ли Tx underrun или Rx overrun.

[mike]

тогда уж nicinfo, там инфы поболе будет

[Goofy]

_oligarch, какая именно плата?
У меня та что со стартеркита, без NANDа, проблемы абсолютно те же.
Qnet не ставил.

Мои наблюдения:
У платы оч сильно греется PHY
Когда идёт пинг в фоновом режиме сетка держится дольше (рекорд 11 суток)
Сетка падает от входящего флуд пинга (вылетает io-net)
Сетка падает от входящего UDP потока (максимальный для 100Мбит) (вылетает io-net)
Сетка падает сама по себе  (перестаёт работать, но ничего не вылетает, запросы типа ping, netstat блокируются наглухо)

Проблемы сопровождаются в sloginfo следующим

Код:

Jan 04 08:44:42    5    10     0 devn-at91sam: link up (100 BaseT Full Duplex)
Jan 04 09:35:21    5    10     0 devn-at91sam: link up (100 BaseT Full Duplex)
Jan 04 09:36:54    5    10     0 devn-at91sam: callback GetActiveMedia returned
3
Jan 04 09:36:54    5    10     0 devn-at91sam: link up (Unknown)
Jan 04 09:36:57    5    10     0 devn-at91sam: link up (100 BaseT Full Duplex)
Jan 04 10:50:21    5    10     0 devn-at91sam: Attempt to recover from underrun!
Jan 04 15:46:03    5    10     0 devn-at91sam: Attempt to recover from underrun!
Jan 04 19:28:18    5    10     0 devn-at91sam: Attempt to recover from underrun!
Jan 04 19:35:47    5    10     0 devn-at91sam: Attempt to recover from underrun!
Jan 04 19:43:12    5    10     0 devn-at91sam: Attempt to recover from underrun!
Jan 04 19:44:22    5    10     0 devn-at91sam: Attempt to recover from underrun!
Jan 04 22:36:16    5    10     0 devn-at91sam: Attempt to recover from underrun!
Jan 05 01:01:54    5    10     0 devn-at91sam: Attempt to recover from underrun!
Jan 05 03:08:33    5    10     0 devn-at91sam: Attempt to recover from underrun!

Кроме этого при запуске драйвера далеко не с первого раза система находит доступный на RMII шине PHY, терпетиво перезапуская, удачно бутимся...

Обновление статуса подключение (10 - 100 мб, дуплекс \ полудуплекс ) в драйвере происходит по таймеру. Похорошему должно быть по прерыванию. Сеть начинает особенно стабильно дурковать, когда в логе идут подобного рода перестановки статуса:

Jan 04 08:44:42    5    10     0 devn-at91sam: link up (100 BaseT Full Duplex)
Jan 04 09:35:21    5    10     0 devn-at91sam: link up (100 BaseT Full Duplex)
Jan 04 09:36:54    5    10     0 devn-at91sam: callback GetActiveMedia returned 3
Jan 04 09:36:54    5    10     0 devn-at91sam: link up (Unknown)
Jan 04 09:36:57    5    10     0 devn-at91sam: link up (100 BaseT Full Duplex)

Возню с этим драйвером все ещё откладываю до переезда платформы на другой PHY, там уже начну вплотную разбираться

[rw9uao]

осенью выложу все сырцы. ковыряйте на здоровье. похоже на переполнение буффера. как лечить - х.з.
про RMII - указывайте явно при загрузке. ФИ греется в пределах нормы.
про то что отключен авто-негатиатион - ну да, на таймере. на прерывании работает монопенисуально. желательно то же указывать жестко в билд файле.

[Goofy]

RMII и так указан явно в строке запуска io-net. Просто при переборе адресов PHY он ничего не находит, утверждаю это потому что работаю с иходниками. М\б с таймингами беда, но факт наличия отсутствия отклика от ФИ при запуске - событие вообще бессистемное...

[_oligarch]

Плата у меня ST-AT91SAM9260 от Starterkit. Вот что выдает sloginfo при крэше:

//-------------------------------------------------------------------------
Time             Sev Major Minor Args
Jan 01 00:10:09    7    15     0 npm-qnet(QOS): tx_conn_idle_l4(): tc_up_max_retries of 6 exceeded, deleting iface for L4 0 for nd 11 conn 2

Jan 01 00:10:09    7    15     0 npm-qnet(QOS): tx_ndb_del_if(): deleting mapping for L4 0 for nd 11

Jan 01 00:10:09    7    15     0 npm-qnet(QOS): tx_ndb_del_if(): no more interfaces, tearing down nd 11

Jan 01 00:10:09    7    15     0 npm-qnet(QOS): nd_change_notify(): Node Down: nd 11 Kovalenko_q632.

Jan 01 00:10:38    7    15     0 npm-qnet(L4): lr_add_ndb(): adding L4 0 addr to ndb for nd 16  Kovalenko_q632.

Jan 01 00:10:38    7    15     0 npm-qnet(QOS): nd_change_notify(): Node Up:   nd 16 Kovalenko_q632.

Jan 01 00:11:57    7    15     0 npm-qnet(QOS): tx_xmit_init_conn_pkt(): to nd 16 on L4 0

Jan 01 00:11:57    7    15     0 npm-qnet(QOS): tx_xmit_init_conn_pkt(): to nd 16 on L4 0 retry 1

Jan 01 00:11:58    7    15     0 npm-qnet(QOS): tx_xmit_init_conn_pkt(): to nd 16 on L4 0 retry 2

Jan 01 00:11:58    7    15     0 npm-qnet(QOS): tx_xmit_init_conn_pkt(): no more L4s to try for nd 16

Jan 01 00:11:58    7    15     0 npm-qnet(QOS): tx_complete(): callback for nd 16 to layer 0 with errno 264

Jan 01 00:11:58    7    15     0 npm-qnet(kif): kif_server_outbound_failed(): NTONET_CONNECT server busy 119178

Jan 01 00:11:58    7    15     0 npm-qnet(QOS): nd_change_notify(): Node Down: nd 16 Kovalenko_q632.

Jan 01 00:12:04    7    15     0 npm-qnet(L4): lr_resolve(): starting for nd 17  Kovalenko_q632.net.intra

Jan 01 00:12:04    7    15     0 npm-qnet(L4): l4_resolve_periodic_en_ionet(): timeout: re-tx 1 looking for nd 17  Kovalenko_q632.net.intra

Jan 01 00:12:04    7    15     0 npm-qnet(L4): l4_resolve_periodic_en_ionet(): timeout: re-tx 2 looking for nd 17  Kovalenko_q632.net.intra

Jan 01 00:12:04    7    15     0 npm-qnet(L4): l4_resolve_periodic_en_ionet(): 2 retries exceeded for nd 17  Kovalenko_q632.net.intra  found 0 interfaces
//-------------------------------------------------------------------------

ifconfig выдает следующее:
//-------------------------------------------------------------------------
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33212
   capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
   enabled=0<>
   inet 127.0.0.1 netmask 0xff000000
en0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
   address: 00:1f:fb:00:00:00
   inet 10.10.1.78 netmask 0xffffff00 broadcast 10.10.1.255
//-------------------------------------------------------------------------


nicinfo выдает следующее:
//-------------------------------------------------------------------------
ATMEL AT91 EMAC Ethernet Controller

  Physical Node ID ........................... 001FF2 000000
  Current Physical Node ID ................... 001FFB 000000
  Current Operation Rate ..................... 0 kb/s half-duplex
  Active Interface Type ...................... MII
    Active PHY address ....................... 1
  Maximum Transmittable data Unit ............ 1514
  Maximum Receivable data Unit ............... 1514
  Hardware Interrupt ......................... 0x15
  I/O Aperture ............................... 0xfffc4000
  Promiscuous Mode ........................... Off
  Multicast Support .......................... Enabled

  Packets Transmitted OK ..................... 1135
  Bytes Transmitted OK ....................... 121435
  Broadcast Packets Transmitted OK ........... 80
  Multicast Packets Transmitted OK ........... 0
  Memory Allocation Failures on Transmit ..... 0

  Packets Received OK ........................ 1055
  Bytes Received OK .......................... 135106
  Broadcast Packets Received OK .............. 13
  Multicast Packets Received OK .............. 0
  Memory Allocation Failures on Receive ...... 0

  Single Collisions on Transmit .............. 0
  Multiple Collisions on Transmit ............ 0
  Deferred Transmits ......................... 0
  Late Collision on Transmit errors .......... 0
  Transmits aborted (excessive collisions) ... 0
  Transmit Underruns ......................... 0
  No Carrier on Transmit ..................... 0
  Receive Alignment errors ................... 0
  Received packets with CRC errors ........... 0
  Packets Dropped on receive ................. 0
  Short packets .............................. 0
  Total Frames experiencing Collison(s) ...... 0
//-------------------------------------------------------------------------

Изза чего пишется вот это: Current Operation Rate ..................... 0 kb/s half-duplex?

[_oligarch]

Active Interface Type ...................... MII ?
должен быть режим RMII

[Goofy]

Не обращайте внимание, это не принципиально в данном случае
Выставте принудительно 100мб\с и полный дуплекс при запуске драйвера, как посоветовал rw9uao.
У меня всё стало пахать постабильнее

[_oligarch]

при запуске драйвера задал:
io-net -d at91emac mac=001ffb000000,speed=100,duplex=1,rmii -ptcpip -pqnet -v &

и не помагает. Через минуту qnet уже слетает

[Goofy]

Ага, эт я рано обрадовался...
Будем разбираться

[AG]

Аналогичный эффект на QNX 6.3.2 на платформе PXA250 с сетевой картой LAN91C111i (devn-smc9000).
/sbin/io-net -vvvvvvv -dsmc9000 ioport=0x04000300,speed=10,duplex=1,variant=generic,width=32 -ptcpip

Сеть отваливается через какое-то время работы. Т.е. любая коммуникация через сеть невозможна.

Проблема воспроизводится легко, надо лишь запустить из под линукс пару flood ping со стандартными параметрами "ping -f <QNX-ip>" и один-два flood ping с большими пакетами "ping -f <QNX-ip> -s 65507".

Есть подозрение что это mutex-bug, которую мы нашли ранее в QNX 6.3.2 на платформе ARM (LE).

[AG]

Добавлю еще вот что. Если сеть "умерла", то можно ее "оживить" если перезапустить io-net (с параметрами) и снова сконфигурировать сеть.

Замечено, что в сети бегает много бродкастного трафика, который похоже и убивает TCP/IP или драйвер. Время "жизни" сети варьируется в зависимости от объема оного трафика. Метод с flood ping просто ускоряет процесс во много раз.

Если кто видел что-то подобное на своих системах, дайте знать.

--Ag

[longest]

При включении broadcast траффика на соседней машине, мгновенно умирает сетевой интрефейс на qnx 6.6.0 (core i5). Проверял на devnp-e1000.so и devnp-rtl8169.so.
При этом USB Ethernet dongle на этой же машине в этой же сети остается живой.
С него подключаюсь и делаю
ifconfig wm0 down
ifconfig wm0 up
и если снять траффик гигибитный интерфейс начинает отвечать.
Как с этим бороться?