1. 05 Feb, 2016 3 commits
    • Martin K. Petersen's avatar
      block/sd: Return -EREMOTEIO when WRITE SAME and DISCARD are disabled · 0fb5b1fb
      Martin K. Petersen authored
      When a storage device rejects a WRITE SAME command we will disable write
      same functionality for the device and return -EREMOTEIO to the block
      layer. -EREMOTEIO will in turn prevent DM from retrying the I/O and/or
      failing the path.
      
      Yiwen Jiang discovered a small race where WRITE SAME requests issued
      simultaneously would cause -EIO to be returned. This happened because
      any requests being prepared after WRITE SAME had been disabled for the
      device caused us to return BLKPREP_KILL. The latter caused the block
      layer to return -EIO upon completion.
      
      To overcome this we introduce BLKPREP_INVALID which indicates that this
      is an invalid request for the device. blk_peek_request() is modified to
      return -EREMOTEIO in that case.
      Reported-by: default avatarYiwen Jiang <jiangyiwen@huawei.com>
      Suggested-by: default avatarMike Snitzer <snitzer@redhat.com>
      Reviewed-by: default avatarHannes Reinicke <hare@suse.de>
      Reviewed-by: default avatarEwan Milne <emilne@redhat.com>
      Reviewed-by: default avatarYiwen Jiang <jiangyiwen@huawei.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      0fb5b1fb
    • Mika Westerberg's avatar
      SCSI: Add Marvell Console to VPD blacklist · 82c43310
      Mika Westerberg authored
      I have a Marvell 88SE9230 SATA Controller that has some sort of
      integrated console SCSI device attached to one of the ports.
      
        ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
        ata14.00: ATAPI: MARVELL VIRTUALL, 1.09, max UDMA/66
        ata14.00: configured for UDMA/66
        scsi 13:0:0:0: Processor         Marvell  Console 1.01 PQ: 0 ANSI: 5
      
      Sending it VPD INQUIRY command seem to always fail with following error:
      
        ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
        ata14.00: irq_stat 0x40000001
        ata14.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 2 dma 16640 in
                  Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation)
        ata14: hard resetting link
      
      This has been minor annoyance (only error printed on dmesg) until commit
      09e2b0b1 ("scsi: rescan VPD attributes") added call to scsi_attach_vpd()
      in scsi_rescan_device(). The commit causes the system to splat out
      following errors continuously without ever reaching the UI:
      
        ata14.00: configured for UDMA/66
        ata14: EH complete
        ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
        ata14.00: irq_stat 0x40000001
        ata14.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 6 dma 16640 in
                  Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation)
        ata14: hard resetting link
        ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
        ata14.00: configured for UDMA/66
        ata14: EH complete
        ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
        ata14.00: irq_stat 0x40000001
        ata14.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 7 dma 16640 in
                  Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation)
      
      Without in-depth understanding of SCSI layer and the Marvell controller,
      I suspect this happens because when the link goes down (because of an
      error) we schedule scsi_rescan_device() which again fails to read VPD
      data... ad infinitum.
      
      Since VPD data cannot be read from the device anyway we prevent the SCSI
      layer from even trying by blacklisting the device. This gets away the
      error and the system starts up normally.
      
      [mkp: Widened the match to all revisions of this device]
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Reported-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Reported-by: default avatarAlexander Duyck <alexander.duyck@gmail.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      82c43310
    • Hannes Reinecke's avatar
      scsi_dh_rdac: always retry MODE SELECT on command lock violation · d2d06d4f
      Hannes Reinecke authored
      If MODE SELECT returns with sense '05/91/36' (command lock violation)
      it should always be retried without counting the number of retries.
      During an HBA upgrade or similar circumstances one might see a flood
      of MODE SELECT command from various HBAs, which will easily trigger
      the sense code and exceed the retry count.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      d2d06d4f
  2. 29 Jan, 2016 2 commits
  3. 27 Jan, 2016 2 commits
  4. 21 Jan, 2016 3 commits
  5. 20 Jan, 2016 24 commits
  6. 19 Jan, 2016 6 commits