1. 30 May, 2008 1 commit
  2. 27 May, 2008 2 commits
    • Brian King's avatar
      [SCSI] ibmvscsi: Non SCSI error status fixup · ca61668b
      Brian King authored
      Some versions of the Virtual I/O Server on Power
      return 0x99 in the non-SCSI error status field as success,
      rather than 0. This fixes the ibmvscsi driver to treat this
      response as success.
      Signed-off-by: default avatarBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      ca61668b
    • Michael Reed's avatar
      [SCSI] fusion mpt: fix target missing after resetting external raid · 7ba2db5f
      Michael Reed authored
      Following a hard reset of a SAS raid, one of the raid targets is occasionally
      missing.  I tracked this down to a pretty obscure little bug.
      
      The LSI fusion drivers for SAS and Fibre Channel both use their respective
      transport layers.  Those transport layers increment the target number
      assigned to new targets.
      
      The routine __scsi_scan_target uses the "this_id" element of the Scsi_Host
      structure to avoid scanning the scsi host adapter.  Both fusion drivers set
      "this_id" from a value returned in a firmware PortFacts response.  For my
      particular test case (SAS) the firmware id assigned to the initiator was
      173.  After enough raid resets to cause the raid targets to go and come a
      sufficient number of times, the id assigned by the transport to a raid
      target would match the id assigned by the host adapter to the "this_id"
      field, resulting in that target not being scanned.
      
      Fix by not assigning this_id and not checking it in slave_configure. 
      Signed-off-by: default avatarMichael Reed <mdr@sgi.com>
      Acked-by: default avatar"Moore, Eric" <Eric.Moore@lsi.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      7ba2db5f
  3. 23 May, 2008 1 commit
    • James Bottomley's avatar
      [SCSI] fix intermittent oops in scsi_bus_uevent · 1f42ea7b
      James Bottomley authored
      Reported-by: default avatarSitsofe Wheeler <sitsofe@yahoo.com>
      > BUG: unable to handle kernel paging request at e6f17fac
      > IP: [<c02604d6>] scsi_bus_uevent+0x1/0x17
      > *pde = 2714b163 *pte = 26f17160
      > Oops: 0000 [#1] DEBUG_PAGEALLOC
      > last sysfs file:
      >
      > Pid:  1, comm: swapper Not tainted (2.6.26-rc2-next-20080516skw #30)
      > EIP: 0060:[<c02604d6>] EFLAGS: 00010282 CPU: 0
      > EIP is at scsi_bus_uevent+0x1/0x17
      > EAX: e6f18014 EBX: e6f18014 ECX: c02604d5 EDX: e7173000
      > ESI: e7173000 EDI: e7173000 EBP: e7851ca0 ESP: e7851c90
      >  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      
      The problem is caused by:
      
      commit b0ed4336
      Author: Hannes Reinecke <hare@suse.de>
      Date:   Tue Mar 18 14:32:28 2008 +0100
      
          [SCSI] add scsi_host and scsi_target to scsi_bus
      
      which added scsi_bus_type to the struct scsi_target device.  This
      causes both the scsi_device and scsi_target to fire scsi_bus_uevents.
      However, the actualy scsi_bus_uevent() call assumes blindly that it's
      a struct scsi_device.  Check for this and return immediately if it
      isn't.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      1f42ea7b
  4. 15 May, 2008 36 commits