[Bug 201313] pm80xx mpi_ssp_completion 1883:SAS Address of IO Failure Drive:

https://bugzilla.kernel.org/show_bug.cgi?id=201313 --- Comment #1 from MasterCATZ (masterc...@hotmail.com) --- pm80xx mpi_ssp_completion 1874:sas IO status 0x24 [ 708.424035] pm80xx mpi_ssp_completion 1883:SAS Address of IO Failure Drive:500605ba00b9cca2 [ 708.424241] sd 1:0:8:0: Power-on or

[Bug 201313] New: pm80xx mpi_ssp_completion 1883:SAS Address of IO Failure Drive:

https://bugzilla.kernel.org/show_bug.cgi?id=201313 Bug ID: 201313 Summary: pm80xx mpi_ssp_completion 1883:SAS Address of IO Failure Drive: Product: IO/Storage Version: 2.5 Kernel Version: 4.18.11-041811-generic

[PATCH 0/3] sd: Rely on the driver core for asynchronous probing

Hello Martin, During the 2018 edition of LSF/MM there was a session about increasing SCSI disk probing concurrency. This patch series implements what has been proposed during that session, namely: - Make sure that the driver core is aware of asynchronous SCSI LUN probing. - Avoid unnecessary

[PATCH 3/3] __device_release_driver(): Do not wait for asynchronous probing

Since __device_release_driver() is called with the device lock held and since the same device lock is obtained by the functions that perform asynchronous probing (driver_attach_async() and __device_attach_async_helper()), asynchronous probing is already serialized against

[PATCH 1/3] sd: Rely on the driver core for asynchronous probing

As explained during the LSF/MM session about increasing SCSI disk probing concurrency, the problems with the current probing approach are as follows: - The driver core is unaware of asynchronous SCSI LUN probing. wait_for_device_probe() waits for all asynchronous probes except asynchronous

[PATCH 2/3] sd: Inline sd_probe_part2()

This patch does not change any functionality. Signed-off-by: Bart Van Assche Cc: Lee Duncan Cc: Hannes Reinecke Cc: Luis R. Rodriguez Cc: Johannes Thumshirn Cc: Christoph Hellwig Cc: Greg Kroah-Hartman --- drivers/scsi/sd.c | 101 -- 1 file

Looking for some help understanding error handling

I'm working on LLDD for a SAS/SATA host adapter, and trying to understand how the system handles link loss and recovery. Say I have a device that gets recognized and attached as sd 12:0:4:0, at /dev/sdb. The drive goes offline temporarily, then comes back online. When it does, it comes back as