From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Porter Date: Wed, 29 Jun 2016 15:12:32 -0400 Subject: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification In-Reply-To: <309B89C4C689E141A5FF6A0C5FB2118B81EFDB5D@ORSMSX101.amr.corp.intel.com> References: <1462786062-7572-1-git-send-email-gangfeng.huang@ni.com> <1462786062-7572-2-git-send-email-gangfeng.huang@ni.com> <309B89C4C689E141A5FF6A0C5FB2118B81EFDB5D@ORSMSX101.amr.corp.intel.com> Message-ID: <20160629191232.GA29990@beef> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On Mon, May 16, 2016 at 10:09:04PM +0000, Brown, Aaron F wrote: > > From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On > > Behalf Of Gangfeng > > Sent: Monday, May 9, 2016 2:28 AM > > To: intel-wired-lan at lists.osuosl.org > > Cc: Gangfeng Huang ; Ruhao Gao > > > > Subject: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX > > network flow classification > > > > From: Gangfeng Huang > > > > This patch is meant to allow for RX network flow classification to insert > > and remove Rx filter by ethtool. Ethtool interface has it's own rules > > manager > > > > Show all filters: > > $ ethtool -n eth0 > > 4 RX rings available > > Total 2 rules > > > > Signed-off-by: Ruhao Gao > > Signed-off-by: Gangfeng Huang > > --- > > drivers/net/ethernet/intel/igb/igb.h | 32 +++++ > > drivers/net/ethernet/intel/igb/igb_ethtool.c | 193 > > +++++++++++++++++++++++++++ > > drivers/net/ethernet/intel/igb/igb_main.c | 44 ++++++ > > 3 files changed, 269 insertions(+) > > This patch is causing 3/4 of my regression systems to fail. Driver load seems normal, but applying an IP address via ifconfig causes the following splat in dmesg and /var/log/messages: Hi Aaron, I'm looking at this series on current net-next and am wondering if you saw this issue with just patch 1 applied or you meant the entire series? I've been working with this on an i210 and haven't reproduced your results yet either with just the (non-functional) first patch applied or the entire series. However, I noticed you had no problems on your system with an i210. > ---------------------------------------------- > May 16 14:37:50 u1486 kernel: Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.0b 11/06/2013 > May 16 14:37:50 u1486 kernel: 0000000000000000 ffff880849ad3938 ffffffff813373d7 0000000000000007 > May 16 14:37:50 u1486 kernel: 0000000000000006 0000000000000000 ffff88085c2f6770 ffff880849ad3a58 > May 16 14:37:50 u1486 kernel: ffffffff810c4e13 ffff880849ad39f8 0000000000000005 0000000000000000 > May 16 14:37:50 u1486 kernel: Call Trace: > May 16 14:37:50 u1486 kernel: [] dump_stack+0x6b/0xa4 > May 16 14:37:50 u1486 kernel: [] register_lock_class+0x523/0x5c0 > May 16 14:37:50 u1486 kernel: [] ? check_preemption_disabled+0x1b/0x110 > May 16 14:37:50 u1486 kernel: [] ? kfree+0x1a5/0x3a0 > May 16 14:37:50 u1486 kernel: [] ? __this_cpu_preempt_check+0x13/0x20 > May 16 14:37:50 u1486 kernel: [] __lock_acquire+0x80/0x5d0 > May 16 14:37:50 u1486 kernel: [] ? __kmalloc+0x265/0x3a0 > May 16 14:37:50 u1486 kernel: [] ? kzalloc+0xf/0x20 [igb] > May 16 14:37:50 u1486 kernel: [] lock_acquire+0xca/0x240 > May 16 14:37:50 u1486 kernel: [] ? igb_configure+0xaf/0x1d0 [igb] > May 16 14:37:50 u1486 kernel: [] ? netdev_rss_key_fill+0x5b/0xa0 > May 16 14:37:50 u1486 kernel: [] ? igb_vfta_set+0x189/0x1f0 [igb] > May 16 14:37:50 u1486 kernel: [] _raw_spin_lock+0x40/0x80 > May 16 14:37:50 u1486 kernel: [] ? igb_configure+0xaf/0x1d0 [igb] > May 16 14:37:50 u1486 kernel: [] ? igb_setup_rctl+0x22/0xb0 [igb] > May 16 14:37:50 u1486 kernel: [] igb_configure+0xaf/0x1d0 [igb] > May 16 14:37:50 u1486 kernel: [] __igb_open+0xfd/0x300 [igb] > May 16 14:37:50 u1486 kernel: [] ? call_netdevice_notifiers_info+0x40/0x70 > May 16 14:37:50 u1486 kernel: [] igb_open+0x10/0x20 [igb] > May 16 14:37:50 u1486 kernel: [] __dev_open+0xb8/0x110 > May 16 14:37:50 u1486 kernel: [] __dev_change_flags+0xac/0x180 > May 16 14:37:50 u1486 kernel: [] dev_change_flags+0x30/0x70 > May 16 14:37:50 u1486 kernel: [] ? lockdep_rtnl_is_held+0x15/0x20 > May 16 14:37:50 u1486 kernel: [] devinet_ioctl+0x5b5/0x620 > May 16 14:37:50 u1486 kernel: [] ? trace_buffer_unlock_commit+0x60/0x80 > May 16 14:37:50 u1486 kernel: [] inet_ioctl+0x63/0x80 > May 16 14:37:50 u1486 kernel: [] sock_do_ioctl+0x30/0x70 > May 16 14:37:50 u1486 kernel: [] sock_ioctl+0x73/0x280 > May 16 14:37:50 u1486 kernel: [] vfs_ioctl+0x18/0x30 > May 16 14:37:50 u1486 kernel: [] do_vfs_ioctl+0x87/0x430 > May 16 14:37:50 u1486 kernel: [] ? syscall_trace_enter_phase2+0x6e/0x280 > May 16 14:37:50 u1486 kernel: [] SyS_ioctl+0x92/0xa0 > May 16 14:37:50 u1486 kernel: [] do_syscall_64+0x63/0x130 > May 16 14:37:50 u1486 kernel: [] ? trace_hardirqs_on_thunk+0x1b/0x1d > May 16 14:37:50 u1486 kernel: [] entry_SYSCALL64_slow_path+0x25/0x25 > ---------------------------------------------- Since it's doing dump_stack in register_lock_class it appears some of the error has been truncated before this stack trace. Can you confirm that this is the complete output logged? By inspection, I would expect to see one of the contextual messages from register_lock_class when it calls dump_stack. Also, any chance of seeing a .config for this run or a freshly reproduced run? By inspection at least there's no obvious locking or otherwise issues in the open path (only *filter_restore() is executed on open and it's a mostly a NOP if this is just patch 1 applied) so I think we need some more detailed output since you have the only system that seems to produce this issue. Any other details you can provide would be appreciated. I'm happy to dig into the root cause. Thanks, Matt