linux-toradex.git/drivers/scsi/cxlflash, branch v4.4.89

scsi: cxlflash: Improve EEH recovery time

2017-05-08T05:46:02+00:00

commit 05dab43230fdc0d14ca885b473a2740fe017ecb1 upstream.

When an EEH occurs during device initialization, the port timeout logic
can cause excessive delays as MMIO reads will fail. Depending on where
they are experienced, these delays can lead to a prolonged reset,
causing an unnecessary triggering of other timeout logic in the SCSI
stack or user applications.

To expedite recovery, the port timeout logic is updated to decay the
timeout at a much faster rate when in the presence of a likely EEH
frozen event.

Signed-off-by: Matthew R. Ochs 
Acked-by: Uma Krishnan 
Signed-off-by: Martin K. Petersen 
Cc: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman

scsi: cxlflash: Fix to avoid EEH and host reset collisions

2017-05-08T05:46:01+00:00

commit 1d3324c382b1a617eb567e3650dcb51f22dfec9a upstream.

The EEH reset handler is ignorant to the current state of the driver
when processing a frozen event and initiating a device reset. This can
be an issue if an EEH event occurs while a user or stack initiated reset
is executing. More specifically, if an EEH occurs while the SCSI host
reset handler is active, the reset initiated by the EEH thread will
likely collide with the host reset thread. This can leave the device in
an inconsistent state, or worse, cause a system crash.

As a remedy, the EEH handler is updated to evaluate the device state and
take appropriate action (proceed, wait, or disconnect host). The host
reset handler is also updated to handle situations where an EEH occurred
during a host reset. In such situations, the host reset handler will
delay reporting back a success to give the EEH reset an opportunity to
complete.

Signed-off-by: Matthew R. Ochs 
Acked-by: Uma Krishnan 
Signed-off-by: Martin K. Petersen 
Cc: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman

scsi: cxlflash: Scan host only after the port is ready for I/O

2017-05-08T05:46:01+00:00

commit bbbfae962b7c221237c0f92547ee0c83f7204747 upstream.

When a port link is established, the AFU sends a 'link up' interrupt.
After the link is up, corresponding initialization steps are performed
on the card. Following that, when the card is ready for I/O, the AFU
sends 'login succeeded' interrupt. Today, cxlflash invokes
scsi_scan_host() upon receipt of both interrupts.

SCSI commands sent to the port prior to the 'login succeeded' interrupt
will fail with 'port not available' error. This is not desirable.
Moreover, when async_scan is active for the host, subsequent scan calls
are terminated with error. Due to this, the scsi_scan_host() call
performed after 'login succeeded' interrupt could portentially return
error and the devices may not be scanned properly.

To avoid this problem, scsi_scan_host() should be called only after the
'login succeeded' interrupt.

Signed-off-by: Uma Krishnan 
Acked-by: Matthew R. Ochs 
Signed-off-by: Martin K. Petersen 
Cc: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman

cxlflash: Increase cmd_per_lun for better throughput

2017-03-26T10:13:17+00:00

commit 83430833b4d4a9c9b23964babbeb1f36450f8136 upstream.

With the current value of cmd_per_lun at 16, the throughput
over a single adapter is limited to around 150kIOPS.

Increase the value of cmd_per_lun to 256 to improve
throughput. With this change a single adapter is able to
attain close to the maximum throughput (380kIOPS).
Also change the number of RRQ entries that can be queued.

Signed-off-by: Manoj N. Kumar 
Acked-by: Matthew R. Ochs 
Reviewed-by: Uma Krishnan 
Signed-off-by: Martin K. Petersen 
Cc: Sumit Semwal 
Signed-off-by: Greg Kroah-Hartman

cxlflash: Move to exponential back-off when cmd_room is not available

2016-09-15T06:27:50+00:00

[ Upstream commit ea76543127da32dec28af0a13ea1b06625fc085e ]

While profiling the cxlflash_queuecommand() path under a heavy load it
was found that number of retries to find cmd_room was fairly high.

There are two problems with the current back-off:
a) It starts with a udelay of 0
b) It backs-off linearly

Tried several approaches (a higher multiple 10*n, 100*n, as well as n^2,
2^n) and found that the exponential back-off(2^n) approach had the least
overall cost. Cost as being defined as overall time spent waiting.

The fix is to change the linear back-off to an exponential back-off.
This solution also takes care of the problem with the initial
delay (starts with 1 usec).

Signed-off-by: Manoj N. Kumar 
Acked-by: Matthew R. Ochs 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Uma Krishnan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

cxlflash: Fix to avoid virtual LUN failover failure

2016-09-15T06:27:49+00:00

[ Upstream commit d5e26bb1d812ba74f29b6bcbc88c3dbfb3eed824 ]

Applications which use virtual LUN's that are backed by a physical LUN
over both adapter ports may experience an I/O failure in the event of a
link loss (e.g. cable pull).

Virtual LUNs may be accessed through one or both ports of the adapter.
This access is encoded in the translation entries that comprise the
virtual LUN and used by the AFU for load-balancing I/O and handling
failover scenarios. In a link loss scenario, even though the AFU is able
to maintain connectivity to the LUN, it is up to the application to
retry the failed I/O. When applications are unaware of the virtual LUN's
underlying topology, they are unable to make a sound decision of when to
retry an I/O and therefore are forced to make their reaction to a failed
I/O absolute. The result is either a failure to retry I/O or increased
latency for scenarios where a retry is pointless.

