1. 11 3月, 2011 1 次提交
  2. 02 3月, 2011 1 次提交
  3. 17 2月, 2011 2 次提交
  4. 12 2月, 2011 1 次提交
  5. 08 2月, 2011 1 次提交
  6. 24 1月, 2011 2 次提交
  7. 14 1月, 2011 2 次提交
  8. 10 1月, 2011 3 次提交
  9. 25 12月, 2010 2 次提交
  10. 17 12月, 2010 1 次提交
  11. 12 12月, 2010 1 次提交
    • T
      drivers/net: don't use flush_scheduled_work() · 23f333a2
      Tejun Heo 提交于
      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: NTejun 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
  12. 11 12月, 2010 5 次提交
  13. 28 11月, 2010 1 次提交
  14. 17 11月, 2010 1 次提交
  15. 16 11月, 2010 1 次提交
  16. 29 10月, 2010 2 次提交
  17. 21 10月, 2010 2 次提交
  18. 01 10月, 2010 2 次提交
  19. 27 9月, 2010 1 次提交
  20. 23 9月, 2010 2 次提交
  21. 15 9月, 2010 1 次提交
  22. 03 9月, 2010 1 次提交
  23. 26 8月, 2010 1 次提交
  24. 09 8月, 2010 1 次提交
    • J
      e100/e1000*/igb*/ixgb*: Add missing read memory barrier · 2d0bb1c1
      Jeff Kirsher 提交于
      Based on patches from Sonny Rao and Milton Miller...
      
      Combined the patches to fix up clean_tx_irq and clean_rx_irq.
      
      The PowerPC architecture does not require loads to independent bytes
      to be ordered without adding an explicit barrier.
      
      In ixgbe_clean_rx_irq we load the status bit then load the packet data.
      With packet split disabled if these loads go out of order we get a
      stale packet, but we will notice the bad sequence numbers and drop it.
      
      The problem occurs with packet split enabled where the TCP/IP header
      and data are in different descriptors. If the reads go out of order
      we may have data that doesn't match the TCP/IP header. Since we use
      hardware checksumming this bad data is never verified and it makes it
      all the way to the application.
      
      This bug was found during stress testing and adding this barrier has
      been shown to fix it.  The bug can manifest as a data integrity issue
      (bad payload data) or as a BUG in skb_pull().
      
      This was a nasty bug to hunt down, if people agree with the fix I think
      it's a candidate for stable.
      
      Previously Submitted to e1000-devel only for ixgbe
      
      http://marc.info/?l=e1000-devel&m=126593062701537&w=3
      
      We've now seen this problem hit with other device drivers (e1000e mostly)
      So I'm resubmitting with fixes for other Intel Device Drivers with
      similar issues.
      
      CC: Milton Miller <miltonm@bga.com>
      CC: Anton Blanchard <anton@samba.org>
      CC: Sonny Rao <sonnyrao@us.ibm.com>
      CC: stable <stable@kernel.org>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d0bb1c1
  25. 03 8月, 2010 2 次提交
    • J
      e1000e: Fix irq_synchronize in MSI-X case · 8e86acd7
      Jeff Kirsher 提交于
      Based on original patch/work from Jean Delvare <jdelvare@suse.de>
      Synchronize all IRQs when in MSI-X IRQ mode.
      
      Jean's original patch hard coded the sync with the 3 possible vectors,
      this patch incorporates more flexibility for the future and aligns
      with how igb stores the number of vectors into the adapter structure.
      
      CC: Jean Delvare <jdelvare@suse.de>
      Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
      Acked-by: NBruce Allan <bruce.w.allan@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e86acd7
    • F
      e1000e: register pm_qos request on hardware activation · c128ec29
      Florian Mickler 提交于
      The pm_qos_add_request call has to register the pm_qos request with the pm_qos
      susbsystem before first use of the pm_qos request via
      pm_qos_update_request.
      
      As pm_qos changed to use plists there is no benefit in registering and
      unregistering the pm_qos request on ifup/ifdown and thus we move the
      registering into e1000_open and the unregistering in e1000_close.
      
      This fixes the following warning:
      
      [    1.786060] WARNING: at kernel/pm_qos_params.c:264
      pm_qos_update_request+0x28/0x54()
      [    1.786088] Hardware name: Latitude E6500
      [    1.787045] pm_qos_update_request() called for unknown object
      [    1.787966] Modules linked in:
      [    1.788940] Pid: 1, comm: swapper Not tainted 2.6.35-rc5-mmotm0719 #1
      [    1.790035] Call Trace:
      [    1.791121]  [<ffffffff81037335>] warn_slowpath_common+0x80/0x98
      [    1.792205]  [<ffffffff810373e1>] warn_slowpath_fmt+0x41/0x43
      [    1.793279]  [<ffffffff81057c14>] pm_qos_update_request+0x28/0x54
      [    1.794347]  [<ffffffff8134889e>] e1000_configure+0x421/0x459
      [    1.795393]  [<ffffffff8134afbd>] e1000_open+0xbd/0x37c
      [    1.796436]  [<ffffffff8105743a>] ? raw_notifier_call_chain+0xf/0x11
      [    1.797491]  [<ffffffff8145f948>] __dev_open+0xae/0xe2
      [    1.798547]  [<ffffffff8145f997>] dev_open+0x1b/0x49
      [    1.799612]  [<ffffffff8146e36e>] netpoll_setup+0x84/0x259
      [    1.800685]  [<ffffffff81b5037c>] init_netconsole+0xbc/0x21f
      [    1.801744]  [<ffffffff81b5026c>] ? sir_wq_init+0x0/0x35
      [    1.802793]  [<ffffffff81b502c0>] ? init_netconsole+0x0/0x21f
      [    1.803845]  [<ffffffff810002ff>] do_one_initcall+0x7a/0x12f
      [    1.804885]  [<ffffffff81b2ccae>] kernel_init+0x138/0x1c2
      [    1.805915]  [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
      [    1.806937]  [<ffffffff81590e00>] ? restore_args+0x0/0x30
      [    1.807955]  [<ffffffff81b2cb76>] ? kernel_init+0x0/0x1c2
      [    1.808958]  [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
      [    1.809958] ---[ end trace 84b562a00a60539e ]---
      Signed-off-by: NFlorian Mickler <florian@mickler.org>
      Tested-by: NValdis Kletnieks <valdis.kletnieks@vt.edu>
      Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c128ec29