1. 23 5月, 2016 4 次提交
  2. 20 5月, 2016 2 次提交
  3. 16 5月, 2016 2 次提交
    • D
      ibft: Expose iBFT acpi header via sysfs · b3c8eb50
      David Bond 提交于
      Some ethernet adapter vendors are supplying products which support optional
      (payed license) features. On some adapters this includes a hardware iscsi
      initiator.  The same adapters in a normal (no extra licenses) mode of
      operation can be used as a software iscsi initiator.  In addition, software
      iscsi boot initiators are becoming a standard part of many vendors uefi
      implementations.  This is creating difficulties during early boot/install
      determining the proper configuration method for these adapters when they
      are used as a boot device.
      
      The attached patch creates sysfs entries to expose information from the
      acpi header of the ibft table.  This information allows for a method to
      easily determining if an ibft table was created by a ethernet card's
      firmware or the system uefi/bios.  In the case of a hardware initiator this
      information in combination with the pci vendor and device id can be used
      to ascertain any vendor specific behaviors that need to be accommodated.
      Reviewed-by: NLee Duncan <lduncan@suse.com>
      Signed-off-by: NDavid Bond <dbond@suse.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      b3c8eb50
    • H
      iscsi_ibft: Add prefix-len attr and display netmask · 9a99425f
      Hannes Reinecke 提交于
      The iBFT table only specifies a prefix length, not a netmask.
      And the netmask is pretty much pointless for IPv6.
      So introduce a new attribute 'prefix-len'.
      
      Some older user-space code might rely on the netmask attribute
      being present, so we should always display it.
      
      Changes from v1:
       - Combined two patches into one
      
      Changes from v2:
       - Cleaned up/corrected wording for patch description
      Signed-off-by: NHannes Reinecke <hare@suse.de>
      Signed-off-by: NLee Duncan <lduncan@suse.com>
      Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad@kernel.org>
      9a99425f
  4. 12 5月, 2016 7 次提交
  5. 11 5月, 2016 8 次提交
  6. 10 5月, 2016 5 次提交
  7. 06 5月, 2016 2 次提交
    • A
      megaraid_sas: Downgrade two success messages to info · 13f30771
      Andy Lutomirski 提交于
      I actually read the error messages in my logs, and successful
      initialization is not an error.
      
      Arguably these log lines could be deleted entirely.
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Reviewed-by: NHannes Reinicke <hare@suse.de>
      Acked-by: NSumit Saxena <sumit.saxena@broadcom.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      13f30771
    • M
      cxlflash: Fix to resolve dead-lock during EEH recovery · 635f6b08
      Manoj N. Kumar 提交于
      When a cxlflash adapter goes into EEH recovery and multiple processes
      (each having established its own context) are active, the EEH recovery
      can hang if the processes attempt to recover in parallel. The symptom
      logged after a couple of minutes is:
      
      INFO: task eehd:48 blocked for more than 120 seconds.
      Not tainted 4.5.0-491-26f710d+ #1
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      eehd            0    48      2
      Call Trace:
      __switch_to+0x2f0/0x410
      __schedule+0x300/0x980
      schedule+0x48/0xc0
      rwsem_down_write_failed+0x294/0x410
      down_write+0x88/0xb0
      cxlflash_pci_error_detected+0x100/0x1c0 [cxlflash]
      cxl_vphb_error_detected+0x88/0x110 [cxl]
      cxl_pci_error_detected+0xb0/0x1d0 [cxl]
      eeh_report_error+0xbc/0x130
      eeh_pe_dev_traverse+0x94/0x160
      eeh_handle_normal_event+0x17c/0x450
      eeh_handle_event+0x184/0x370
      eeh_event_handler+0x1c8/0x1d0
      kthread+0x110/0x130
      ret_from_kernel_thread+0x5c/0xa4
      INFO: task blockio:33215 blocked for more than 120 seconds.
      
      Not tainted 4.5.0-491-26f710d+ #1
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      blockio         0 33215  33213
      Call Trace:
      0x1 (unreliable)
      __switch_to+0x2f0/0x410
      __schedule+0x300/0x980
      schedule+0x48/0xc0
      rwsem_down_read_failed+0x124/0x1d0
      down_read+0x68/0x80
      cxlflash_ioctl+0x70/0x6f0 [cxlflash]
      scsi_ioctl+0x3b0/0x4c0
      sg_ioctl+0x960/0x1010
      do_vfs_ioctl+0xd8/0x8c0
      SyS_ioctl+0xd4/0xf0
      system_call+0x38/0xb4
      INFO: task eehd:48 blocked for more than 120 seconds.
      
      The hang is because of a 3 way dead-lock:
      
      Process A holds the recovery mutex, and waits for eehd to complete.
      Process B holds the semaphore and waits for the recovery mutex.
      eehd waits for semaphore.
      
      The fix is to have Process B above release the semaphore before
      attempting to acquire the recovery mutex. This will allow
      eehd to proceed to completion.
      Signed-off-by: NManoj N. Kumar <manoj@linux.vnet.ibm.com>
      Reviewed-by: NMatthew R. Ochs <mrochs@linux.vnet.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      635f6b08
  8. 04 5月, 2016 2 次提交
  9. 01 5月, 2016 2 次提交
  10. 30 4月, 2016 6 次提交