1. 26 4月, 2016 1 次提交
  2. 24 2月, 2016 6 次提交
  3. 07 1月, 2016 2 次提交
  4. 14 11月, 2015 1 次提交
  5. 10 11月, 2015 28 次提交
  6. 27 8月, 2015 2 次提交
    • D
      hpsa: fix rmmod issues · 2d041306
      Don Brace 提交于
      The driver is calling hpsa_shutdown before calling scsi_remove_host.
      hpsa_shutdown is disabling interrupts.
      
      scsi_remove_host can trigger I/O operations, such as
      SYNCHRONIZE CACHE when multipath is enabled which hang the system.
      
      Call scsi_remove_host before calling hpsa_shutdown.
      Reviewed-by: NKevin Barnett <kevin.barnett@pmcs.com>
      Reviewed-by: NScott Teel <scott.teel@pmcs.com>
      Reviewed-by: NTomas Henzl <thenzl@redhat.com>
      Signed-off-by: NDon Brace <don.brace@pmcs.com>
      Signed-off-by: NJames Bottomley <JBottomley@Odin.com>
      2d041306
    • S
      hpsa: fix issues with multilun devices · 9a4178b7
      shane.seymour 提交于
      A regression was introduced into the hpsa driver a while back so
      non-zero LUNs of multi-LUN devices may no longer be presented via
      a SAS based Smart Array. I have not done a bisection to discover
      the change that caused it.
      
      The CISS firmware specification (available on sourceforge)
      defines an 8 byte lunid that describes devices that the Smart
      Array can see/present to the system. The current code in the hpsa
      driver attempts to find matches for non-zero LUNs with LUN 0 for
      a bus/target by zeroing out byte 4 of the lunid and find a match.
      
      This method is sufficient for SCSI based Smart Arrays because
      byte 5 is always 0. For SAS based Smart arrays byte 5 of the
      lunid contains the path number for a multipath device and
      either one or two bits (the documentation does not define how
      many bits are used but it appears it may be one only) that
      indicate if the given path number in byte 5 must always be
      used to access that device. Byte 5 may not always be zero.
      
      The following are lunids (spaces added for clarity) for a
      MSL2024 single drive library connected via a H241 Smart Array:
      
      00 00 00 00 01 00 00 01 (changer)
      00 00 00 00 00 80 00 01 (tape)
      
      In the 4th byte (counting from 0) you can see that the tape
      is LUN 0 and the changer is LUN 1. The 0x80 set in the 5th byte
      for the tape drive means the driver should force access to
      path 0 (the library in this case was connected to one path only
      anyway).
      
      After the changes we can see the following in the dmesg output:
      
      scsi 0:3:0:0: RAID              HP       H241             1.18 \
      PQ: 0 ANSI: 5
      scsi 0:2:0:0: Sequential-Access HP       Ultrium 6-SCSI   354W \
      PQ: 0 ANSI: 6
      scsi 0:2:0:1: Medium Changer    HP       MSL G3 Series    8.70 \
      PQ: 0 ANSI: 5
      
      Showing that the changer is correctly identified as LUN 1 of
      bus 2 target 0. Before the change the changer device is not seen.
      Suggested-by: Nshane.seymour <shane.seymour@hp.com>
      Reviewed-by: NKevin Barnett <kevin.barnett@pmcs.com>
      Reviewed-by: NScott Teel <scott.teel@pmcs.com>
      Reviewed-by: NTomas Henzl <thenzl@redhat.com>
      Signed-off-by: NDon Brace <don.brace@pmcs.com>
      Signed-off-by: NJames Bottomley <JBottomley@Odin.com>
      9a4178b7