From owner-freebsd-net@freebsd.org Tue May 8 17:02:49 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AADDCFBBF21 for ; Tue, 8 May 2018 17:02:49 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3FA0A7BA50; Tue, 8 May 2018 17:02:49 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id w48H2mMB082672; Tue, 8 May 2018 19:02:48 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 8F8AB130; Tue, 8 May 2018 19:02:47 +0200 (CEST) Message-ID: <5AF1D837.4060909@omnilan.de> Date: Tue, 08 May 2018 19:02:47 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Kevin Bowling CC: Stephen Hurd , "freebsd-net@freebsd.org" Subject: iflib-if_igb tests with HEAD success [Was: Re: svn commit: r333338 - in stable/11/sys: dev/bnxt kern net sys] References: <201805072142.w47LgN1R041002@repo.freebsd.org> <5AF16B8B.7030703@omnilan.de> <5AF17134.7020602@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Tue, 08 May 2018 19:02:48 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 17:02:49 -0000 Bezüglich Kevin Bowling's Nachricht vom 08.05.2018 11:52 (localtime): > On Tue, May 8, 2018 at 2:43 AM, Harry Schmalzbauer wrote: … >> But if the simple iflib/hw-support test with kawela+hartwell helps I'm >> happy to do. > > At this point it would be helpful, we think e1000 is nearing pretty > good shape and I need to become familiar with any outstanding bugs. Here's the results for kawela (82576) which, to my surprise, still shows up as "igb" – I thought it would be "emX". igb0: attach_pre capping queues at 8 igb0: using 1024 tx descriptors and 1024 rx descriptors igb0: msix_init qsets capped at 8 igb0: pxm cpus: 2 queue msgs: 9 admincnt: 1 igb0: queue equality override not set, capping rx_queues at 2 and tx_queues at 2 igb0: using 2 rx queues 2 tx queues igb0: Using MSIX interrupts with 3 vectors igb0: allocated for 2 tx_queues igb0: allocated for 2 rx_queues igb0: Ethernet address: 90:e2:ba:80:30:ee igb0: netmap queues/slots: TX 2/1024, RX 2/1024 igb1: mem 0xf7c00000-0xf7c1ffff,0xf7400000-0xf77fffff,0xf7c40000-0xf7c43fff at device 0.1 on pci3 igb1: attach_pre capping queues at 8 igb1: using 1024 tx descriptors and 1024 rx descriptors igb1: msix_init qsets capped at 8 igb1: pxm cpus: 2 queue msgs: 9 admincnt: 1 igb1: queue equality override not set, capping rx_queues at 2 and tx_queues at 2 igb1: using 2 rx queues 2 tx queues igb1: Using MSIX interrupts with 3 vectors igb1: allocated for 2 tx_queues igb1: allocated for 2 rx_queues igb1: Ethernet address: 90:e2:ba:80:30:ef igb1: netmap queues/slots: TX 2/1024, RX 2/1024 dev.igb.0.iflib.driver_version: 7.6.1-k Only 2 queues were allocated because this is my desktop dual core haswell. Running simple NFS4 copies with all offloading bells and whistles enabled and MTU 9000 work fine (over IPv6 and LACP) at full line rate. Only one LACP LOR (no panic as with emo+em1 lagg, where I saw pages full of LORs): lock order reversal: (sleepable after non-sleepable) 1st 0xfffff80002bc9208 if_lagg rmlock (if_lagg rmlock) @ /usr/src/sys/net/if_lagg.c:1433 2nd 0xfffff80002c04550 iflib ctx lock (iflib ctx lock) @ /usr/src/sys/net/iflib.c:3999 stack backtrace: #0 0xffffffff80701113 at witness_debugger+0x73 #1 0xffffffff80700f94 at witness_checkorder+0xe34 #2 0xffffffff806a26a8 at _sx_xlock+0x68 #3 0xffffffff807bbfbc at iflib_if_ioctl+0x8c #4 0xffffffff8079e5f4 at if_addmulti+0x264 #5 0xffffffff821144a8 at lagg_setmulti+0x108 #6 0xffffffff82111a28 at lagg_ioctl+0x128 #7 0xffffffff8079e5f4 at if_addmulti+0x264 #8 0xffffffff807d8b7e at in_joingroup_locked+0x1ce #9 0xffffffff807d8982 at in_joingroup+0x42 #10 0xffffffff807d47cb at in_control+0x93b #11 0xffffffff8079d656 at ifioctl+0x19c6 #12 0xffffffff807068c9 at kern_ioctl+0x2b9 #13 0xffffffff80706598 at sys_ioctl+0x168 #14 0xffffffff809dab2c at amd64_syscall+0x2cc #15 0xffffffff809b71ad at fast_syscall_common+0x101 I must have accidentially excluded kgdb via src.conf – will check and return to the iflib-if_em thread. Thanks, -harry