1. 22 6月, 2018 2 次提交
  2. 20 6月, 2018 2 次提交
  3. 05 6月, 2018 2 次提交
  4. 10 5月, 2018 5 次提交
    • S
      IB/{hfi1, rdmavt, qib}: Implement CQ completion vector support · 5d18ee67
      Sebastian Sanchez 提交于
      Currently the driver doesn't support completion vectors. These
      are used to indicate which sets of CQs should be grouped together
      into the same vector. A vector is a CQ processing thread that
      runs on a specific CPU.
      
      If an application has several CQs bound to different completion
      vectors, and each completion vector runs on different CPUs, then
      the completion queue workload is balanced. This helps scale as more
      nodes are used.
      
      Implement CQ completion vector support using a global workqueue
      where a CQ entry is queued to the CPU corresponding to the CQ's
      completion vector. Since the workqueue is global, it's guaranteed
      to always be there when queueing CQ entries; Therefore, the RCU
      locking for cq->rdi->worker in the hot path is superfluous.
      
      Each completion vector is assigned to a different CPU. The number of
      completion vectors available is computed by taking the number of
      online, physical CPUs from the local NUMA node and subtracting the
      CPUs used for kernel receive queues and the general interrupt.
      Special use cases:
      
        * If there are no CPUs left for completion vectors, the same CPU
          for the general interrupt is used; Therefore, there would only
          be one completion vector available.
      
        * For multi-HFI systems, the number of completion vectors available
          for each device is the total number of completion vectors in
          the local NUMA node divided by the number of devices in the same
          NUMA node. If there's a division remainder, the first device to
          get initialized gets an extra completion vector.
      
      Upon a CQ creation, an invalid completion vector could be specified.
      Handle it as follows:
      
        * If the completion vector is less than 0, set it to 0.
      
        * Set the completion vector to the result of the passed completion
          vector moded with the number of device completion vectors
          available.
      Reviewed-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: NSebastian Sanchez <sebastian.sanchez@intel.com>
      Signed-off-by: NDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      5d18ee67
    • K
      IB/Hfi1: Read CCE Revision register to verify the device is responsive · c872a1f9
      Kamenee Arumugam 提交于
      When Hfi1 device is unresponsive, reading the RcvArrayCnt register
      will return all 1's. This value is then used to remap chip's RcvArray.
      The incorrect all ones value used in remapping RcvArray
      will cause warn on as shown by trace below:
      
      [<ffffffff81685eac>] dump_stack+0x19/0x1b
      [<ffffffff81085820>] warn_slowpath_common+0x70/0xb0
      [<ffffffff810858bc>] warn_slowpath_fmt+0x5c/0x80
      [<ffffffff81065c29>] __ioremap_caller+0x279/0x320
      [<ffffffff8142873c>] ? _dev_info+0x6c/0x90
      [<ffffffffa021d155>] ? hfi1_pcie_ddinit+0x1d5/0x330 [hfi1]
      [<ffffffff81065d62>] ioremap_wc+0x32/0x40
      [<ffffffffa021d155>] hfi1_pcie_ddinit+0x1d5/0x330 [hfi1]
      [<ffffffffa0204851>] hfi1_init_dd+0x1d1/0x2440 [hfi1]
      [<ffffffff813503dc>] ? pci_write_config_word+0x1c/0x20
      
      Read CCE revision register first to verify that WFR device is
      responsive. If the read return "all ones", bail out from init
      and fail the driver load.
      Reviewed-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Reviewed-by: NMichael J. Ruhl <michael.j.ruhl@intel.com>
      Signed-off-by: NKamenee Arumugam <kamenee.arumugam@intel.com>
      Signed-off-by: NDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      c872a1f9
    • M
      IB/hfi1: Rework fault injection machinery · a74d5307
      Mitko Haralanov 提交于
      The packet fault injection code present in the HFI1 driver had some
      issues which not only fragment the code but also created user
      confusion. Furthermore, it suffered from the following issues:
      
        1. The fault_packet method only worked for received packets. This
           meant that the only fault injection mode available for sent
           packets is fault_opcode, which did not allow for random packet
           drops on all egressing packets.
        2. The mask available for the fault_opcode mode did not really work
           due to the fact that the opcode values are not bits in a bitmask but
           rather sequential integer values. Creating a opcode/mask pair that
           would successfully capture a set of packets was nearly impossible.
        3. The code was fragmented and used too many debugfs entries to
           operate and control. This was confusing to users.
        4. It did not allow filtering fault injection on a per direction basis -
           egress vs. ingress.
      
      In order to improve or fix the above issues, the following changes have
      been made:
      
         1. The fault injection methods have been combined into a single fault
            injection facility. As such, the fault injection has been plugged
            into both the send and receive code paths. Regardless of method used
            the fault injection will operate on both egress and ingress packets.
         2. The type of fault injection - by packet or by opcode - is now controlled
            by changing the boolean value of the file "opcode_mode". When the value
            is set to True, fault injection is done by opcode. Otherwise, by
            packet.
         2. The masking ability has been removed in favor of a bitmap that holds
            opcodes of interest (one bit per opcode, a total of 256 bits). This
            works in tandem with the "opcode_mode" value. When the value of
            "opcode_mode" is False, this bitmap is ignored. When the value is
            True, the bitmap lists all opcodes to be considered for fault injection.
            By default, the bitmap is empty. When the user wants to filter by opcode,
            the user sets the corresponding bit in the bitmap by echo'ing the bit
            position into the 'opcodes' file. This gets around the issue that the set
            of opcodes does not lend itself to effective masks and allow for extremely
            fine-grained filtering by opcode.
         4. fault_packet and fault_opcode methods have been combined. Hence, there
            is only one debugfs directory controlling the entire operation of the
            fault injection machinery. This reduces the number of debugfs entries
            and provides a more unified user experience.
         5. A new control files - "direction" - is provided to allow the user to
            control the direction of packets, which are subject to fault injection.
         6. A new control file - "skip_usec" - is added that would allow the user
            to specify a "timeout" during which no fault injection will occur.
      
      In addition, the following bug fixes have been applied:
      
         1. The fault injection code has been split into its own header and source
            files. This was done to better organize the code and support conditional
            compilation without littering the code with #ifdef's.
         2. The method by which the TX PIO packets were being marked for drop
            conflicted with the way send contexts were being setup. As a result,
            the send context was repeatedly being reset.
         3. The fault injection only makes sense when the user can control it
            through the debugfs entries. However, a kernel configuration can
            enable fault injection but keep fault injection debugfs entries
            disabled. Therefore, it makes sense that the HFI fault injection
            code depends on both.
         4. Error suppression did not take into account the method by which PIO
            packets were being dropped. Therefore, even with error suppression
            turned on, errors would still be displayed to the screen. A larger
            enough packet drop percentage would case the kernel to crash because
            the driver would be stuck printing errors.
      Reviewed-by: NDennis Dalessandro <dennis.dalessandro@intel.com>
      Reviewed-by: NDon Hiatt <don.hiatt@intel.com>
      Reviewed-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: NMitko Haralanov <mitko.haralanov@intel.com>
      Signed-off-by: NDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      a74d5307
    • M
      IB/hfi1: Return correct value for device state · e4607073
      Michael J. Ruhl 提交于
      The driver_pstate() function is used to map internal driver state
      information to externally defined states.
      
      The VERIFY_CAP and GOING_UP states are config/training states, but
      the mapping routing returns the POLLING value.
      
      Update the return values for VERIFY_CAP and GOING_UP to return the
      correct value: TRAINING.
      Reviewed-by: NSebastian Sanchez <sebastian.sanchez@intel.com>
      Signed-off-by: NMichael J. Ruhl <michael.j.ruhl@intel.com>
      Signed-off-by: NDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      e4607073
    • S
      IB/hfi1: Prevent LNI hang when LCB can't obtain lanes · 254361c1
      Sebastian Sanchez 提交于
      When the LCB isn't able to get any lanes operational on the
      first transition into mission mode, the link transfer active
      never happens and the LNI stays in the polling state indefinitely.
      
      Reset LCB upon receiving an 8051 interrupt for LCB to try to obtain
      lanes with firmware version 1.25.0 or later. Also, update the LCB
      reset value in other parts of the code with a macro defined to make
      the code more maintainable and rename functions with the link_width
      label to link_mode to reflect the fact that those functions set and
      read link related data not just the link width.
      Reviewed-by: NMichael J. Ruhl <michael.j.ruhl@intel.com>
      Reviewed-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: NSebastian Sanchez <sebastian.sanchez@intel.com>
      Signed-off-by: NDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      254361c1
  5. 09 5月, 2018 1 次提交
    • M
      IB/hfi1: Use after free race condition in send context error path · f9e76ca3
      Michael J. Ruhl 提交于
      A pio send egress error can occur when the PSM library attempts to
      to send a bad packet.  That issue is still being investigated.
      
      The pio error interrupt handler then attempts to progress the recovery
      of the errored pio send context.
      
      Code inspection reveals that the handling lacks the necessary locking
      if that recovery interleaves with a PSM close of the "context" object
      contains the pio send context.
      
      The lack of the locking can cause the recovery to access the already
      freed pio send context object and incorrectly deduce that the pio
      send context is actually a kernel pio send context as shown by the
      NULL deref stack below:
      
      [<ffffffff8143d78c>] _dev_info+0x6c/0x90
      [<ffffffffc0613230>] sc_restart+0x70/0x1f0 [hfi1]
      [<ffffffff816ab124>] ? __schedule+0x424/0x9b0
      [<ffffffffc06133c5>] sc_halted+0x15/0x20 [hfi1]
      [<ffffffff810aa3ba>] process_one_work+0x17a/0x440
      [<ffffffff810ab086>] worker_thread+0x126/0x3c0
      [<ffffffff810aaf60>] ? manage_workers.isra.24+0x2a0/0x2a0
      [<ffffffff810b252f>] kthread+0xcf/0xe0
      [<ffffffff810b2460>] ? insert_kthread_work+0x40/0x40
      [<ffffffff816b8798>] ret_from_fork+0x58/0x90
      [<ffffffff810b2460>] ? insert_kthread_work+0x40/0x40
      
      This is the best case scenario and other scenarios can corrupt the
      already freed memory.
      
      Fix by adding the necessary locking in the pio send context error
      handler.
      
      Cc: <stable@vger.kernel.org> # 4.9.x
      Reviewed-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Reviewed-by: NDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: NMichael J. Ruhl <michael.j.ruhl@intel.com>
      Signed-off-by: NDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      f9e76ca3
  6. 02 2月, 2018 2 次提交
  7. 06 1月, 2018 2 次提交
  8. 14 11月, 2017 3 次提交
  9. 31 10月, 2017 4 次提交
  10. 18 10月, 2017 2 次提交
  11. 05 10月, 2017 3 次提交
  12. 27 9月, 2017 7 次提交
  13. 29 8月, 2017 1 次提交
  14. 23 8月, 2017 4 次提交