To remedy this scenario, provide feedback back to the application on
virtual LUN creation as to which ports the LUN may be accessed. LUN's
spanning both ports are candidates for a retry in a presence of an I/O
failure.

Signed-off-by: Matthew R. Ochs 
Acked-by: Manoj Kumar 
Reviewed-by: Uma Krishnan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

cxlflash: Fix to escalate LINK_RESET also on port 1

2016-09-15T06:27:49+00:00

[ Upstream commit a9be294ecb3b9dc82b15625631b153f871181d16 ]

The original fix to escalate a 'login timed out' error to a LINK_RESET
was only made for one of the two ports on the card. This fix resolves
the same issue for the second port (port 1).

Signed-off-by: Manoj N. Kumar 
Acked-by: Matthew R. Ochs 
Reviewed-by: Uma Krishnan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

cxlflash: Fix to resolve dead-lock during EEH recovery

2016-09-15T06:27:47+00:00

[ Upstream commit 635f6b0893cff193a1774881ebb1e4a4b9a7fead ]

When a cxlflash adapter goes into EEH recovery and multiple processes
(each having established its own context) are active, the EEH recovery
can hang if the processes attempt to recover in parallel. The symptom
logged after a couple of minutes is:

INFO: task eehd:48 blocked for more than 120 seconds.
Not tainted 4.5.0-491-26f710d+ #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
eehd            0    48      2
Call Trace:
__switch_to+0x2f0/0x410
__schedule+0x300/0x980
schedule+0x48/0xc0
rwsem_down_write_failed+0x294/0x410
down_write+0x88/0xb0
cxlflash_pci_error_detected+0x100/0x1c0 [cxlflash]
cxl_vphb_error_detected+0x88/0x110 [cxl]
cxl_pci_error_detected+0xb0/0x1d0 [cxl]
eeh_report_error+0xbc/0x130
eeh_pe_dev_traverse+0x94/0x160
eeh_handle_normal_event+0x17c/0x450
eeh_handle_event+0x184/0x370
eeh_event_handler+0x1c8/0x1d0
kthread+0x110/0x130
ret_from_kernel_thread+0x5c/0xa4
INFO: task blockio:33215 blocked for more than 120 seconds.

Not tainted 4.5.0-491-26f710d+ #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
blockio         0 33215  33213
Call Trace:
0x1 (unreliable)
__switch_to+0x2f0/0x410
__schedule+0x300/0x980
schedule+0x48/0xc0
rwsem_down_read_failed+0x124/0x1d0
down_read+0x68/0x80
cxlflash_ioctl+0x70/0x6f0 [cxlflash]
scsi_ioctl+0x3b0/0x4c0
sg_ioctl+0x960/0x1010
do_vfs_ioctl+0xd8/0x8c0
SyS_ioctl+0xd4/0xf0
system_call+0x38/0xb4
INFO: task eehd:48 blocked for more than 120 seconds.

The hang is because of a 3 way dead-lock:

Process A holds the recovery mutex, and waits for eehd to complete.
Process B holds the semaphore and waits for the recovery mutex.
eehd waits for semaphore.

The fix is to have Process B above release the semaphore before
attempting to acquire the recovery mutex. This will allow
eehd to proceed to completion.

Signed-off-by: Manoj N. Kumar 
Reviewed-by: Matthew R. Ochs 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

cxlflash: Fix to avoid unnecessary scan with internal LUNs

2016-09-15T06:27:46+00:00

[ Upstream commit 603ecce95f4817074a724a889cd88c3c8210f933 ]

When switching to the internal LUN defined on the
IBM CXL flash adapter, there is an unnecessary
scan occurring on the second port. This scan leads
to the following extra lines in the log:

Dec 17 10:09:00 tul83p1 kernel: [ 3708.561134] cxlflash 0008:00:00.0: cxlflash_queuecommand: (scp=c0000000fc1f0f00) 11/1/0/0 cdb=(A0000000-00000000-10000000-00000000)
Dec 17 10:09:00 tul83p1 kernel: [ 3708.561147] process_cmd_err: cmd failed afu_rc=32 scsi_rc=0 fc_rc=0 afu_extra=0xE, scsi_extra=0x0, fc_extra=0x0

By definition, both of the internal LUNs are on the first port/channel.

When the lun_mode is switched to internal LUN the
same value for host->max_channel is retained. This
causes an unnecessary scan over the second port/channel.

This fix alters the host->max_channel to 0 (1 port), if internal
LUNs are configured and switches it back to 1 (2 ports) while
going back to external LUNs.

Signed-off-by: Manoj N. Kumar 
Acked-by: Matthew R. Ochs 
Reviewed-by: Uma Krishnan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

cxlflash: Enable device id for future IBM CXL adapter

2016-09-15T06:27:41+00:00

[ Upstream commit a2746fb16e41b7c8f02aa4d2605ecce97abbebbd ]

This drop enables a future card with a device id of 0x0600 to be
recognized by the cxlflash driver.

As per the design, the Accelerator Function Unit (AFU) for this new IBM
CXL Flash Adapter retains the same host interface as the previous
generation. For the early prototypes of the new card, the driver with
this change behaves exactly as the driver prior to this behaved with the
earlier generation card. Therefore, no card specific programming has
been added. These card specific changes can be staged in later if
needed.

Signed-off-by: Manoj N. Kumar 
Acked-by: Matthew R. Ochs 
Reviewed-by: Andrew Donnellan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman