1. 26 Jan, 2009 1 commit
  2. 21 Jan, 2009 2 commits
  3. 19 Jan, 2009 1 commit
  4. 11 Jan, 2009 1 commit
    • Roland Dreier's avatar
      cxgb3: Keep LRO off if disabled when interface is down · 47fd23fe
      Roland Dreier authored
      I have a system with a Chelsio adapter (driven by cxgb3) whose ports are
      part of a Linux bridge.  Recently I updated the kernel and discovered
      that things stopped working because cxgb3 was doing LRO on packets that
      were passed into the bridge code for forwarding.  (Incidentally, this
      problem manifested itself in a strange way that made debugging a bit
      interesting -- for some reason, the skb_warn_if_lro() check in bridge
      didn't trigger and these LROed packets were forwarded out a forcedeth
      interface, and caused the forcedeth transmit path to get stuck)
      
      This is because cxgb3 has no way of keeping state for the LRO flag until
      the interface is brought up, so if the bridging code disables LRO while
      the interface is down, then cxgb3_up() will just reenable LRO, and on my
      Debian system at least, the init scripts add interfaces to a bridge
      before bringing the interfaces up.
      
      Fix this by keeping track of each interface's LRO state in cxgb3 so that
      when bridge disables LRO, it stays disabled in cxgb3_up() when the
      interface is brought up.  I did this by changing the rx_csum_offload
      flag into a pair of bit flags; the effect of this on the rx_eth() fast
      path is miniscule enough that it should be fine (eg on x86, a cmpb
      instruction becomes a testb instruction).
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      47fd23fe
  5. 26 Dec, 2008 2 commits
  6. 18 Dec, 2008 1 commit
  7. 16 Dec, 2008 2 commits
  8. 28 Nov, 2008 1 commit
    • Roland Dreier's avatar
      cxgb3: Fix sparse warning and micro-optimize is_pure_response() · c5419e6f
      Roland Dreier authored
      The function is_pure_response() does "ntohl(var) & const" and then
      essentially just tests whether the result is 0 or not; this can be done
      more efficiently by computing "var & htonl(const)" instead and doing the
      byte swap at compile time instead of run time.
      
      This change slightly shrinks the compiled code; eg on x86-64 we save a
      couple of bswapl instructions:
      
      add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-8 (-8)
      function                                     old     new   delta
      t3_sge_intr_msix_napi                        544     536      -8
      
      and this also has the pleasant side effect of fixing a sparse warning:
      
          drivers/net/cxgb3/sge.c:2313:15: warning: restricted degrades to integer
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5419e6f
  9. 26 Nov, 2008 3 commits
  10. 20 Nov, 2008 1 commit
  11. 19 Nov, 2008 1 commit
  12. 12 Nov, 2008 1 commit
    • Steve Wise's avatar
      RDMA/cxgb3: Fix deadlock in iw_cxgb3 (hang when configuring interface) · b3e123cf
      Steve Wise authored
      When the iw_cxgb3 module's cxgb3_client "add" func gets called by the
      cxgb3 module, the iwarp driver ends up calling the ethtool ops
      get_drvinfo function in cxgb3 to get the fw version and other info.
      Currently the iwarp driver grabs the rtnl lock around this down call
      to serialize.  As of 2.6.27 or so, things changed such that the rtnl
      lock is held around the call to the netdev driver open function.  Also
      the cxgb3_client "add" function doesn't get called if the device is
      down.
      
      So, if you load cxgb3, then load iw_cxgb3, then ifconfig up the
      device, the iw_cxgb3 add func gets called with the rtnl_lock held.  If
      you load cxgb3, ifconfig up the device, then load iw_cxgb3, the add
      func gets called without the rtnl_lock held.  The former causes the
      deadlock, the latter does not.
      
      In addition, there are iw_cxgb3 sysfs handlers that also can call down
      into cxgb3 to gather the fw and hw versions.  These can be called
      concurrently on different processors and at any time.  Thus we need to
      push this serialization down in the cxgb3 driver get_drvinfo func.
      
      The fix is to remove rtnl lock usage, and use a per-device lock in cxgb3.
      Signed-off-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Acked-by: default avatarDivy Le Ray <divy@chelsio.com>
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      b3e123cf
  13. 11 Nov, 2008 3 commits
    • Steve Wise's avatar
      RDMA/cxgb3: deadlock in iw_cxgb3 can cause hang when configuring interface. · cf3760da
      Steve Wise authored
      When the iw_cxgb3 module's cxgb3_client "add" func gets called by the
      cxgb3 module, the iwarp driver ends up calling the ethtool ops get_drvinfo
      function in cxgb3 to get the fw version and other info.  Currently the
      iwarp driver grabs the rtnl lock around this down call to serialize.
      As of 2.6.27 or so, things changed such that the rtnl lock is held around
      the call to the netdev driver open function.  Also the cxgb3_client "add"
      function doesn't get called if the device is down.
      
      So, if you load cxgb3, then load iw_cxgb3, then ifconfig up the device,
      the iw_cxgb3 add func gets called with the rtnl_lock held.   If you
      load cxgb3, ifconfig up the device, then load iw_cxgb3, the add func
      gets called without the rtnl_lock held.  The former causes the deadlock,
      the latter does not.
      
      In addition, there are iw_cxgb3 sysfs handlers that also can call
      down into cxgb3 to gather the fw and hw versions.  These can be called
      concurrently on different processors and at any time.  Thus we need to
      push this serialization down in the cxgb3 driver get_drvinfo func.
      
      The fix is to remove rtnl lock usage, and use a per-device lock in cxgb3.
      Signed-off-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      cf3760da
    • Divy Le Ray's avatar
      cxgb3 - Limit multiqueue setting to msi-x · f9ee3882
      Divy Le Ray authored
      Allow multiqueue setting in MSI-X mode only
      Signed-off-by: default avatarDivy Le Ray <divy@chelsio.com>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      f9ee3882
    • Divy Le Ray's avatar
      cxgb3 - eeprom read fixes · 9f64306b
      Divy Le Ray authored
      Protect against invalid phy entries in the eeprom.
      Extend eeprom access timeout.
      Signed-off-by: default avatarDivy Le Ray <divy@chelsio.com>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      9f64306b
  14. 03 Nov, 2008 1 commit
  15. 30 Oct, 2008 1 commit
  16. 22 Oct, 2008 1 commit
    • Roland Dreier's avatar
      cxgb3: Fix kernel crash caused by uninitialized l2t_entry.arpq · 6d329af9
      Roland Dreier authored
      Commit 147e70e6 ("cxgb3: Use SKB list interfaces instead of home-grown
      implementation.") causes a crash in t3_l2t_send_slow() when an iWARP
      connection request is received.  This is because the new l2t_entry.arpq
      skb queue is never initialized, and therefore trying to add an skb to
      it causes a NULL dereference.  With the old code there was no need to
      initialize the queues because the l2t_entry structures were zeroed,
      and the code used NULL to mean empty.
      
      Fix this by adding __skb_queue_head_init() when all the l2t_entry
      structures get allocated.
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      6d329af9
  17. 13 Oct, 2008 2 commits
  18. 08 Oct, 2008 9 commits
  19. 24 Sep, 2008 2 commits
  20. 22 Sep, 2008 1 commit
  21. 29 Jul, 2008 1 commit
  22. 26 Jul, 2008 1 commit
    • FUJITA Tomonori's avatar
      dma-mapping: add the device argument to dma_mapping_error() · 8d8bb39b
      FUJITA Tomonori authored
      Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
      architecture does:
      
      This enables us to cleanly fix the Calgary IOMMU issue that some devices
      are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423).
      
      I think that per-device dma_mapping_ops support would be also helpful for
      KVM people to support PCI passthrough but Andi thinks that this makes it
      difficult to support the PCI passthrough (see the above thread).  So I
      CC'ed this to KVM camp.  Comments are appreciated.
      
      A pointer to dma_mapping_ops to struct dev_archdata is added.  If the
      pointer is non NULL, DMA operations in asm/dma-mapping.h use it.  If it's
      NULL, the system-wide dma_ops pointer is used as before.
      
      If it's useful for KVM people, I plan to implement a mechanism to register
      a hook called when a new pci (or dma capable) device is created (it works
      with hot plugging).  It enables IOMMUs to set up an appropriate
      dma_mapping_ops per device.
      
      The major obstacle is that dma_mapping_error doesn't take a pointer to the
      device unlike other DMA operations.  So x86 can't have dma_mapping_ops per
      device.  Note all the POWER IOMMUs use the same dma_mapping_error function
      so this is not a problem for POWER but x86 IOMMUs use different
      dma_mapping_error functions.
      
      The first patch adds the device argument to dma_mapping_error.  The patch
      is trivial but large since it touches lots of drivers and dma-mapping.h in
      all the architecture.
      
      This patch:
      
      dma_mapping_error() doesn't take a pointer to the device unlike other DMA
      operations.  So we can't have dma_mapping_ops per device.
      
      Note that POWER already has dma_mapping_ops per device but all the POWER
      IOMMUs use the same dma_mapping_error function.  x86 IOMMUs use device
      argument.
      
      [akpm@linux-foundation.org: fix sge]
      [akpm@linux-foundation.org: fix svc_rdma]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix bnx2x]
      [akpm@linux-foundation.org: fix s2io]
      [akpm@linux-foundation.org: fix pasemi_mac]
      [akpm@linux-foundation.org: fix sdhci]
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix sparc]
      [akpm@linux-foundation.org: fix ibmvscsi]
      Signed-off-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Muli Ben-Yehuda <muli@il.ibm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Avi Kivity <avi@qumranet.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8d8bb39b
  23. 15 Jul, 2008 1 commit
    • Steve Wise's avatar
      RDMA/cxgb3: Fixes for zero STag · 4ab928f6
      Steve Wise authored
      Handling the zero STag in receive work request requires some extra
      logic in the driver:
      
       - Only set the QP_PRIV bit for kernel mode QPs.
      
      - Add a zero STag build function for recv wrs. The uP needs a PBL
        allocated and passed down in the recv WR so it can construct a HW
        PBL for the zero STag S/G entries.  Note: we need to place a few
        restrictions on zero STag usage because of this:
      
        1) all SGEs in a recv WR must either be zero STag or not.  No mixing.
      
        2) an individual SGE length cannot exceed 128MB for a zero-stag SGE.
           This should be OK since it's not really practical to allocate
           such a large chunk of pinned contiguous DMA mapped memory.
      
      - Add an optimized non-zero-STag recv wr format for kernel users.
        This is needed to optimize both zero and non-zero STag cracking in
        the recv path for kernel users.
      
       - Remove the iwch_ prefix from the static build functions.
      
       - Bump required FW version.
      Signed-off-by: default avatarSteve Wise <swise@opengridcomputing.com>
      4ab928f6