1. 21 10月, 2010 1 次提交
  2. 01 10月, 2010 2 次提交
  3. 27 9月, 2010 1 次提交
  4. 23 9月, 2010 2 次提交
  5. 15 9月, 2010 1 次提交
  6. 03 9月, 2010 1 次提交
  7. 26 8月, 2010 1 次提交
  8. 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
  9. 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
  10. 31 7月, 2010 1 次提交
    • A
      PCI: change device runtime PM settings for probe and remove · f3ec4f87
      Alan Stern 提交于
      This patch (as1388) changes the way the PCI core handles runtime PM
      settings when probing or unbinding drivers.  Now the core will make
      sure the device is enabled for runtime PM, with a usage count >= 1,
      when a driver is probed.  It does the same when calling a driver's
      remove method.
      
      If the driver wants to use runtime PM, all it has to do is call
      pm_runtime_pu_noidle() near the end of its probe routine (to cancel
      the core's usage increment) and pm_runtime_get_noresume() near the
      start of its remove routine (to restore the usage count).  It does not
      need to mess around with setting the runtime state to enabled,
      disabled, active, or suspended.
      
      The patch updates e1000e and r8169, the only PCI drivers that already
      use the existing runtime PM interface.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      f3ec4f87
  11. 27 7月, 2010 1 次提交
  12. 19 7月, 2010 1 次提交
  13. 30 6月, 2010 2 次提交
    • B
      e1000e: suppress compile warnings on certain archs · 8eb64e6b
      Bruce Allan 提交于
      Commit 84f4ee90 causes compile warnings on
      architectures that have unsigned long long's that are not 64-bit, e.g.
      ia64.
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8eb64e6b
    • D
      e1000e: don't inadvertently re-set INTX_DISABLE · 36f2407f
      Dean Nelson 提交于
      Should e1000_test_msi() fail to see an msi interrupt, it attempts to
      fallback to legacy INTx interrupts. But an error in the code may prevent
      this from happening correctly.
      
      Before calling e1000_test_msi_interrupt(), e1000_test_msi() disables SERR
      by clearing the SERR bit from the just read PCI_COMMAND bits as it writes
      them back out.
      
      Upon return from calling e1000_test_msi_interrupt(), it re-enables SERR
      by writing out the version of PCI_COMMAND it had previously read.
      
      The problem with this is that e1000_test_msi_interrupt() calls
      pci_disable_msi(), which eventually ends up in pci_intx(). And because
      pci_intx() was called with enable set to 1, the INTX_DISABLE bit gets
      cleared from PCI_COMMAND, which is what we want. But when we get back to
      e1000_test_msi(), the INTX_DISABLE bit gets inadvertently re-set because
      of the attempt by e1000_test_msi() to re-enable SERR.
      
      The solution is to have e1000_test_msi() re-read the PCI_COMMAND bits as
      part of its attempt to re-enable SERR.
      
      During debugging/testing of this issue I found that not all the systems
      I ran on had the SERR bit set to begin with. And on some of the systems
      the same could be said for the INTX_DISABLE bit. Needless to say these
      latter systems didn't have a problem falling back to legacy INTx
      interrupts with the code as is.
      Signed-off-by: NDean Nelson <dnelson@redhat.com>
      CC: stable@kernel.org
      Tested-by: NEmil Tantilov <emil.s.tantilov@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      36f2407f
  14. 24 6月, 2010 3 次提交
  15. 19 6月, 2010 4 次提交
  16. 03 6月, 2010 1 次提交
  17. 14 5月, 2010 1 次提交
    • J
      drivers/net: Remove unnecessary returns from void function()s · a4b77097
      Joe Perches 提交于
      This patch removes from drivers/net/ all the unnecessary
      return; statements that precede the last closing brace of
      void functions.
      
      It does not remove the returns that are immediately
      preceded by a label as gcc doesn't like that.
      
      It also does not remove null void functions with return.
      
      Done via:
      $ grep -rP --include=*.[ch] -l "return;\n}" net/ | \
        xargs perl -i -e 'local $/ ; while (<>) { s/\n[ \t\n]+return;\n}/\n}/g; print; }'
      
      with some cleanups by hand.
      
      Compile tested x86 allmodconfig only.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a4b77097
  18. 13 5月, 2010 5 次提交
  19. 11 5月, 2010 1 次提交
    • M
      PM QOS update · ed77134b
      Mark Gross 提交于
      This patch changes the string based list management to a handle base
      implementation to help with the hot path use of pm-qos, it also renames
      much of the API to use "request" as opposed to "requirement" that was
      used in the initial implementation.  I did this because request more
      accurately represents what it actually does.
      
      Also, I added a string based ABI for users wanting to use a string
      interface.  So if the user writes 0xDDDDDDDD formatted hex it will be
      accepted by the interface.  (someone asked me for it and I don't think
      it hurts anything.)
      
      This patch updates some documentation input I got from Randy.
      Signed-off-by: Nmarkgross <mgross@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      ed77134b
  20. 06 5月, 2010 4 次提交
  21. 01 5月, 2010 1 次提交
    • A
      e1000e: Fix oops caused by ASPM patch. · 0c75ba22
      Anton Blanchard 提交于
      Commit 6f461f6c
      ("e1000e: enable/disable ASPM L0s and L1 and ERT according to hardware errata")
      oopses on one of my ppc64 boxes with a NULL pointer (0x4a):
      
      Unable to handle kernel paging request for data at address 0x0000004a
      Faulting instruction address: 0xc0000000004d2f1c
      cpu 0xe: Vector: 300 (Data Access) at [c000000bec1833a0]
          pc: c0000000004d2f1c: .e1000e_disable_aspm+0xe0/0x150
          lr: c0000000004d2f0c: .e1000e_disable_aspm+0xd0/0x150
         dar: 4a
      
      [c000000bec1836d0] c00000000069b9d8 .e1000_probe+0x84/0xe8c
      [c000000bec1837b0] c000000000386d90 .local_pci_probe+0x4c/0x68
      [c000000bec183840] c0000000003872ac .pci_device_probe+0xfc/0x148
      [c000000bec183900] c000000000409e8c .driver_probe_device+0xe4/0x1d0
      [c000000bec1839a0] c00000000040a024 .__driver_attach+0xac/0xf4
      [c000000bec183a40] c000000000409124 .bus_for_each_dev+0x9c/0x10c
      [c000000bec183b00] c000000000409c1c .driver_attach+0x40/0x60
      [c000000bec183b90] c0000000004085dc .bus_add_driver+0x150/0x328
      [c000000bec183c40] c00000000040a58c .driver_register+0x100/0x1c4
      [c000000bec183cf0] c00000000038764c .__pci_register_driver+0x78/0x128
      
      Seems like pdev->bus->self == NULL. I haven't touched pci in a long time
      so I'm trying to remember what this means (no pcie bridge perhaps?)
      
      The patch below fixes the oops for me.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Reviewed-by: NBruce Allan <bruce.w.allan@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c75ba22
  22. 28 4月, 2010 3 次提交