Re: [Intel-wired-lan] NULL dereference on v4.1.x while enabling VF

Hello Hello Don, Thank you for your help. On Fri, May 6, 2016 at 6:26 PM, Skidmore, Donald C wrote: > My validation hasn't be able to recreate the dereference on v4.1.x, v4.5.x or > net_next. Where exactly did you place the two line script in your rc > scripts.

Re: [Intel-wired-lan] NULL dereference on v4.1.x while enabling VF

Hello Don, Thank you for your reply. On Mon, May 2, 2016 at 11:33 PM, Skidmore, Donald C wrote: > Thanks for reporting the dereference. Could you provide a little more detail > on how you created this issue? Are you just running the two commands (ip, >

NULL dereference on v4.1.x while enabling VF

Hello, I am getting a NULL dereference on v4.1.x while enabling VF on a ixgbe ( Intel Corporation 82599ES 10-Gigabit) card during boot. It seems to be related to a race since I don't have the issue if I test it a few seconds after boot. I had the same issue while testing on v4.5.x What can I do

Re: dynamically set number of queues for 82598 devices in -stable

Hi Jeff, Any chance to get an opinion on that? Thanks, On Nov27 11:05, William Dauchy wrote: > Hello Jeff, > > I faced the problem described in commit 7e3f5c8: > ixgbe: fix bounds checking in ixgbe_setup_tc for 82598 > > This patch resolves an issue where users were not a

dynamically set number of queues for 82598 devices in -stable

Hello Jeff, I faced the problem described in commit 7e3f5c8: ixgbe: fix bounds checking in ixgbe_setup_tc for 82598 This patch resolves an issue where users were not able to dynamically set number of queues for 82598 via ethtool -L I backported it for my v4.1.x build but I was wondering if

Re: [net-next 07/15] ixgbe: Fix handling of NAPI budget when multiple queues are enabled per vector

Hello Jeff, There is also the equivalent patch for ixgbevf http://patchwork.ozlabs.org/patch/539065/ On Mon, Nov 23, 2015 at 8:36 PM, Jeff Kirsher wrote: > From: Alexander Duyck > > This patch corrects an issue in which the polling routine

kmemleak report with nfs3/4 activity on v4.1.x

Hello, I'm seeing some kmemleak reports while I'm using nfsv3/4 as a client on linux v4.1.13; unreferenced object 0x880c22a97ad0 (size 16):   comm "softirq", pid 0, jiffies 4294896089 (age 43927.436s)   hex dump (first 16 bytes):     00 00 00 00 00 00 00 00 00 45 1e 24 06 88 ff ff  

Re: [Intel-wired-lan] regression in ixgbe SFP detection patch

On Nov11 22:13, Rustad, Mark D wrote: > Just so you know, there are patches in queue that will improve this situation > in two ways: > 1) When the I2C probe times out, the code assumes that the cage is empty and > does not retry the access until the next probe. > 2) The driver will use its own

regression in ixgbe SFP detection patch

Hello, I upgraded a machine from 3.14.x to v4.1.x and noted that I now have two kworker very often on D state, just after boot while I am not doing anything special. This issue remains indefinitely. This machine has four network interfaces: 01:00.0 Ethernet controller: Intel Corporation 82576

Re: regression in ixgbe SFP detection patch

On Nov11 20:33, Tantilov, Emil S wrote: > If the diff above is the patch you are referring to then you will break the > SFP+ detection in the case where the driver was loaded while there were no > SFP+ modules present in the cages. understood, I was surprised of the modification of behavior. --

Re: [PATCH 1/1] packet: race condition in packet_bind

Hi Francesco, On Thu, Nov 5, 2015 at 5:16 PM, Francesco Ruggeri wrote: > There is a race conditions between packet_notifier and packet_bind{_spkt}. > > It happens if packet_notifier(NETDEV_UNREGISTER) executes between the > time packet_bind{_spkt} takes a reference

Re: unregister_netdevice warnings when deleting netns

On Tue, Sep 29, 2015 at 6:12 PM, Anand Gurram wrote: > Any additional ideas and suggestions on debugging in above scenario? You may give a try with the recent patch: packet: race condition in packet_bind http://www.spinics.net/lists/netdev/msg351337.html -- William

Re: dynamically set number of queues for 82598 devices

Hello David, On Oct29 16:26, William Dauchy wrote: > I faced the problem described in commit 7e3f5c8: > ixgbe: fix bounds checking in ixgbe_setup_tc for 82598 > > This patch resolves an issue where users were not able to dynamically > set number of queues for 82598 via et

Re: [net PATCH 3/3] ixgbe: Fix handling of napi budget when multiple queues are enabled per vector

being processed when the budget was 0 which > is meant to indicate that no Rx can be handled. We may logically have the same issue with VF, right? >From 4521374ae746543a925982d59a8ba73b6aaee59c Mon Sep 17 00:00:00 2001 From: William Dauchy <will...@gandi.net> Date: Fri, 30 Oct 2015 15:

[PATCH] ixgbevf: Fix handling of napi budget when multiple queues are enabled per vector

This is the same patch as for ixgbe but applied differently according to busy polling. see commit "ixgbe: Fix handling of napi budget when multiple queues are enabled per vector" Signed-off-by: William Dauchy <will...@gandi.net> --- drivers/net/ethernet/intel/ixgbevf/ixgbevf_

dynamically set number of queues for 82598 devices

Hello David, I faced the problem described in commit 7e3f5c8: ixgbe: fix bounds checking in ixgbe_setup_tc for 82598 This patch resolves an issue where users were not able to dynamically set number of queues for 82598 via ethtool -L I backported it for my v4.1.x build but I was wondering if