10:0:10:0: [sdb] FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[ 7726.531075] sd 10:0:10:0: [sdb] Sense Key : Not Ready [current]
[ 7726.531079] sd 10:0:10:0: [sdb] Add. Sense: Logical unit not ready, sanitize
in progress
[ 7726.531082] sd 10:0:10:0: [sdb] CDB: Read(10) 28 00 00 00 00 04 00 00 04 00
[ 7726.531084] blk_update_request: I/O error, dev sdb, sector 4
[ 7726.531087] Buffer I/O error on dev sdb, logical block 1, async page read
[ 7726.535232] Dev sdb: unable to read RDB block 0
[ 7726.539416] sdb: unable to read partition table
Thanks,
Mahesh
-Original Message-
From: Douglas Gilbert [mailto:dgilb...@interlog.com]
Sent: Tuesday, April 3, 2018 9:53 PM
To: Mahesh Rajashekhara <mahesh.rajashekh...@microsemi.com>;
linux-scsi@vger.kernel.org
Cc: Vasanthalakshmi Tharmarajan <vasanthalakshmi.t...@microsemi.com>; Ajish
Koshy <ajish.ko...@microsemi.com>
Subject: Re: Regarding SCSI SANITIZE command support
EXTERNAL EMAIL
On 2018-04-02 07:10 AM, Mahesh Rajashekhara wrote:
> Hello,
>
> I am RAID HBA driver engineer here at Microsemi. We are working on linux
> driver development for Microsemi SAS/SATA RAID HBA controllers.
>
> As per our understanding, while a drive is processing the SANITIZE command:
> - The drive should still be exposed to the OS.
> - The drive will fail all commands other than REQUEST SENSE
Not sure that the drive should ever knowingly fail INQUIRY and REPORT LUNS.
That is to allow a discovery process to occur. In the INQUIRY response the
peripheral qualifier should be 000b by my reading.
Go look at sbc4r15.pdf, specifically clause 4.11.2 to see all the commands that
should be responded to during a SANITIZE (there are
9 of them).
> When we initiate SCSI SANITIZE operation on disk drive, from the OS
> dmesg, we could see that continuous SCSI READ (10) commands have been sent by
> the OS upper layer drivers and drive reports ASC: 04 ASCQ: 1B "LOGICAL UNIT
> NOT READY, SANITIZE IN PROGRESS". Since the sanitize operation is in
> progress, the drive will fail the commands.
> Although, OS could see drive is sanitizing, we are not sure why does OS upper
> layer driver is sending SCSI READ (10).
>
> During the OS boot, if the drive is sanitizing, OS boot is taking very long
> time and call trace issue has been occurred.
>
> It would be of great help if you could shed some light on this issue.
>
> Snippet of dmesg:
>
> [ 202.659196] sd 0:0:11:0: [sdm] CDB: Read(10) 28 00 00 00 00 00 00 00 01 00
> [ 202.659198] blk_update_request: I/O error, dev sdm, sector 0
> [ 202.659201] Buffer I/O error on dev sdm, logical block 0, async page read
> [ 202.659294] sd 0:0:11:0: [sdm] FAILED Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [ 202.659299] sd 0:0:11:0: [sdm] Sense Key : Not Ready [current]
> [ 202.659303] sd 0:0:11:0: [sdm] Add. Sense: Logical unit not ready,
> sanitize in progress
> [ 202.659308] sd 0:0:11:0: [sdm] CDB: Read(10) 28 00 00 00 00 00 00 00 01 00
> [ 202.659311] blk_update_request: I/O error, dev sdm, sector 0
> [ 202.659314] Buffer I/O error on dev sdm, logical block 0, async page read
> [ 202.659322] sdm: unable to read partition table
> [ 202.659633] sd 0:0:11:0: [sdm] FAILED Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [ 202.659638] sd 0:0:11:0: [sdm] Sense Key : Not Ready [current]
> [ 202.659641] sd 0:0:11:0: [sdm] Add. Sense: Logical unit not ready,
> sanitize in progress
> [ 202.659645] sd 0:0:11:0: [sdm] CDB: Read(10) 28 00 00 00 00 00 00 00 01 00
> [ 202.659648] blk_update_request: I/O error, dev sdm, sector 0
> [ 202.660621] sd 0:0:11:0: [sdm] Spinning up disk...
> [ 204.067155] Buffer I/O error on dev sdm, logical block 488378624, async
> page read
> [ 204.122152] SGI XFS with ACLs, security attributes, no debug enabled
> [ 204.123494] XFS (dm-0): Mounting V5 Filesystem
> [ 204.289817] XFS (dm-0): Ending clean mount
> [ 240.069283] INFO: task systemd-udevd:251 blocked for more than 120
> seconds.
> [ 240.069289] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message
> [ 203.661324] .
> [ 240.069293] systemd-udevd D
> [ 240.069296] c00c3580 0 251 1 0x0004
> [ 240.069301] 88007e0e7d18 0082 88007e0ceeb0
> 88007e0e7fd8
> [ 240.069306] 88007e0e7fd8 88007e0e7fd8 88007e0ceeb0
>
> [ 240.069311] c00c35d0 0001
> c00c3580
> [ 240.069316] Call Trace:
> [ 240.069328] [] schedule+0x29/0x70
> [ 240.069334] []
> async_synchronize_cookie_domain+0x85/0x150
> [ 240.069340] [] ? wake_up_atomic_t+0x30/0x30
> [ 240.069346] [] async_synchronize_full+0x17/0x20
> [ 240.
