Skip to content
Snippets Groups Projects
  1. Jul 21, 2011
  2. Jul 18, 2011
  3. Jun 27, 2011
  4. Jun 24, 2011
  5. Jun 21, 2011
  6. May 22, 2011
    • Paul Gortmaker's avatar
      Add appropriate <linux/prefetch.h> include for prefetch users · 70c71606
      Paul Gortmaker authored
      
      After discovering that wide use of prefetch on modern CPUs
      could be a net loss instead of a win, net drivers which were
      relying on the implicit inclusion of prefetch.h via the list
      headers showed up in the resulting cleanup fallout.  Give
      them an explicit include via the following $0.02 script.
      
       =========================================
       #!/bin/bash
       MANUAL=""
       for i in `git grep -l 'prefetch(.*)' .` ; do
       	grep -q '<linux/prefetch.h>' $i
       	if [ $? = 0 ] ; then
       		continue
       	fi
      
       	(	echo '?^#include <linux/?a'
       		echo '#include <linux/prefetch.h>'
       		echo .
       		echo w
       		echo q
       	) | ed -s $i > /dev/null 2>&1
       	if [ $? != 0 ]; then
       		echo $i needs manual fixup
       		MANUAL="$i $MANUAL"
       	fi
       done
       echo ------------------- 8\<----------------------
       echo vi $MANUAL
       =========================================
      
      Signed-off-by: default avatarPaul <paul.gortmaker@windriver.com>
      [ Fixed up some incorrect #include placements, and added some
        non-network drivers and the fib_trie.c case    - Linus ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      70c71606
    • Paul Gortmaker's avatar
      drivers/net: add prefetch header for prefetch users · c0cba59e
      Paul Gortmaker authored
      
      After discovering that wide use of prefetch on modern CPUs
      could be a net loss instead of a win, net drivers which were
      relying on the implicit inclusion of prefetch.h via the list
      headers showed up in the resulting cleanup fallout.  Give
      them an explicit include via the following $0.02 script.
      
       =========================================
       #!/bin/bash
       MANUAL=""
       for i in `git grep -l 'prefetch(.*)' .` ; do
       	grep -q '<linux/prefetch.h>' $i
       	if [ $? = 0 ] ; then
       		continue
       	fi
      
       	(	echo '?^#include <linux/?a'
       		echo '#include <linux/prefetch.h>'
       		echo .
       		echo w
       		echo q
       	) | ed -s $i > /dev/null 2>&1
       	if [ $? != 0 ]; then
       		echo $i needs manual fixup
       		MANUAL="$i $MANUAL"
       	fi
       done
       echo ------------------- 8\<----------------------
       echo vi $MANUAL
       =========================================
      
      Signed-off-by: default avatarPaul <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0cba59e
  7. Apr 29, 2011
  8. Apr 17, 2011
  9. Apr 14, 2011
    • Allan, Bruce W's avatar
      ethtool: allow custom interval for physical identification · fce55922
      Allan, Bruce W authored
      
      When physical identification of an adapter is done by toggling the
      mechanism on and off through software utilizing the set_phys_id operation,
      it is done with a fixed duration for both on and off states.  Some drivers
      may want to set a custom duration for the on/off intervals.  This patch
      changes the API so the return code from the driver's entry point when it
      is called with ETHTOOL_ID_ACTIVE can specify the frequency at which to
      cycle the on/off states, and updates the drivers that have already been
      converted to use the new set_phys_id and use the synchronous method for
      identifying an adapter.
      
      The physical identification frequency set in the updated drivers is based
      on how it was done prior to the introduction of set_phys_id.
      
      Compile tested only.  Also fixes a compiler warning in sfc.
      
      v2: drivers do not return -EINVAL for ETHOOL_ID_ACTIVE
      v3: fold patchset into single patch and cleanup per Ben's feedback
      
      Signed-off-by: default avatarBruce Allan <bruce.w.allan@intel.com>
      Cc: Ben Hutchings <bhutchings@solarflare.com>
      Cc: Sathya Perla <sathya.perla@emulex.com>
      Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com>
      Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
      Cc: Michael Chan <mchan@broadcom.com>
      Cc: Eilon Greenstein <eilong@broadcom.com>
      Cc: Divy Le Ray <divy@chelsio.com>
      Cc: Don Fry <pcnet32@frontier.com>
      Cc: Jon Mason <jdmason@kudzu.us>
      Cc: Solarflare linux maintainers <linux-net-drivers@solarflare.com>
      Cc: Steve Hodgson <shodgson@solarflare.com>
      Cc: Stephen Hemminger <shemminger@linux-foundation.org>
      Cc: Matt Carlson <mcarlson@broadcom.com>
      Acked-by: default avatarJon Mason <jdmason@kudzu.us>
      Acked-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fce55922
  10. Apr 06, 2011
  11. Mar 31, 2011
  12. Mar 28, 2011
  13. Feb 13, 2011
  14. Feb 08, 2011
  15. Dec 21, 2010
  16. Dec 12, 2010
    • Tejun Heo's avatar
      drivers/net: don't use flush_scheduled_work() · 23f333a2
      Tejun Heo authored
      
      flush_scheduled_work() is on its way out.  This patch contains simple
      conversions to replace flush_scheduled_work() usage with direct
      cancels and flushes.
      
      Directly cancel the used works on driver detach and flush them in
      other cases.
      
      The conversions are mostly straight forward and the only dangers are,
      
      * Forgetting to cancel/flush one or more used works.
      
      * Cancelling when a work should be flushed (ie. the work must be
        executed once scheduled whether the driver is detaching or not).
      
      I've gone over the changes multiple times but it would be much
      appreciated if you can review with the above points in mind.
      
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jay Cliburn <jcliburn@gmail.com>
      Cc: Michael Chan <mchan@broadcom.com>
      Cc: Divy Le Ray <divy@chelsio.com>
      Cc: e1000-devel@lists.sourceforge.net
      Cc: Vasanthy Kolluri <vkolluri@cisco.com>
      Cc: Samuel Ortiz <samuel@sortiz.org>
      Cc: Lennert Buytenhek <buytenh@wantstofly.org>
      Cc: Andrew Gallatin <gallatin@myri.com>
      Cc: Francois Romieu <romieu@fr.zoreil.com>
      Cc: Ramkrishna Vepa <ramkrishna.vepa@exar.com>
      Cc: Matt Carlson <mcarlson@broadcom.com>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Cc: Shreyas Bhatewara <sbhatewara@vmware.com>
      Cc: netdev@vger.kernel.org
      23f333a2
  17. Nov 28, 2010
  18. Nov 27, 2010
  19. Nov 01, 2010
  20. Oct 28, 2010
    • Krishna Kumar's avatar
      cxgb3: Fix panic in free_tx_desc() · b1424ed9
      Krishna Kumar authored
      
      I got a few of these panics (on 2.6.36-rc7) when running high
      number of netperf sessions:
      
      BUG: unable to handle kernel paging request at 0000100000000000
      IP: [<ffffffff813125f0>] skb_release_data+0xa0/0xd0
      Oops: 0000 [#1] SMP
      Pid: 2155, comm: vhost-2115 Not tainted 2.6.36-rc7-ORG #1 49Y6512     /System x3650 M2 -[7947AC1]-
      RIP: 0010:[<ffffffff813125f0>]  [<ffffffff813125f0>] skb_release_data+0xa0/0xd0
      RSP: 0018:ffff880001803738  EFLAGS: 00010206
      RAX: ffff880179b0fc00 RBX: ffff880178b441c0 RCX: 0000000000000000
      RSP: 0018:ffff880001803738  EFLAGS: 00010206
      RAX: ffff880179b0fc00 RBX: ffff880178b441c0 RCX: 0000000000000000
      RDX: ffff880179b0fd40 RSI: 0000000000000000 RDI: 0000100000000000
      RBP: ffff880001803748 R08: 0000000000000001 R09: ffff88017f117000
      R10: ffff88017b990608 R11: ffff88017f117090 R12: ffff880178b441c0
      R13: ffff88017f117090 R14: 0000000000000000 R15: ffff880178b441c0
      FS:  0000000000000000(0000) GS:ffff880001800000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000100000000000 CR3: 000000017ea64000 CR4: 00000000000026e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process vhost-2115 (pid: 2155, threadinfo ffff88017d872000, task ffff88017e954680)
      Stack:
      ffff880178b441c0 0000000000000007 ffff880001803768 ffffffff81312119
      <0> 0000000000000000 0000000000000002 ffff880001803778 ffffffff813121f9
      <0> ffff880001803818 ffffffffa012d14c ffffffffa02de076 ffff880001803700
      Call Trace:
      <IRQ>
      [<ffffffff81312119>] __kfree_skb+0x19/0xa0
      [<ffffffff813121f9>] kfree_skb+0x19/0x40
      [<ffffffffa012d14c>] free_tx_desc+0x2fc/0x350 [cxgb3]
      [<ffffffffa02de076>] ? vhost_poll_wakeup+0x16/0x20 [vhost_net]
      [<ffffffffa01323db>] t3_eth_xmit+0x28b/0x380 [cxgb3]
      [<ffffffff8131ce47>] dev_hard_start_xmit+0x377/0x5a0
      [<ffffffff81335a4a>] sch_direct_xmit+0xfa/0x1d0
      [<ffffffff8131d1a9>] dev_queue_xmit+0x139/0x450
      [<ffffffff81326225>] neigh_resolve_output+0x125/0x340
      [<ffffffff8135a77c>] ip_finish_output+0x14c/0x320
      [<ffffffff8135a9fe>] ip_output+0xae/0xc0
      [<ffffffff8135620f>] ip_forward_finish+0x3f/0x50
      [<ffffffff8135641f>] ip_forward+0x1ff/0x400
      [<ffffffff81354789>] ip_rcv_finish+0x119/0x3e0
      [<ffffffff81354c7d>] ip_rcv+0x22d/0x300
      [<ffffffff8131a95b>] __netif_receive_skb+0x29b/0x570
      [<ffffffff8131ba70>] ? netif_receive_skb+0x0/0x80
      [<ffffffff8131bae8>] netif_receive_skb+0x78/0x80
      [<ffffffffa02a96d8>] br_handle_frame_finish+0x198/0x260 [bridge]
      [<ffffffffa02aebc8>] br_nf_pre_routing_finish+0x238/0x380 [bridge]
      [<ffffffff813424bc>] ? nf_hook_slow+0x6c/0x100
      [<ffffffffa02ae990>] ? br_nf_pre_routing_finish+0x0/0x380 [bridge]
      [<ffffffffa02afb08>] br_nf_pre_routing+0x698/0x7a0 [bridge]
      [<ffffffff81342414>] nf_iterate+0x64/0xa0
      [<ffffffffa02a9540>] ? br_handle_frame_finish+0x0/0x260 [bridge]
      [<ffffffff813424bc>] nf_hook_slow+0x6c/0x100
      [<ffffffffa02a9540>] ? br_handle_frame_finish+0x0/0x260 [bridge]
      [<ffffffffa02a9931>] br_handle_frame+0x191/0x240 [bridge]
      [<ffffffffa02a97a0>] ? br_handle_frame+0x0/0x240 [bridge]
      [<ffffffff8131a863>] __netif_receive_skb+0x1a3/0x570
      [<ffffffff812ef3f6>] ? dma_issue_pending_all+0x76/0xa0
      [<ffffffff8131ad32>] process_backlog+0x102/0x200
      [<ffffffff8131c2d0>] net_rx_action+0x100/0x220
      [<ffffffff810548ef>] __do_softirq+0xaf/0x140
      [<ffffffff8100bcdc>] call_softirq+0x1c/0x30
      [<ffffffff8100dfc5>] ? do_softirq+0x65/0xa0
      [<ffffffff8131c6b8>] netif_rx_ni+0x28/0x30
      [<ffffffffa02c305d>] tun_sendmsg+0x2cd/0x4b0 [tun]
      [<ffffffffa02e01af>] handle_tx+0x1df/0x340 [vhost_net]
      [<ffffffffa02e0340>] handle_tx_kick+0x10/0x20 [vhost_net]
      [<ffffffffa02de29b>] vhost_worker+0xbb/0x130 [vhost_net]
      [<ffffffffa02de1e0>] ? vhost_worker+0x0/0x130 [vhost_net]
      [<ffffffffa02de1e0>] ? vhost_worker+0x0/0x130 [vhost_net]
      [<ffffffff81069686>] kthread+0x96/0xa0
      [<ffffffff8100bbe4>] kernel_thread_helper+0x4/0x10
      [<ffffffff810695f0>] ? kthread+0x0/0xa0
      [<ffffffff8100bbe0>] ? kernel_thread_helper+0x0/0x10
      Code: 8b 94 24 d0 00 00 00 49 8b 84 24 d8 00 00 00 48 8d 14 10 0f b7 0a 39 d9 7f d1 48 8b 7a 10 48 85 ff 74 20 48 c7 42 10 00 00 00 00 <48> 8b 1f e8 e8 fb ff ff 48 85 db 48 89 df 75 f0 49 8b 84 24 d8
      
      Patch below fixes the panic. cxgb4 and cxgb4vf already have this fix.
      
      Signed-off-by: default avatarKrishna Kumar <krkumar2@in.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b1424ed9
    • Nishanth Aravamudan's avatar
      cxgb3: fix crash due to manipulating queues before registration · 69dcfc8a
      Nishanth Aravamudan authored
      
      Along the same lines as "cxgb4: fix crash due to manipulating queues
      before registration" (8f6d9f40), before
      commit "net: allocate tx queues in register_netdevice"
      netif_tx_stop_all_queues and related functions could be used between
      device allocation and registration but now only after registration.
      cxgb4 has such a call before registration and crashes now.  Move it
      after register_netdev.
      
      Signed-off-by: default avatarNishanth Aravamudan <nacc@us.ibm.com>
      Cc: eric.dumazet@gmail.com
      Cc: sonnyrao@us.ibm.com
      Cc: Divy Le Ray <divy@chelsio.com>
      Cc: Dimitris Michailidis <dm@chelsio.com>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Tested-by: default avatarNishanth Aravamudan <nacc@us.ibm.com>
      Acked-by: default avatarDivy Le Ray <divy@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      69dcfc8a
  21. Oct 25, 2010
  22. Oct 21, 2010
  23. Sep 27, 2010
  24. Sep 26, 2010
  25. Sep 16, 2010
  26. Sep 13, 2010
  27. Sep 03, 2010
  28. Sep 02, 2010
  29. Aug 04, 2010
  30. Jul 21, 2010
  31. Jul 09, 2010
  32. Jun 25, 2010
Loading