Перезагрузка по watchdog при подключении к коммутатору

[san]

Пользователь обнаружил что после подключения платы SW-01 портом Eth1 к коммутатору Huawei S5731 плата перезагружается по ватчдогу. К коммутатору, кроме SW-01, подключен только ПК пользователя. При подключении ПК напрямую к SW-01 проблема не воспроизводится.

Воспроизводится, как минимум на двух платах SW-01 r2382 и r2428
Коммутаторов пользователь перепробовал уже много, в их сети используется одинаковая модель , но в нескольких модификациях. С Huawei S5731-S48P4X и S5731-H48T4XC плата SW-01 перезагружается, а с Huawei S5731-S48T4X проблема не воспроизводится.
Пользователь записал два дампа, при подключении SW-01 к разным модификациям свитча:
work.pcapng - проблема не воспроизводится
problem.pcapng - проблема воспроизводится
Описание дампа problem.pcapng от пользователя:

Захват трафика в обе стороны - уходящего от свитча Huawei в сторону платы SW01 и входящего с платы SW01 к свитчу Huawei.
Со свитча Huawei поставил пинг на SW-01 192.168.0.254.

MAC-адрес Huawei - a8 50 81 9a e7 22 на L3 интерфейсе и a8 50 81 9a e7 20 на L2 порту.
MAC-адрес SW-01 - 02 ad c2 00 09 0b

До пакета №78 видно, что Huawei отправляет STP, LLDP и пытается по ARP узнать MAC-адрес 192.168.0.254 для отправки ICMP-запроса.

Пакеты №79 - №82 - загрузилась сетевая карта SW-01 и отправляет первые пакеты по ICMPv6

Пакет №85 - SW-01 отвечает на ARP-запрос Huawei.

Пакеты №86 - №359 обмен ICMP и отправка со стороны Huawei служебки STP, LLDP, ARP и броадкаст.   Плюс проскакивает со стороны SW-01 также ARP и IGMP

Пакет №360 SW-01 уходит в перезагрузку и перестает отвечать на ICMP (в дампе остаются только request). С Huawei остаются ICMP-request, STP, LLDP и броадкаст. 

Пакет №412 - загружается сетевая карта SW-01 и все повторяется заново.

[alx]

Провел эксперимент со своей платой, имитировав "падение" swd (я его просто убил). Пакеты от платы пропали (т.е. сработал watchdog) через 16 секунд, а снова появились (после перезагрузки) через 30 секунд.

Если предположить, что в описанном случае перезагрузка тоже вызвана падением swd, то это произошло приблизительно в 18:23:24. В районе этой отметки из "левых" кадров от коммутатора вижу только RSTP BPDU и нечто с типом 0x9998. Но такие кадры передавались регулярно и ранее, и непонятно тогда, почему падение не произошло раньше.

Если же предположить, что перезагрузка вызвана не падением процесса swd, а самим ядром (паникой), то это должно было произойти в момент прекращения ответов - в 18:23:40. В это время (18:23:39.923838) я вижу пару мультикастовых кадров типа 0x88a7, а предыдущий раз они были еще до того как плата загрузилась. Однако аналогичные кадры есть и в дампе "хорошего" коммутатора, но они отличаются (как содержимым, так и размером)...

[san]

Кажется мы научились воспроизводить это у себя.
У Влада есть какая-то утилита, которая умеет "проигрывать" дампы в сеть.
При неторопливом проигрывании дампа пользователя в сторону SW-01, она перезапустилась по ватчдогу.

[san]

Влад проигрывает с 11 по 15-й пакеты из дампа problem.pcapng и проблема воспроизводится

[san]

Похоже проблема в пакете #12

[alx]

Replying to san:

Похоже проблема в пакете номер 12

Думаю, что мой вывод можно считать подтвержденным экспериментально.

[san]

В момент падения в консоль вываливается следующее:

skbuff: skb_over_panic: text:c0198480 len:217 put:3 head:c287ddc0 data:c287ddea tail:0xc287dec3 end:0xc287dec0 dev:eth0
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:127!
Internal error: Oops - BUG: 0 [#1] ARM
Modules linked in: g_serial
CPU: 0 Not tainted (3.6.9 #1)
PC is at skb_put+0x74/0x90
LR is at skb_put+0x74/0x90
pc : [<c01d5740>] lr : [<c01d5740>] psr: 20000013
sp : c2845ed8 ip : 000008d8 fp : 00000000
r10: 00000000 r9 : 0000000d r8 : 000000d6
r7 : 00000186 r6 : c034fcb3 r5 : c287dec0 r4 : c287ddc0
r3 : c03be6b8 r2 : 20000093 r1 : 00000001 r0 : 00000077
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005317f Table: 23bec000 DAC: 00000015
Process swd (pid: 272, stack limit = 0xc2844270)
Stack: (0xc2845ed8 to 0xc2846000)
5ec0: 00000003 c287ddc0
5ee0: c287ddea c287dec3 c287dec0 c3987000 c3878440 c39873a0 00000001 c0198480
5f00: 00000001 00000040 00000040 c39873d0 c39846d8 c39873d0 c03d6360 00000001
5f20: 0000012c 00000040 00400140 c03d6368 fffc891e c01dd73c c01dd6dc 00000001
5f40: c03dbc8c c2844000 00000100 c03dbc80 00400140 0000000a 00000000 c001b8a0
5f60: 00128079 c3805440 00000000 00000003 001ae260 00000025 00000000 ffffffff
5f80: 001ae260 00000000 00000000 001ae2a8 00000242 c001bca4 00000025 c0009c18
5fa0: fefff000 00056f8c 80000010 c00091c4 001af070 00000000 00000000 00000000
5fc0: 001af07f 001af070 001af085 001ae260 00000000 00000000 001ae2a8 00000242
5fe0: ffffffff b613a9d0 000133bc 00056f8c 80000010 ffffffff aa0a2022 a22a0222
[<c01d5740>] (skb_put+0x74/0x90) from [<c0198480>] (macb_poll+0x238/0x3ac)
[<c0198480>] (macb_poll+0x238/0x3ac) from [<c01dd73c>] (net_rx_action+0x60/0x16c)
[<c01dd73c>] (net_rx_action+0x60/0x16c) from [<c001b8a0>] (__do_softirq+0x8c/0x144)
[<c001b8a0>] (__do_softirq+0x8c/0x144) from [<c001bca4>] (irq_exit+0x40/0x4c)
[<c001bca4>] (irq_exit+0x40/0x4c) from [<c0009c18>] (handle_IRQ+0x64/0x84)
[<c0009c18>] (handle_IRQ+0x64/0x84) from [<c00091c4>] (__irq_usr+0x44/0x60)
Code: e59f0020 e58dc00c e58d5010 eb036f22 (e7f001f2)
---[ end trace 9a52d65af3f6ca16 ]---
Kernel panic - not syncing: Fatal exception

[alx]

In 535/openembedded:

Исправлена ошибка в драйвере macb: при приеме некоторых пакетов
skb_put() могла выходить за пределы выделенного буфера, что
приводило к kernel panic и последующей перезагрузке.
Closes #723.