Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752604AbbKOVLP (ORCPT ); Sun, 15 Nov 2015 16:11:15 -0500 Received: from mail-pa0-f54.google.com ([209.85.220.54]:33484 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751749AbbKOVLM (ORCPT ); Sun, 15 Nov 2015 16:11:12 -0500 Date: Sun, 15 Nov 2015 13:11:22 -0800 From: Stephen Hemminger To: David Madore Cc: Linux Kernel mailing-list , Linux network mailing-list Subject: Re: "hw csum failure" error on skge driver with 4.3 kernel upon receiving ICMPv6 multicast listener discovery packets Message-ID: <20151115131122.5501a1b5@xeon-e3> In-Reply-To: <20151115184402.GA6614@achernar.madore.org> References: <20151115184402.GA6614@achernar.madore.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6625 Lines: 95 On Sun, 15 Nov 2015 19:44:02 +0100 David Madore 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] [] dump_stack+0x44/0x5e > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] netdev_rx_csum_fault+0x35/0x40 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] __skb_checksum_complete+0xca/0xd0 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] ipv6_mc_validate_checksum+0xab/0x140 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] skb_checksum_trimmed+0x8f/0x180 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] ipv6_mc_check_mld+0x105/0x330 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] br_multicast_rcv+0x8c/0xce0 [bridge] > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] ? __netif_receive_skb+0x13/0x60 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] ? netif_receive_skb_internal+0x2e/0x90 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] br_handle_frame_finish+0x28c/0x5b0 [bridge] > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] ? usb_hcd_submit_urb+0xa4/0x960 [usbcore] > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] br_handle_frame+0x151/0x270 [bridge] > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] ? usb_submit_urb+0x2d2/0x510 [usbcore] > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] __netif_receive_skb_core+0x1c2/0x990 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] ? __usb_hcd_giveback_urb+0x82/0xe0 [usbcore] > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] __netif_receive_skb+0x13/0x60 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] netif_receive_skb_internal+0x2e/0x90 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] napi_gro_receive+0xa0/0xd0 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] skge_poll+0x380/0x7a0 [skge] > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] ? lapic_next_event+0x18/0x20 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] net_rx_action+0x13c/0x300 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] __do_softirq+0xc7/0x240 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] irq_exit+0x70/0x90 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] do_IRQ+0x51/0xd0 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] common_interrupt+0x7c/0x7c > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] ? mwait_idle+0x87/0x140 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] arch_cpu_idle+0xa/0x10 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] default_idle_call+0x25/0x30 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] cpu_startup_entry+0x29c/0x310 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] rest_init+0x72/0x80 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] start_kernel+0x471/0x47e > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] ? set_init_arg+0x55/0x55 > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] x86_64_start_reservations+0x2a/0x2c > Nov 15 17:52:13 pleiades kernel: [ 661.395192] [] 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/