Сетевой интерфейс не работает в условиях интенсивного трафика
Мы исследуем проблему с нашим комплектом, который представляет собой IP-камеру под управлением Busybox Linux на SoC Ti-Davinci .
На одном конкретном сайте существует большой сетевой трафик (которым мы не можем управлять), и одна система рассылает широковещательные пакеты (на 255.255.255.255 ) каждые ~ 50 мс без перерыва. Он не отправляет много данных, но он очень постоянный.
Это оказывает странное влияние на нашу систему - если система запускается, перезапускается или сеть снова запускается ( ifdown ... ifup и т. Д. .) пока этот трафик присутствует, сетевой интерфейс не работает должным образом. Он утверждает, что работает вверх , но просто сидит там, регистрируя тысячи ошибок переполнения Rx / фреймов. Мы не получаем ничего успешно адресованного нам (PING и т. Д.), И ничего не можем отправить, PING терпят неудачу, как будто они пропали без вести (они отображаются как успешно переданные, но никогда не покидают нас), а не активно отклоняются / упал. Сетевой драйвер, кажется, считает, что он включен и работает нормально, но ничего не входит и не выходит.
Если мы удалим трафик и запустим / перезапустим / зациклили сеть, интерфейс появится и будет работать отлично - если мы затем снова представьте трафик, тогда мы НЕ увидим нарастания переполнения / ошибок кадров.
Поскольку мы являемся небольшой встроенной системой, работающей под управлением Busybox, в нашем распоряжении нет ни мощности, ни полного набора сетевых инструментов для некоторых из наиболее сложных предложений, найденных во время поиска (увеличение буферов Rx было основным, что я нашел).
Скорее, я ищу предложения по первопричине и / или предложения о том, где начать копаться, чтобы попытаться предотвратить это. Это может быть так же просто, как настройка параметров ядра или перестройка сетевого драйвера - ответы на открытке!
Если требуется дополнительная информация, спросите - это не вызывает никаких ошибок, кроме статистики Rx Overflow / Frame в ifconfig , так что публиковать особо нечего.
Похоже, я нашёл ответ - в EMAC-драйвере ti-davinci произошла ошибка:
Davinci-Linux список рассылки примечания:
Said commit добавляет проверку того, в порядке ли ссылка на несущую. Если ссылка не хорошо, skb освобождается и в rx dma не добавляется новый дескриптор dma Канал. Это вызывает проблемы во время инициализации, когда носитель статус еще не был обновлен. Если много пакетов получено в то время как netif_carrier_ok возвращает false, все дескрипторы dma освобождаются, а также Передача rx dma остановлена.
Чтобы воспроизвести жучок, затопив доску давинчи во время выполнения
ifconfig eth0 down && ifconfig eth0 upна плате.После этого путь rx перестает работать и сообщается о значении превышения. еслиconfig ведет отсчет.
Мы собрали и протестировали это, теперь устройство может выдержать более 2500 пакетов/сек, не оказывая на него никакого негативного воздействия, настолько уверенно, что оно исправлено - раньше для его расстройства требовалось всего около ~50 пакетов/сек.
.