1. 14 5月, 2010 2 次提交
  2. 06 5月, 2010 1 次提交
  3. 28 4月, 2010 2 次提交
  4. 15 4月, 2010 1 次提交
  5. 04 4月, 2010 1 次提交
    • J
      net: convert multicast list to list_head · 22bedad3
      Jiri Pirko 提交于
      Converts the list and the core manipulating with it to be the same as uc_list.
      
      +uses two functions for adding/removing mc address (normal and "global"
       variant) instead of a function parameter.
      +removes dev_mcast.c completely.
      +exposes netdev_hw_addr_list_* macros along with __hw_addr_* functions for
       manipulation with lists on a sandbox (used in bonding and 80211 drivers)
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22bedad3
  6. 27 3月, 2010 1 次提交
  7. 23 2月, 2010 3 次提交
  8. 04 2月, 2010 2 次提交
  9. 26 1月, 2010 1 次提交
  10. 23 1月, 2010 1 次提交
    • J
      e1000/e1000e: don't use small hardware rx buffers · 9926146b
      Jesse Brandeburg 提交于
      When testing the "e1000: enhance frame fragment detection" (and e1000e)
      patches we found some bugs with reducing the MTU size.  The 1024 byte
      descriptor used with the 1000 mtu test also (re) introduced the
      (originally) reported bug, and causes us to need the e1000_clean_tx_irq
      "enhance frame fragment detection" fix.
      
      So what has occured here is that 2.6.32 is only vulnerable for mtu <
      1500 due to the jumbo specific routines in both e1000 and e1000e.
      So, 2.6.32 needs the 2kB buffer len fix for those smaller MTUs, but
      is not vulnerable to the original issue reported.  It has been pointed
      out that this vulnerability needs to be patched in older kernels that
      don't have the e1000 jumbo routine.  Without the jumbo routines, we
      need the "enhance frame fragment detection" fix the e1000, old
      e1000e is only vulnerable for < 1500 mtu, and needs a similar
      fix.  We split the patches up to provide easy backport paths.
      
      There is only a slight bit of extra code when this fix and the
      original "enhance frame fragment detection" fixes are applied, so
      please apply both, even though it is a bit of overkill.
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9926146b
  11. 21 1月, 2010 2 次提交
  12. 08 1月, 2010 1 次提交
  13. 04 12月, 2009 1 次提交
  14. 03 12月, 2009 1 次提交
  15. 14 10月, 2009 1 次提交
  16. 08 10月, 2009 1 次提交
  17. 27 9月, 2009 10 次提交
  18. 04 9月, 2009 1 次提交
  19. 02 9月, 2009 1 次提交
    • G
      e1000: Fix for e1000 kills IPMI on a tagged vlan. · fd38d7a0
      Graham, David 提交于
      Enabling VLAN filters (VFE) when the primary interface is brought up
      (per commit 78ed11a5) has caused problems for some users who manage
      their systems using IPMI over a VLAN. This is because when the driver
      enables the VLAN filter, this same filter table is enabled for the
      management channel, and the table is initially empty, which means that
      the IPMI/VLAN packets are filtered out and not received by the BMC.
      This is a problem only on e1000 class adapters, as it is only
      on e1000 that the filter table is common to the management and host
      streams.
      
      With this change, filtering is only enabled when one or more host VLANs
      exist, and is disabled when the last host VLAN is removed. VLAN filtering
      is always disabled when the primary interface is in promiscuous mode,
      and will be (re)enabled if VLANs exist when the interface exits
      promiscuous mode.
      
      Note that this does not completely resolve the issue for those using VLAN
      management, because if the host adds a VLAN, then the above problem
      occurs when that VLAN is enabled. However, it does mean the there is no
      problem for configurations where management is on a VLAN and the host is
      not.
      
      A complete solution to this issue would require further driver changes.
      The driver would need to discover if (and which) management VLANs are
      active before enabling VLAN filtering, so that it could ensure that the
      managed VLANs are included in the VLAN filter table. This discovery
      requires that the BMC identifies its VLAN in registers accessible
      to the driver, and at least on Dell PE2850 systems the BMC does not
      identify its VLAN to allow such discovery. Intel is pursuing this issue
      with the BMC vendor.
      Signed-off-by: NDave Graham <david.graham@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Tested-by: NKrzysztof Piotr Oledzki <ole@ans.pl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd38d7a0
  20. 01 9月, 2009 1 次提交
  21. 07 7月, 2009 2 次提交
  22. 01 7月, 2009 2 次提交
    • A
      e1000: return PCI_ERS_RESULT_DISCONNECT on permanent error · eab63302
      Andre Detsch 提交于
      PCI drivers that implement the io_error_detected callback
      should return PCI_ERS_RESULT_DISCONNECT if the state
      passed in is pci_channel_io_perm_failure.  This state is
      not checked in many of the network drivers.
      
      The patch fixes the omission in the e1000 driver.
      
      Based on Mike Mason's similar patch for e1000e.
      Signed-off-by: NAndre Detsch <adetsch@br.ibm.com>
      CC: Mike Mason <mmlnx@us.ibm.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eab63302
    • J
      e1000: fix unmap bug · 679be3ba
      Jesse Brandeburg 提交于
      as reported by kerneloops.org
      
      [  121.781161] ------------[ cut here ]------------
      [  121.781171] WARNING: at lib/dma-debug.c:793 check_unmap+0x14e/0x577()
      [  121.781173] Hardware name: S5520HC
      [  121.781177] e1000 0000:0a:00.0: DMA-API: device driver tries to free DMA
      memory it has not allocated [device address=0x00000001d688b0fa] [size=1522
      bytes]
      [  121.781180] Modules linked in: e1000 mdio  dca [last unloaded: ixgbe]
      [  121.781187] Pid: 4793, comm: bash Tainted: P 2.6.30-master-06161113 #3
      [  121.781190] Call Trace:
      [  121.781195]  [<ffffffff8123056f>] ? check_unmap+0x14e/0x577
      [  121.781201]  [<ffffffff81057a19>] warn_slowpath_common+0x77/0x8f
      [  121.781205]  [<ffffffff81057ae1>] warn_slowpath_fmt+0x9f/0xa1
      [  121.781212]  [<ffffffff81477ce2>] ? _spin_lock_irqsave+0x3f/0x49
      [  121.781216]  [<ffffffff8122fa97>] ? get_hash_bucket+0x28/0x33
      [  121.781220]  [<ffffffff8123056f>] check_unmap+0x14e/0x577
      [  121.781225]  [<ffffffff810e4f48>] ? check_bytes_and_report+0x38/0xcb
      [  121.781230]  [<ffffffff81230bbf>] debug_dma_unmap_page+0x80/0x92
      [  121.781234]  [<ffffffff8122e549>] ? unmap_single+0x1a/0x4e
      [  121.781239]  [<ffffffff813901e1>] ? __kfree_skb+0x74/0x78
      [  121.781250]  [<ffffffffa00662ef>] pci_unmap_single+0x64/0x6d [e1000]
      [  121.781259]  [<ffffffffa0066344>] e1000_clean_rx_ring+0x4c/0xbf [e1000]
      [  121.781268]  [<ffffffffa00663df>] e1000_clean_all_rx_rings+0x28/0x36 [e1000]
      [  121.781277]  [<ffffffffa0067464>] e1000_down+0x138/0x141 [e1000]
      [  121.781286]  [<ffffffffa00681c2>] __e1000_shutdown+0x6b/0x198 [e1000]
      [  121.781296]  [<ffffffffa0068405>] e1000_suspend+0x17/0x50 [e1000]
      [  121.781301]  [<ffffffff81237665>] pci_legacy_suspend+0x3b/0xbe
      [  121.781305]  [<ffffffff81237bc6>] pci_pm_suspend+0x3e/0xf1
      [  121.781310]  [<ffffffff812eaf1c>] pm_op+0x57/0xde
      [  121.781314]  [<ffffffff812eb444>] dpm_suspend_start+0x31e/0x470
      [  121.781319]  [<ffffffff810877da>] suspend_devices_and_enter+0x3e/0x1a2
      [  121.781323]  [<ffffffff81087a0f>] enter_state+0xd1/0x127
      [  121.781327]  [<ffffffff8108717a>] state_store+0xa7/0xc9
      [  121.781332]  [<ffffffff81221843>] kobj_attr_store+0x17/0x19
      [  121.781336]  [<ffffffff8113c01e>] sysfs_write_file+0xe5/0x121
      [  121.781341]  [<ffffffff810ed165>] vfs_write+0xab/0x105
      [  121.781344]  [<ffffffff810ed279>] sys_write+0x47/0x6d
      [  121.781349]  [<ffffffff81027aab>] system_call_fastpath+0x16/0x1b
      [  121.781352] ---[ end trace 97bacaaac2ed7786 ]---
      
      Fix is to correctly zero out internal ->dma value when unmapping
      and make sure never to unmap unless there specifically was a mapping done.
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      679be3ba
  23. 18 6月, 2009 1 次提交
    • J
      net: group address list and its count · 31278e71
      Jiri Pirko 提交于
      This patch is inspired by patch recently posted by Johannes Berg. Basically what
      my patch does is to group list and a count of addresses into newly introduced
      structure netdev_hw_addr_list. This brings us two benefits:
      1) struct net_device becames a bit nicer.
      2) in the future there will be a possibility to operate with lists independently
         on netdevices (with exporting right functions).
      I wanted to introduce this patch before I'll post a multicast lists conversion.
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      
       drivers/net/bnx2.c              |    4 +-
       drivers/net/e1000/e1000_main.c  |    4 +-
       drivers/net/ixgbe/ixgbe_main.c  |    6 +-
       drivers/net/mv643xx_eth.c       |    2 +-
       drivers/net/niu.c               |    4 +-
       drivers/net/virtio_net.c        |   10 ++--
       drivers/s390/net/qeth_l2_main.c |    2 +-
       include/linux/netdevice.h       |   17 +++--
       net/core/dev.c                  |  130 ++++++++++++++++++--------------------
       9 files changed, 89 insertions(+), 90 deletions(-)
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31278e71