1. 27 6月, 2014 4 次提交
  2. 26 6月, 2014 6 次提交
  3. 25 6月, 2014 16 次提交
    • C
      i40e/i40evf: Bump i40e to 0.4.17 and i40evf to 0.9.36 · 25941f94
      Catherine Sullivan 提交于
      Bump versions.
      
      Change-ID: I47fc3433240800cd823ff512f3015822277b0d20
      Signed-off-by: NCatherine Sullivan <catherine.sullivan@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      25941f94
    • A
      i40e: Bypass timeout recovery level 0 so as to not cause MDD · 327fe04b
      Anjali Singhai Jain 提交于
      When a Tx hang happens, usually the Tx queue disable fails. At
      this point if we try to recover by a VSI reinit the HW gets
      unhappy and we get a Malicious Driver Detect (MDD) event.
      HW expects a PF reset if a queue disable fails, if we don't do a PF
      reset and restart the queue we get an MDD.  This patch makes sure we
      do a PF reset on Tx hang and that way we avoid any MDD because of Tx
      queue disable failure.
      
      Change-ID: I665ab6223577c788da857ee2132e733dc9a451e4
      Signed-off-by: NAnjali Singhai Jain <anjali.singhai@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      327fe04b
    • S
      i40e: no pf reset at pci remove · 264ccc93
      Shannon Nelson 提交于
      The PF reset to clean up at the end of the remove is a nice thing
      to do, but it also removes any LAA setting that Wake On LAN wants
      for future wake up.
      
      Change-ID: Ic090ec714df2d722281d11735cf75f2aa4432e2c
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      264ccc93
    • S
      i40e: reapply LAA after reset · 6252c7e4
      Shannon Nelson 提交于
      The LAA is lost on a reset, so be sure to replay it when rebuilding
      the switch after any reset.
      
      Change-ID: I6e643f9a59dfd899b6cbdf84d93b4bc9c37bb949
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      6252c7e4
    • S
      i40e: allow user to set LAA again · 6c8ad1ba
      Shannon Nelson 提交于
      Don't short-circuit the LAA assignment when the driver thinks it has
      already been done - it is possible that the user might want to force
      the address setting again.  At the same time, this requires a little
      re-ordering of the filter management.
      
      Change-ID: Ia0d71e3bc04edd7b68cf67edecc00abe7b9f6639
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      6c8ad1ba
    • S
      i40e: use WoL flag when setting LAA · cc41222c
      Shannon Nelson 提交于
      Make sure the Firmware sets up the LAA as a Wake-On-LAN address.
      
      Change-ID: I57b9acd8c288424fcfed0911053eb725c400b41c
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      cc41222c
    • C
      i40e: Add ablitity to enable/disable link from set_link_restart_an · 1ac978af
      Catherine Sullivan 提交于
      The ability is already there in the fw and this will make it easy
      to toggle link without calling set_phy_config when no other link
      settings need to change.
      
      Change-ID: I185567ae81776382ac145247e4eb1ee95f22382c
      Signed-off-by: NCatherine Sullivan <catherine.sullivan@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      1ac978af
    • J
      i40e/i40evf: remove reserved type · c571ea05
      Jesse Brandeburg 提交于
      One of the PCTYPES that was moved to a reserved value
      wasn't removed from the code.
      
      Change-ID: I31fafe6d79c5f5128179979af5eaafa8c0cd62fe
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c571ea05
    • C
      i40e: Fix ethtool coalesce settings · 5c2cebda
      Carolyn Wyborny 提交于
      This patch fixes the i40e_set_coalesce function to allow 0 as a disable
      value.  Also, added message to user about invalid value and provides valid
      range.
      
      Change-ID: I6c9ff11a9861f2045bd543745a3d132999ffbbd8
      Signed-off-by: NCarolyn Wyborny <carolyn.wyborny@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      5c2cebda
    • S
      i40e: fix a stray print message · cde4cbc7
      Shannon Nelson 提交于
      This log print message will probably never be seen, but it needs to match
      the "attempting to rebuild switch\n" log message a few lines above.
      
      Change-ID: Ic3f5b4f67568d721cb02e826cf2cb33847f51c11
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      cde4cbc7
    • S
      i40e: warn on newer/older firmware API rev · 278b6f62
      Shannon Nelson 提交于
      If the firmware's API minor number is larger than the one expected, log
      a warning and recommend driver SW update.
      If the firmware's API major or minor number is smaller then the one expected
      (n for major, n or n-1 for minor), log a warning and recommend NVM update.
      
      Change-ID: If0b887e055478f8e435ba7fa28113b63a6f1bb35
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Signed-off-by: NCatherine Sullivan <catherine.sullivan@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      278b6f62
    • N
      i40e: Add PF reset when Malicious driver event for PF · df430b12
      Neerav Parikh 提交于
      As per the spec when the PF driver receives a Malicious driver event
      the queue that caused the event is already stopped and it is expected
      that the function that owns the queue will reset the queue.
      In some cases it may not be possible to determine the queue and it is
      suggested to reset the whole function.
      
      This patch takes the later approach when the event is owned by the PF
      that owns it.
      
      Change-ID: I40f9764a6a5e068c0ef8438db00c5aa9c2c6c1c8
      Signed-off-by: NNeerav Parikh <neerav.parikh@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      df430b12
    • S
      i40e: make prep_for_reset void · 23cfbe07
      Shannon Nelson 提交于
      The return from i40e_prep_for_reset() was being ignored by almost all
      its callers.  The one place it wasn't ignored could have caused a silent
      and confusing failure of the driver to finish a reset.  Since we really
      are doing a rebuild anyway, ignore this last case as well and simply
      make the function a void type.
      
      Change-ID: Ia4fed7f903d39a6c47c5722625a53e59c3f7ed53
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      23cfbe07
    • G
      i40e: Stop the VF device after setting its MAC address · 17413a80
      Greg Rose 提交于
      If the host VMM administrator has changed the VF device's MAC address then
      the i40e driver needs to halt the VF device so that the administrator will
      be forced to reload the VF driver.  This will cause the VF driver to start
      using the newly assigned MAC address.  This brings the i40e driver into
      conformance with operational characteristics of other Intel SR-IOV
      featured drivers.
      
      Change-ID: Ic7242cceb8287dd2cb72fb1f3166a032a28bf88a
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      17413a80
    • L
      cxgb4: Not need to hold the adap_rcu_lock lock when read adap_rcu_list · ee9a33b2
      Li RongQing 提交于
      cxgb4_netdev maybe lead to dead lock, since it uses a spin lock, and be called
      in both thread and softirq context, but not disable BH, the lockdep report is
      below; In fact, cxgb4_netdev only reads adap_rcu_list with RCU protection, so
      not need to hold spin lock again.
      	=================================
      	[ INFO: inconsistent lock state ]
      	3.14.7+ #24 Tainted: G         C O
      	---------------------------------
      	inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      	radvd/3794 [HC0[0]:SC1[1]:HE1:SE0] takes:
      	 (adap_rcu_lock){+.?...}, at: [<ffffffffa09989ea>] clip_add+0x2c/0x116 [cxgb4]
      	{SOFTIRQ-ON-W} state was registered at:
      	  [<ffffffff810fca81>] __lock_acquire+0x34a/0xe48
      	  [<ffffffff810fd98b>] lock_acquire+0x82/0x9d
      	  [<ffffffff815d6ff8>] _raw_spin_lock+0x34/0x43
      	  [<ffffffffa09989ea>] clip_add+0x2c/0x116 [cxgb4]
      	  [<ffffffffa0998beb>] cxgb4_inet6addr_handler+0x117/0x12c [cxgb4]
      	  [<ffffffff815da98b>] notifier_call_chain+0x32/0x5c
      	  [<ffffffff815da9f9>] __atomic_notifier_call_chain+0x44/0x6e
      	  [<ffffffff815daa32>] atomic_notifier_call_chain+0xf/0x11
      	  [<ffffffff815b1356>] inet6addr_notifier_call_chain+0x16/0x18
      	  [<ffffffffa01f72e5>] ipv6_add_addr+0x404/0x46e [ipv6]
      	  [<ffffffffa01f8df0>] addrconf_add_linklocal+0x5f/0x95 [ipv6]
      	  [<ffffffffa01fc3e9>] addrconf_notify+0x632/0x841 [ipv6]
      	  [<ffffffff815da98b>] notifier_call_chain+0x32/0x5c
      	  [<ffffffff810e09a1>] __raw_notifier_call_chain+0x9/0xb
      	  [<ffffffff810e09b2>] raw_notifier_call_chain+0xf/0x11
      	  [<ffffffff8151b3b7>] call_netdevice_notifiers_info+0x4e/0x56
      	  [<ffffffff8151b3d0>] call_netdevice_notifiers+0x11/0x13
      	  [<ffffffff8151c0a6>] netdev_state_change+0x1f/0x38
      	  [<ffffffff8152f004>] linkwatch_do_dev+0x3b/0x49
      	  [<ffffffff8152f184>] __linkwatch_run_queue+0x10b/0x144
      	  [<ffffffff8152f1dd>] linkwatch_event+0x20/0x27
      	  [<ffffffff810d7bc0>] process_one_work+0x1cb/0x2ee
      	  [<ffffffff810d7e3b>] worker_thread+0x12e/0x1fc
      	  [<ffffffff810dd391>] kthread+0xc4/0xcc
      	  [<ffffffff815dc48c>] ret_from_fork+0x7c/0xb0
      	irq event stamp: 3388
      	hardirqs last  enabled at (3388): [<ffffffff810c6c85>]
      	__local_bh_enable_ip+0xaa/0xd9
      	hardirqs last disabled at (3387): [<ffffffff810c6c2d>]
      	__local_bh_enable_ip+0x52/0xd9
      	softirqs last  enabled at (3288): [<ffffffffa01f1d5b>]
      	rcu_read_unlock_bh+0x0/0x2f [ipv6]
      	softirqs last disabled at (3289): [<ffffffff815ddafc>]
      	do_softirq_own_stack+0x1c/0x30
      
      	other info that might help us debug this:
      	 Possible unsafe locking scenario:
      
      	       CPU0
      	       ----
      	  lock(adap_rcu_lock);
      	  <Interrupt>
      	    lock(adap_rcu_lock);
      
      	 *** DEADLOCK ***
      
      	5 locks held by radvd/3794:
      	 #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffffa020b85a>]
      	rawv6_sendmsg+0x74b/0xa4d [ipv6]
      	 #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff8151ac6b>]
      	rcu_lock_acquire+0x0/0x29
      	 #2:  (rcu_read_lock){.+.+..}, at: [<ffffffffa01f4cca>]
      	rcu_lock_acquire.constprop.16+0x0/0x30 [ipv6]
      	 #3:  (rcu_read_lock){.+.+..}, at: [<ffffffff810e09b4>]
      	rcu_lock_acquire+0x0/0x29
      	 #4:  (rcu_read_lock){.+.+..}, at: [<ffffffffa0998782>]
      	rcu_lock_acquire.constprop.40+0x0/0x30 [cxgb4]
      
      	stack backtrace:
      	CPU: 7 PID: 3794 Comm: radvd Tainted: G         C O 3.14.7+ #24
      	Hardware name: Supermicro X7DBU/X7DBU, BIOS 6.00 12/03/2007
      	 ffffffff81f15990 ffff88012fdc36a8 ffffffff815d0016 0000000000000006
      	 ffff8800c80dc2a0 ffff88012fdc3708 ffffffff815cc727 0000000000000001
      	 0000000000000001 ffff880100000000 ffffffff81015b02 ffff8800c80dcb58
      	Call Trace:
      	 <IRQ>  [<ffffffff815d0016>] dump_stack+0x4e/0x71
      	 [<ffffffff815cc727>] print_usage_bug+0x1ec/0x1fd
      	 [<ffffffff81015b02>] ? save_stack_trace+0x27/0x44
      	 [<ffffffff810fbfaa>] ? check_usage_backwards+0xa0/0xa0
      	 [<ffffffff810fc640>] mark_lock+0x11b/0x212
      	 [<ffffffff810fca0b>] __lock_acquire+0x2d4/0xe48
      	 [<ffffffff810fbfaa>] ? check_usage_backwards+0xa0/0xa0
      	 [<ffffffff810fbff6>] ? check_usage_forwards+0x4c/0xa6
      	 [<ffffffff810c6c8a>] ? __local_bh_enable_ip+0xaf/0xd9
      	 [<ffffffff810fd98b>] lock_acquire+0x82/0x9d
      	 [<ffffffffa09989ea>] ? clip_add+0x2c/0x116 [cxgb4]
      	 [<ffffffffa0998782>] ? rcu_read_unlock+0x23/0x23 [cxgb4]
      	 [<ffffffff815d6ff8>] _raw_spin_lock+0x34/0x43
      	 [<ffffffffa09989ea>] ? clip_add+0x2c/0x116 [cxgb4]
      	 [<ffffffffa09987b0>] ? rcu_lock_acquire.constprop.40+0x2e/0x30 [cxgb4]
      	 [<ffffffffa0998782>] ? rcu_read_unlock+0x23/0x23 [cxgb4]
      	 [<ffffffffa09989ea>] clip_add+0x2c/0x116 [cxgb4]
      	 [<ffffffffa0998beb>] cxgb4_inet6addr_handler+0x117/0x12c [cxgb4]
      	 [<ffffffff810fd99d>] ? lock_acquire+0x94/0x9d
      	 [<ffffffff810e09b4>] ? raw_notifier_call_chain+0x11/0x11
      	 [<ffffffff815da98b>] notifier_call_chain+0x32/0x5c
      	 [<ffffffff815da9f9>] __atomic_notifier_call_chain+0x44/0x6e
      	 [<ffffffff815daa32>] atomic_notifier_call_chain+0xf/0x11
      	 [<ffffffff815b1356>] inet6addr_notifier_call_chain+0x16/0x18
      	 [<ffffffffa01f72e5>] ipv6_add_addr+0x404/0x46e [ipv6]
      	 [<ffffffff810fde6a>] ? trace_hardirqs_on+0xd/0xf
      	 [<ffffffffa01fb634>] addrconf_prefix_rcv+0x385/0x6ea [ipv6]
      	 [<ffffffffa0207950>] ndisc_rcv+0x9d3/0xd76 [ipv6]
      	 [<ffffffffa020d536>] icmpv6_rcv+0x592/0x67b [ipv6]
      	 [<ffffffff810c6c85>] ? __local_bh_enable_ip+0xaa/0xd9
      	 [<ffffffff810c6c85>] ? __local_bh_enable_ip+0xaa/0xd9
      	 [<ffffffff810fd8dc>] ? lock_release+0x14e/0x17b
      	 [<ffffffffa020df97>] ? rcu_read_unlock+0x21/0x23 [ipv6]
      	 [<ffffffff8150df52>] ? rcu_read_unlock+0x23/0x23
      	 [<ffffffffa01f4ede>] ip6_input_finish+0x1e4/0x2fc [ipv6]
      	 [<ffffffffa01f540b>] ip6_input+0x33/0x38 [ipv6]
      	 [<ffffffffa01f5557>] ip6_mc_input+0x147/0x160 [ipv6]
      	 [<ffffffffa01f4ba3>] ip6_rcv_finish+0x7c/0x81 [ipv6]
      	 [<ffffffffa01f5397>] ipv6_rcv+0x3a1/0x3e2 [ipv6]
      	 [<ffffffff8151ef96>] __netif_receive_skb_core+0x4ab/0x511
      	 [<ffffffff810fdc94>] ? mark_held_locks+0x71/0x99
      	 [<ffffffff8151f0c0>] ? process_backlog+0x69/0x15e
      	 [<ffffffff8151f045>] __netif_receive_skb+0x49/0x5b
      	 [<ffffffff8151f0cf>] process_backlog+0x78/0x15e
      	 [<ffffffff8151f571>] ? net_rx_action+0x1a2/0x1cc
      	 [<ffffffff8151f47b>] net_rx_action+0xac/0x1cc
      	 [<ffffffff810c69b7>] ? __do_softirq+0xad/0x218
      	 [<ffffffff810c69ff>] __do_softirq+0xf5/0x218
      	 [<ffffffff815ddafc>] do_softirq_own_stack+0x1c/0x30
      	 <EOI>  [<ffffffff810c6bb6>] do_softirq+0x38/0x5d
      	 [<ffffffffa01f1d5b>] ? ip6_copy_metadata+0x156/0x156 [ipv6]
      	 [<ffffffff810c6c78>] __local_bh_enable_ip+0x9d/0xd9
      	 [<ffffffffa01f1d88>] rcu_read_unlock_bh+0x2d/0x2f [ipv6]
      	 [<ffffffffa01f28b4>] ip6_finish_output2+0x381/0x3d8 [ipv6]
      	 [<ffffffffa01f49ef>] ip6_finish_output+0x6e/0x73 [ipv6]
      	 [<ffffffffa01f4a70>] ip6_output+0x7c/0xa8 [ipv6]
      	 [<ffffffff815b1bfa>] dst_output+0x18/0x1c
      	 [<ffffffff815b1c9e>] ip6_local_out+0x1c/0x21
      	 [<ffffffffa01f2489>] ip6_push_pending_frames+0x37d/0x427 [ipv6]
      	 [<ffffffff81558af8>] ? skb_orphan+0x39/0x39
      	 [<ffffffffa020b85a>] ? rawv6_sendmsg+0x74b/0xa4d [ipv6]
      	 [<ffffffffa020ba51>] rawv6_sendmsg+0x942/0xa4d [ipv6]
      	 [<ffffffff81584cd2>] inet_sendmsg+0x3d/0x66
      	 [<ffffffff81508930>] __sock_sendmsg_nosec+0x25/0x27
      	 [<ffffffff8150b0d7>] sock_sendmsg+0x5a/0x7b
      	 [<ffffffff810fd8dc>] ? lock_release+0x14e/0x17b
      	 [<ffffffff8116d756>] ? might_fault+0x9e/0xa5
      	 [<ffffffff8116d70d>] ? might_fault+0x55/0xa5
      	 [<ffffffff81508cb1>] ? copy_from_user+0x2a/0x2c
      	 [<ffffffff8150b70c>] ___sys_sendmsg+0x226/0x2d9
      	 [<ffffffff810fcd25>] ? __lock_acquire+0x5ee/0xe48
      	 [<ffffffff810fde01>] ? trace_hardirqs_on_caller+0x145/0x1a1
      	 [<ffffffff8118efcb>] ? slab_free_hook.isra.71+0x50/0x59
      	 [<ffffffff8115c81f>] ? release_pages+0xbc/0x181
      	 [<ffffffff810fd99d>] ? lock_acquire+0x94/0x9d
      	 [<ffffffff81115e97>] ? read_seqcount_begin.constprop.25+0x73/0x90
      	 [<ffffffff8150c408>] __sys_sendmsg+0x3d/0x5b
      	 [<ffffffff8150c433>] SyS_sendmsg+0xd/0x19
      	 [<ffffffff815dc53d>] system_call_fastpath+0x1a/0x1f
      Reported-by: NBen Greear <greearb@candelatech.com>
      Cc: Casey Leedom <leedom@chelsio.com>
      Cc: Hariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: NLi RongQing <roy.qing.li@gmail.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Acked-by: NCasey Leedom <leedom@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee9a33b2
    • A
      cxgb4: Fix endian bug introduced in cxgb4 dcb patchset · 5433ba36
      Anish Bhatt 提交于
      Hi,
       This patch fixes warnings generated by sparse as pointed out by kbuild test
       robot, please apply to net-next. Applies on top of
      commit 79631c89 ("trivial: net/irda/irlmp.c:
      Fix closing brace followed by if")
      -Anish
      
      v2: cleanup submission as per davem's feedback
      
      Fixes: 76bcb31e ("cxgb4 : Add DCBx support codebase  and dcbnl_ops")
      Signed-off-by: NAnish Bhatt <anish@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5433ba36
  4. 24 6月, 2014 9 次提交
  5. 23 6月, 2014 5 次提交