1. 13 4月, 2018 1 次提交
    • N
      ibmvnic: Handle all login error conditions · 64d92aa2
      Nathan Fontenot 提交于
      There is a bug in handling the possible return codes from sending the
      login CRQ. The current code treats any non-success return value,
      minus failure to send the crq and a timeout waiting for a login response,
      as a need to re-send the login CRQ. This can put the drive in an
      infinite loop of trying to login when getting return values other
      that a partial success such as a return code of aborted. For these
      scenarios the login will not ever succeed at this point and the
      driver would need to be reset again.
      
      To resolve this loop trying to login is updated to only retry the
      login if the driver gets a return code of a partial success. Other
      return codes are treated as an error and the driver returns an error
      from ibmvnic_login().
      
      To avoid infinite looping in the partial success return cases, the
      number of retries is capped at the maximum number of supported
      queues. This value was chosen because the driver does a renegotiation
      of capabilities which sets the number of queues possible and allows
      the driver to attempt a login for possible value for the number
      of queues supported.
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      64d92aa2
  2. 09 4月, 2018 1 次提交
    • T
      ibmvnic: Fix failover case for non-redundant configuration · 5a18e1e0
      Thomas Falcon 提交于
      There is a failover case for a non-redundant pseries VNIC
      configuration that was not being handled properly. The current
      implementation assumes that the driver will always have a redandant
      device to communicate with following a failover notification. There
      are cases, however, when a non-redundant configuration can receive
      a failover request. If that happens, the driver should wait until
      it receives a signal that the device is ready for operation.
      
      The driver is agnostic of its backing hardware configuration,
      so this fix necessarily affects all device failover management.
      The driver needs to wait until it receives a signal that the device
      is ready for resetting. A flag is introduced to track this intermediary
      state where the driver is waiting for an active device.
      Signed-off-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a18e1e0
  3. 18 3月, 2018 3 次提交
  4. 23 2月, 2018 1 次提交
  5. 22 2月, 2018 1 次提交
  6. 21 2月, 2018 1 次提交
  7. 23 1月, 2018 1 次提交
  8. 20 12月, 2017 2 次提交
  9. 14 11月, 2017 1 次提交
  10. 11 11月, 2017 1 次提交
  11. 27 10月, 2017 2 次提交
  12. 19 10月, 2017 1 次提交
  13. 04 8月, 2017 1 次提交
  14. 22 6月, 2017 2 次提交
  15. 27 5月, 2017 3 次提交
  16. 03 5月, 2017 2 次提交
  17. 25 4月, 2017 2 次提交
  18. 22 4月, 2017 3 次提交
  19. 31 3月, 2017 1 次提交
  20. 28 3月, 2017 1 次提交
  21. 22 3月, 2017 1 次提交
  22. 08 3月, 2017 1 次提交
    • T
      ibmvnic: Fix overflowing firmware/hardware TX queue · 142c0ac4
      Thomas Falcon 提交于
      Use a counter to track the number of outstanding transmissions sent
      that have not received completions. If the counter reaches the maximum
      number of queue entries, stop transmissions on that queue. As we receive
      more completions from firmware, wake the queue once the counter reaches
      an acceptable level.
      
      This patch prevents hardware/firmware TX queue from filling up and
      and generating errors.  Since incorporating this fix, internal testing
      has reported that these firmware errors have stopped.
      Signed-off-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      142c0ac4
  23. 20 2月, 2017 3 次提交
  24. 30 10月, 2016 3 次提交
  25. 19 10月, 2016 1 次提交