1. 26 1月, 2018 1 次提交
  2. 24 1月, 2018 1 次提交
  3. 22 1月, 2018 1 次提交
  4. 18 1月, 2018 1 次提交
  5. 11 1月, 2018 3 次提交
  6. 09 12月, 2017 1 次提交
  7. 02 11月, 2017 1 次提交
  8. 01 11月, 2017 4 次提交
  9. 21 10月, 2017 2 次提交
  10. 20 10月, 2017 2 次提交
  11. 15 10月, 2017 2 次提交
  12. 04 10月, 2017 1 次提交
  13. 26 9月, 2017 1 次提交
  14. 23 9月, 2017 3 次提交
  15. 22 9月, 2017 1 次提交
  16. 21 8月, 2017 1 次提交
  17. 19 8月, 2017 1 次提交
  18. 15 8月, 2017 1 次提交
  19. 12 8月, 2017 1 次提交
  20. 08 8月, 2017 4 次提交
  21. 21 7月, 2017 1 次提交
  22. 12 7月, 2017 1 次提交
    • G
      cxgb4: fix BUG() on interrupt deallocating path of ULD · 6a146f3a
      Guilherme G. Piccoli 提交于
      Since the introduction of ULD (Upper-Layer Drivers), the MSI-X
      deallocating path changed in cxgb4: the driver frees the interrupts
      of ULD when unregistering it or on shutdown PCI handler.
      
      Problem is that if a MSI-X is not freed before deallocated in the PCI
      layer, it will trigger a BUG() due to still "alive" interrupt being
      tentatively quiesced.
      
      The below trace was observed when doing a simple unbind of Chelsio's
      adapter PCI function, like:
        "echo 001e:80:00.4 > /sys/bus/pci/drivers/cxgb4/unbind"
      
      Trace:
      
        kernel BUG at drivers/pci/msi.c:352!
        Oops: Exception in kernel mode, sig: 5 [#1]
        ...
        NIP [c0000000005a5e60] free_msi_irqs+0xa0/0x250
        LR [c0000000005a5e50] free_msi_irqs+0x90/0x250
        Call Trace:
        [c0000000005a5e50] free_msi_irqs+0x90/0x250 (unreliable)
        [c0000000005a72c4] pci_disable_msix+0x124/0x180
        [d000000011e06708] disable_msi+0x88/0xb0 [cxgb4]
        [d000000011e06948] free_some_resources+0xa8/0x160 [cxgb4]
        [d000000011e06d60] remove_one+0x170/0x3c0 [cxgb4]
        [c00000000058a910] pci_device_remove+0x70/0x110
        [c00000000064ef04] device_release_driver_internal+0x1f4/0x2c0
        ...
      
      This patch fixes the issue by refactoring the shutdown path of ULD on
      cxgb4 driver, by properly freeing and disabling interrupts on PCI
      remove handler too.
      
      Fixes: 0fbc81b3 ("Allocate resources dynamically for all cxgb4 ULD's")
      Reported-by: NHarsha Thyagaraja <hathyaga@in.ibm.com>
      Signed-off-by: NGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6a146f3a
  23. 05 7月, 2017 2 次提交
  24. 24 6月, 2017 1 次提交
    • A
      cxgb4: Update T6 Buffer Group and Channel Mappings · 193c4c28
      Arjun Vynipadath 提交于
      We were using t4_get_mps_bg_map() for both t4_get_port_stats()
      to determine which MPS Buffer Groups to report statistics on for a given
      Port, and also for t4_sge_alloc_rxq() to provide a TP Ingress Channel
      Congestion Map.  For T4/T5 these are actually the same values (because they
      are ~somewhat~ related), but for T6 they should return different values
      (T6 has Port 0 associated with MPS Buffer Group 0 (with MPS Buffer Group 1
      silently cascading off) and Port 1 is associated with MPS Buffer Group 2
      (with 3 cascading off)).
      
      Based on the original work by Casey Leedom <leedom@chelsio.com>
      Signed-off-by: NArjun Vynipadath <arjun@chelsio.com>
      Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      193c4c28
  25. 19 6月, 2017 2 次提交
    • R
      cxgb4: notify uP to route ctrlq compl to rdma rspq · dec6b331
      Raju Rangoju 提交于
      During the module initialisation there is a possible race
      (basically race between uld and lld) where neither the uld
      nor lld notifies the uP about where to route the ctrl queue
      completions. LLD skips notifying uP as the rdma queues were
      not created by then (will leave it to ULD to notify the uP).
      As the ULD comes up, it also skips notifying the uP as the
      flag FULL_INIT_DONE is not set yet (ULD assumes that the
      interface is not up yet).
      
      Consequently, this race between uld and lld leaves uP
      unnotified about where to send the ctrl queue completions
      to, leading to iwarp RI_RES WR failure.
      
      Here is the race:
      
      CPU 0                                   CPU1
      
      - allocates nic rx queus
      - t4_sge_alloc_ctrl_txq()
      (if rdma rsp queues exists,
      tell uP to route ctrl queue
      compl to rdma rspq)
                                      - acquires the mutex_lock
                                      - allocates rdma response queues
                                      - if FULL_INIT_DONE set,
                                        tell uP to route ctrl queue compl
                                        to rdma rspq
                                      - relinquishes mutex_lock
      - acquires the mutex_lock
      - enable_rx()
      - set FULL_INIT_DONE
      - relinquishes mutex_lock
      
      This patch fixes the above issue.
      
      Fixes: e7519f99('cxgb4: avoid enabling napi twice to the same queue')
      Signed-off-by: NRaju Rangoju <rajur@chelsio.com>
      Acked-by: NSteve Wise <swise@opengridcomputing.com>
      CC: Stable <stable@vger.kernel.org> # 4.9+
      Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dec6b331
    • R
      cxgb4: notify uP to route ctrlq compl to rdma rspq · 91060381
      Raju Rangoju 提交于
      During the module initialisation there is a possible race
      (basically race between uld and lld) where neither the uld
      nor lld notifies the uP about where to route the ctrl queue
      completions. LLD skips notifying uP as the rdma queues were
      not created by then (will leave it to ULD to notify the uP).
      As the ULD comes up, it also skips notifying the uP as the
      flag FULL_INIT_DONE is not set yet (ULD assumes that the
      interface is not up yet).
      
      Consequently, this race between uld and lld leaves uP
      unnotified about where to send the ctrl queue completions
      to, leading to iwarp RI_RES WR failure.
      
      Here is the race:
      
      CPU 0                                   CPU1
      
      - allocates nic rx queus
      - t4_sge_alloc_ctrl_txq()
      (if rdma rsp queues exists,
      tell uP to route ctrl queue
      compl to rdma rspq)
                                      - acquires the mutex_lock
                                      - allocates rdma response queues
                                      - if FULL_INIT_DONE set,
                                        tell uP to route ctrl queue compl
                                        to rdma rspq
                                      - relinquishes mutex_lock
      - acquires the mutex_lock
      - enable_rx()
      - set FULL_INIT_DONE
      - relinquishes mutex_lock
      
      This patch fixes the above issue.
      
      Fixes: e7519f99('cxgb4: avoid enabling napi twice to the same queue')
      Signed-off-by: NRaju Rangoju <rajur@chelsio.com>
      Acked-by: NSteve Wise <swise@opengridcomputing.com>
      CC: Stable <stable@vger.kernel.org> # 4.9+
      Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      91060381