* "hw csum failure" error on skge driver with 4.3 kernel upon receiving ICMPv6 multicast listener discovery packets
@ 2015-11-15 18:44 David Madore
2015-11-15 21:11 ` Stephen Hemminger
2015-12-01 21:07 ` Stefan Ring
0 siblings, 2 replies; 4+ messages in thread
From: David Madore @ 2015-11-15 18:44 UTC (permalink / raw)
To: Linux Kernel mailing-list, Linux network mailing-list
The skge driver in the 4.3 kernel reports hardware checksum errors
upon receiving (certain?) IPv6 multicast packets containing ICMPv6
multicast listener discovery messages. This is a regression since 4.1
(I believe between 4.1 and 4.2). The e1000e driver on a different
Ethernet port of the same machine is not affected. Disabling offload
rx checksumming suppresses the errors. Nor are all IPv6 multicast
packets affected: for some reason, it seems only those containing
ICMPv6 multicast listener discovery messages trigger the problem.
In case it also matters, the skge interface in question (eth1 in what
follows) is part of a bridge that contains another Ethernet interface
and a Wifi card.
Here is a frame, with its link-level headers, that caused an error
when received by skge:
0000 33 33 ff 62 30 d8 60 fb 42 f1 b1 36 86 dd 60 00 33.b0.`.B..6..`.
0010 00 00 00 20 00 01 fe 80 00 00 00 00 00 00 62 fb ... ..........b.
0020 42 ff fe f1 b1 36 ff 02 00 00 00 00 00 00 00 00 B....6..........
0030 00 01 ff 62 30 d8 3a 00 01 00 05 02 00 00 83 00 ...b0.:.........
0040 c9 8a 00 00 00 00 ff 02 00 00 00 00 00 00 00 00 ................
0050 00 01 ff 62 30 d8 ...b0.
(Network dumps performed on another network device suggest that the
checksum is, indeed, correct.)
And here is the syslog produced upon receiving the above packet:
Nov 15 17:52:13 pleiades kernel: [ 661.393163] eth1: hw csum failure
Nov 15 17:52:13 pleiades kernel: [ 661.394203] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.3.0-pleiades #1
Nov 15 17:52:13 pleiades kernel: [ 661.395192] Hardware name: System manufacturer System Product Name/P5WD2-Premium, BIOS 0709 03/31/2006
Nov 15 17:52:13 pleiades kernel: [ 661.395192] ffff88013a9d5d00 ffff88013fc03aa8 ffffffff8129a186 ffff88013afe0000
Nov 15 17:52:13 pleiades kernel: [ 661.395192] ffff88013fc03ac0 ffffffff81436425 0000000000000000 ffff88013fc03af0
Nov 15 17:52:13 pleiades kernel: [ 661.395192] ffffffff8142b87a 1027316b3fc03b30 ffff88013a9d5d00 0000000000000030
Nov 15 17:52:13 pleiades kernel: [ 661.395192] Call Trace:
Nov 15 17:52:13 pleiades kernel: [ 661.395192] <IRQ> [<ffffffff8129a186>] dump_stack+0x44/0x5e
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81436425>] netdev_rx_csum_fault+0x35/0x40
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8142b87a>] __skb_checksum_complete+0xca/0xd0
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff815062db>] ipv6_mc_validate_checksum+0xab/0x140
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8142858f>] skb_checksum_trimmed+0x8f/0x180
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81506475>] ipv6_mc_check_mld+0x105/0x330
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0d2840c>] br_multicast_rcv+0x8c/0xce0 [bridge]
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff814364d3>] ? __netif_receive_skb+0x13/0x60
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8143654e>] ? netif_receive_skb_internal+0x2e/0x90
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0d2006c>] br_handle_frame_finish+0x28c/0x5b0 [bridge]
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa00217e4>] ? usb_hcd_submit_urb+0xa4/0x960 [usbcore]
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0d204e1>] br_handle_frame+0x151/0x270 [bridge]
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0023092>] ? usb_submit_urb+0x2d2/0x510 [usbcore]
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81433c82>] __netif_receive_skb_core+0x1c2/0x990
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0020472>] ? __usb_hcd_giveback_urb+0x82/0xe0 [usbcore]
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff814364d3>] __netif_receive_skb+0x13/0x60
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8143654e>] netif_receive_skb_internal+0x2e/0x90
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81436d70>] napi_gro_receive+0xa0/0xd0
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa01cecc0>] skge_poll+0x380/0x7a0 [skge]
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81032438>] ? lapic_next_event+0x18/0x20
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81437cec>] net_rx_action+0x13c/0x300
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8104fef7>] __do_softirq+0xc7/0x240
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81050240>] irq_exit+0x70/0x90
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff810060b1>] do_IRQ+0x51/0xd0
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8151ee7c>] common_interrupt+0x7c/0x7c
Nov 15 17:52:13 pleiades kernel: [ 661.395192] <EOI> [<ffffffff8100da47>] ? mwait_idle+0x87/0x140
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8100dffa>] arch_cpu_idle+0xa/0x10
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81081f45>] default_idle_call+0x25/0x30
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8108223c>] cpu_startup_entry+0x29c/0x310
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff815194e2>] rest_init+0x72/0x80
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817db00f>] start_kernel+0x471/0x47e
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817da989>] ? set_init_arg+0x55/0x55
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817da5ad>] x86_64_start_reservations+0x2a/0x2c
Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817da694>] x86_64_start_kernel+0xe5/0xe8
I can unfortunately offer no additional information: I will no longer
be using this Ethernet hardware and can only access the machine
physically on rare occasions, so I can do no further tests. Here are
links to the basic config information, though:
Kernel config:
http://www.madore.org/~david/.tmp/config.20151115
Initial dmesg:
http://www.madore.org/~david/.tmp/dmesg.20151115
--
David A. Madore
( http://www.madore.org/~david/ )
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: "hw csum failure" error on skge driver with 4.3 kernel upon receiving ICMPv6 multicast listener discovery packets
2015-11-15 18:44 "hw csum failure" error on skge driver with 4.3 kernel upon receiving ICMPv6 multicast listener discovery packets David Madore
@ 2015-11-15 21:11 ` Stephen Hemminger
2015-12-01 21:07 ` Stefan Ring
1 sibling, 0 replies; 4+ messages in thread
From: Stephen Hemminger @ 2015-11-15 21:11 UTC (permalink / raw)
To: David Madore; +Cc: Linux Kernel mailing-list, Linux network mailing-list
On Sun, 15 Nov 2015 19:44:02 +0100
David Madore <david+ml@madore.org> wrote:
> The skge driver in the 4.3 kernel reports hardware checksum errors
> upon receiving (certain?) IPv6 multicast packets containing ICMPv6
> multicast listener discovery messages. This is a regression since 4.1
> (I believe between 4.1 and 4.2). The e1000e driver on a different
> Ethernet port of the same machine is not affected. Disabling offload
> rx checksumming suppresses the errors. Nor are all IPv6 multicast
> packets affected: for some reason, it seems only those containing
> ICMPv6 multicast listener discovery messages trigger the problem.
>
> In case it also matters, the skge interface in question (eth1 in what
> follows) is part of a bridge that contains another Ethernet interface
> and a Wifi card.
>
> Here is a frame, with its link-level headers, that caused an error
> when received by skge:
>
> 0000 33 33 ff 62 30 d8 60 fb 42 f1 b1 36 86 dd 60 00 33.b0.`.B..6..`.
> 0010 00 00 00 20 00 01 fe 80 00 00 00 00 00 00 62 fb ... ..........b.
> 0020 42 ff fe f1 b1 36 ff 02 00 00 00 00 00 00 00 00 B....6..........
> 0030 00 01 ff 62 30 d8 3a 00 01 00 05 02 00 00 83 00 ...b0.:.........
> 0040 c9 8a 00 00 00 00 ff 02 00 00 00 00 00 00 00 00 ................
> 0050 00 01 ff 62 30 d8 ...b0.
>
> (Network dumps performed on another network device suggest that the
> checksum is, indeed, correct.)
>
> And here is the syslog produced upon receiving the above packet:
>
> Nov 15 17:52:13 pleiades kernel: [ 661.393163] eth1: hw csum failure
> Nov 15 17:52:13 pleiades kernel: [ 661.394203] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.3.0-pleiades #1
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] Hardware name: System manufacturer System Product Name/P5WD2-Premium, BIOS 0709 03/31/2006
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] ffff88013a9d5d00 ffff88013fc03aa8 ffffffff8129a186 ffff88013afe0000
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] ffff88013fc03ac0 ffffffff81436425 0000000000000000 ffff88013fc03af0
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] ffffffff8142b87a 1027316b3fc03b30 ffff88013a9d5d00 0000000000000030
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] Call Trace:
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] <IRQ> [<ffffffff8129a186>] dump_stack+0x44/0x5e
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81436425>] netdev_rx_csum_fault+0x35/0x40
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8142b87a>] __skb_checksum_complete+0xca/0xd0
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff815062db>] ipv6_mc_validate_checksum+0xab/0x140
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8142858f>] skb_checksum_trimmed+0x8f/0x180
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81506475>] ipv6_mc_check_mld+0x105/0x330
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0d2840c>] br_multicast_rcv+0x8c/0xce0 [bridge]
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff814364d3>] ? __netif_receive_skb+0x13/0x60
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8143654e>] ? netif_receive_skb_internal+0x2e/0x90
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0d2006c>] br_handle_frame_finish+0x28c/0x5b0 [bridge]
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa00217e4>] ? usb_hcd_submit_urb+0xa4/0x960 [usbcore]
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0d204e1>] br_handle_frame+0x151/0x270 [bridge]
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0023092>] ? usb_submit_urb+0x2d2/0x510 [usbcore]
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81433c82>] __netif_receive_skb_core+0x1c2/0x990
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0020472>] ? __usb_hcd_giveback_urb+0x82/0xe0 [usbcore]
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff814364d3>] __netif_receive_skb+0x13/0x60
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8143654e>] netif_receive_skb_internal+0x2e/0x90
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81436d70>] napi_gro_receive+0xa0/0xd0
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa01cecc0>] skge_poll+0x380/0x7a0 [skge]
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81032438>] ? lapic_next_event+0x18/0x20
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81437cec>] net_rx_action+0x13c/0x300
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8104fef7>] __do_softirq+0xc7/0x240
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81050240>] irq_exit+0x70/0x90
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff810060b1>] do_IRQ+0x51/0xd0
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8151ee7c>] common_interrupt+0x7c/0x7c
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] <EOI> [<ffffffff8100da47>] ? mwait_idle+0x87/0x140
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8100dffa>] arch_cpu_idle+0xa/0x10
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81081f45>] default_idle_call+0x25/0x30
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8108223c>] cpu_startup_entry+0x29c/0x310
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff815194e2>] rest_init+0x72/0x80
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817db00f>] start_kernel+0x471/0x47e
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817da989>] ? set_init_arg+0x55/0x55
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817da5ad>] x86_64_start_reservations+0x2a/0x2c
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817da694>] x86_64_start_kernel+0xe5/0xe8
>
>
> I can unfortunately offer no additional information: I will no longer
> be using this Ethernet hardware and can only access the machine
> physically on rare occasions, so I can do no further tests. Here are
> links to the basic config information, though:
>
> Kernel config:
> http://www.madore.org/~david/.tmp/config.20151115
>
> Initial dmesg:
> http://www.madore.org/~david/.tmp/dmesg.20151115
>
skge is one of the few drivers which uses CHECKSUM_COMPLETE.
When these errors showed up in the past it was because some part
or the protocol stack forgot to call skb_postpull_rcsum
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: "hw csum failure" error on skge driver with 4.3 kernel upon receiving ICMPv6 multicast listener discovery packets
2015-11-15 18:44 "hw csum failure" error on skge driver with 4.3 kernel upon receiving ICMPv6 multicast listener discovery packets David Madore
2015-11-15 21:11 ` Stephen Hemminger
@ 2015-12-01 21:07 ` Stefan Ring
2015-12-01 21:37 ` Stephen Hemminger
1 sibling, 1 reply; 4+ messages in thread
From: Stefan Ring @ 2015-12-01 21:07 UTC (permalink / raw)
To: David Madore; +Cc: Linux Kernel mailing-list, Linux network mailing-list
On Sun, Nov 15, 2015 at 7:44 PM, David Madore <david+ml@madore.org> wrote:
> The skge driver in the 4.3 kernel reports hardware checksum errors
> upon receiving (certain?) IPv6 multicast packets containing ICMPv6
> multicast listener discovery messages. This is a regression since 4.1
> (I believe between 4.1 and 4.2). The e1000e driver on a different
> Ethernet port of the same machine is not affected. Disabling offload
> rx checksumming suppresses the errors. Nor are all IPv6 multicast
> packets affected: for some reason, it seems only those containing
> ICMPv6 multicast listener discovery messages trigger the problem.
>
> In case it also matters, the skge interface in question (eth1 in what
> follows) is part of a bridge that contains another Ethernet interface
> and a Wifi card.
>
> Here is a frame, with its link-level headers, that caused an error
> when received by skge:
>
> 0000 33 33 ff 62 30 d8 60 fb 42 f1 b1 36 86 dd 60 00 33.b0.`.B..6..`.
> 0010 00 00 00 20 00 01 fe 80 00 00 00 00 00 00 62 fb ... ..........b.
> 0020 42 ff fe f1 b1 36 ff 02 00 00 00 00 00 00 00 00 B....6..........
> 0030 00 01 ff 62 30 d8 3a 00 01 00 05 02 00 00 83 00 ...b0.:.........
> 0040 c9 8a 00 00 00 00 ff 02 00 00 00 00 00 00 00 00 ................
> 0050 00 01 ff 62 30 d8 ...b0.
>
> (Network dumps performed on another network device suggest that the
> checksum is, indeed, correct.)
>
> And here is the syslog produced upon receiving the above packet:
>
> Nov 15 17:52:13 pleiades kernel: [ 661.393163] eth1: hw csum failure
> Nov 15 17:52:13 pleiades kernel: [ 661.394203] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.3.0-pleiades #1
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] Hardware name: System manufacturer System Product Name/P5WD2-Premium, BIOS 0709 03/31/2006
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] ffff88013a9d5d00 ffff88013fc03aa8 ffffffff8129a186 ffff88013afe0000
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] ffff88013fc03ac0 ffffffff81436425 0000000000000000 ffff88013fc03af0
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] ffffffff8142b87a 1027316b3fc03b30 ffff88013a9d5d00 0000000000000030
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] Call Trace:
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] <IRQ> [<ffffffff8129a186>] dump_stack+0x44/0x5e
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81436425>] netdev_rx_csum_fault+0x35/0x40
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8142b87a>] __skb_checksum_complete+0xca/0xd0
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff815062db>] ipv6_mc_validate_checksum+0xab/0x140
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8142858f>] skb_checksum_trimmed+0x8f/0x180
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81506475>] ipv6_mc_check_mld+0x105/0x330
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0d2840c>] br_multicast_rcv+0x8c/0xce0 [bridge]
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff814364d3>] ? __netif_receive_skb+0x13/0x60
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8143654e>] ? netif_receive_skb_internal+0x2e/0x90
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0d2006c>] br_handle_frame_finish+0x28c/0x5b0 [bridge]
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa00217e4>] ? usb_hcd_submit_urb+0xa4/0x960 [usbcore]
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0d204e1>] br_handle_frame+0x151/0x270 [bridge]
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0023092>] ? usb_submit_urb+0x2d2/0x510 [usbcore]
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81433c82>] __netif_receive_skb_core+0x1c2/0x990
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0020472>] ? __usb_hcd_giveback_urb+0x82/0xe0 [usbcore]
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff814364d3>] __netif_receive_skb+0x13/0x60
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8143654e>] netif_receive_skb_internal+0x2e/0x90
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81436d70>] napi_gro_receive+0xa0/0xd0
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa01cecc0>] skge_poll+0x380/0x7a0 [skge]
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81032438>] ? lapic_next_event+0x18/0x20
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81437cec>] net_rx_action+0x13c/0x300
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8104fef7>] __do_softirq+0xc7/0x240
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81050240>] irq_exit+0x70/0x90
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff810060b1>] do_IRQ+0x51/0xd0
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8151ee7c>] common_interrupt+0x7c/0x7c
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] <EOI> [<ffffffff8100da47>] ? mwait_idle+0x87/0x140
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8100dffa>] arch_cpu_idle+0xa/0x10
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81081f45>] default_idle_call+0x25/0x30
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8108223c>] cpu_startup_entry+0x29c/0x310
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff815194e2>] rest_init+0x72/0x80
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817db00f>] start_kernel+0x471/0x47e
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817da989>] ? set_init_arg+0x55/0x55
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817da5ad>] x86_64_start_reservations+0x2a/0x2c
> Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817da694>] x86_64_start_kernel+0xe5/0xe8
>
I have basically the same issue starting with v4.2, with the sky2 driver.
https://bugzilla.redhat.com/show_bug.cgi?id=1266601
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: "hw csum failure" error on skge driver with 4.3 kernel upon receiving ICMPv6 multicast listener discovery packets
2015-12-01 21:07 ` Stefan Ring
@ 2015-12-01 21:37 ` Stephen Hemminger
0 siblings, 0 replies; 4+ messages in thread
From: Stephen Hemminger @ 2015-12-01 21:37 UTC (permalink / raw)
To: Stefan Ring
Cc: David Madore, Linux Kernel mailing-list, Linux network mailing-list
On Tue, 1 Dec 2015 22:07:45 +0100
Stefan Ring <stefanrin@gmail.com> wrote:
> On Sun, Nov 15, 2015 at 7:44 PM, David Madore <david+ml@madore.org> wrote:
> > The skge driver in the 4.3 kernel reports hardware checksum errors
> > upon receiving (certain?) IPv6 multicast packets containing ICMPv6
> > multicast listener discovery messages. This is a regression since 4.1
> > (I believe between 4.1 and 4.2). The e1000e driver on a different
> > Ethernet port of the same machine is not affected. Disabling offload
> > rx checksumming suppresses the errors. Nor are all IPv6 multicast
> > packets affected: for some reason, it seems only those containing
> > ICMPv6 multicast listener discovery messages trigger the problem.
> >
> > In case it also matters, the skge interface in question (eth1 in what
> > follows) is part of a bridge that contains another Ethernet interface
> > and a Wifi card.
> >
> > Here is a frame, with its link-level headers, that caused an error
> > when received by skge:
> >
> > 0000 33 33 ff 62 30 d8 60 fb 42 f1 b1 36 86 dd 60 00 33.b0.`.B..6..`.
> > 0010 00 00 00 20 00 01 fe 80 00 00 00 00 00 00 62 fb ... ..........b.
> > 0020 42 ff fe f1 b1 36 ff 02 00 00 00 00 00 00 00 00 B....6..........
> > 0030 00 01 ff 62 30 d8 3a 00 01 00 05 02 00 00 83 00 ...b0.:.........
> > 0040 c9 8a 00 00 00 00 ff 02 00 00 00 00 00 00 00 00 ................
> > 0050 00 01 ff 62 30 d8 ...b0.
> >
> > (Network dumps performed on another network device suggest that the
> > checksum is, indeed, correct.)
> >
> > And here is the syslog produced upon receiving the above packet:
> >
> > Nov 15 17:52:13 pleiades kernel: [ 661.393163] eth1: hw csum failure
> > Nov 15 17:52:13 pleiades kernel: [ 661.394203] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.3.0-pleiades #1
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] Hardware name: System manufacturer System Product Name/P5WD2-Premium, BIOS 0709 03/31/2006
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] ffff88013a9d5d00 ffff88013fc03aa8 ffffffff8129a186 ffff88013afe0000
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] ffff88013fc03ac0 ffffffff81436425 0000000000000000 ffff88013fc03af0
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] ffffffff8142b87a 1027316b3fc03b30 ffff88013a9d5d00 0000000000000030
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] Call Trace:
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] <IRQ> [<ffffffff8129a186>] dump_stack+0x44/0x5e
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81436425>] netdev_rx_csum_fault+0x35/0x40
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8142b87a>] __skb_checksum_complete+0xca/0xd0
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff815062db>] ipv6_mc_validate_checksum+0xab/0x140
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8142858f>] skb_checksum_trimmed+0x8f/0x180
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81506475>] ipv6_mc_check_mld+0x105/0x330
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0d2840c>] br_multicast_rcv+0x8c/0xce0 [bridge]
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff814364d3>] ? __netif_receive_skb+0x13/0x60
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8143654e>] ? netif_receive_skb_internal+0x2e/0x90
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0d2006c>] br_handle_frame_finish+0x28c/0x5b0 [bridge]
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa00217e4>] ? usb_hcd_submit_urb+0xa4/0x960 [usbcore]
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0d204e1>] br_handle_frame+0x151/0x270 [bridge]
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0023092>] ? usb_submit_urb+0x2d2/0x510 [usbcore]
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81433c82>] __netif_receive_skb_core+0x1c2/0x990
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa0020472>] ? __usb_hcd_giveback_urb+0x82/0xe0 [usbcore]
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff814364d3>] __netif_receive_skb+0x13/0x60
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8143654e>] netif_receive_skb_internal+0x2e/0x90
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81436d70>] napi_gro_receive+0xa0/0xd0
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffffa01cecc0>] skge_poll+0x380/0x7a0 [skge]
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81032438>] ? lapic_next_event+0x18/0x20
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81437cec>] net_rx_action+0x13c/0x300
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8104fef7>] __do_softirq+0xc7/0x240
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81050240>] irq_exit+0x70/0x90
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff810060b1>] do_IRQ+0x51/0xd0
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8151ee7c>] common_interrupt+0x7c/0x7c
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] <EOI> [<ffffffff8100da47>] ? mwait_idle+0x87/0x140
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8100dffa>] arch_cpu_idle+0xa/0x10
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff81081f45>] default_idle_call+0x25/0x30
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff8108223c>] cpu_startup_entry+0x29c/0x310
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff815194e2>] rest_init+0x72/0x80
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817db00f>] start_kernel+0x471/0x47e
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817da989>] ? set_init_arg+0x55/0x55
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817da5ad>] x86_64_start_reservations+0x2a/0x2c
> > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [<ffffffff817da694>] x86_64_start_kernel+0xe5/0xe8
> >
>
> I have basically the same issue starting with v4.2, with the sky2 driver.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1266601
Same symptom and once again it is not the drivers fault.
It is somewhere in the tunnel path not using postpull_rcsum
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-12-01 21:36 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-15 18:44 "hw csum failure" error on skge driver with 4.3 kernel upon receiving ICMPv6 multicast listener discovery packets David Madore
2015-11-15 21:11 ` Stephen Hemminger
2015-12-01 21:07 ` Stefan Ring
2015-12-01 21:37 ` Stephen Hemminger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.