While testing live partition mobility, we have observed occasional crashes
of the Linux partition. What we've seen is that during the live migration,
for specific configurations with large amounts of memory, slow network
links, and workloads that are changing memory a lot, the partition can end
up being suspended for 30 seconds or longer. This resulted in the following
scenario:
CPU 0 CPU 1
------------------------------- ----------------------------------
scsi_queue_rq migration_store
-> blk_mq_start_request -> rtas_ibm_suspend_me
-> blk_add_timer -> on_each_cpu(rtas_percpu_suspend_me
_______________________________________V
|
V
-> IPI from CPU 1
-> rtas_percpu_suspend_me
-> __rtas_suspend_last_cpu
-- Linux partition suspended for > 30 seconds --
-> for_each_online_cpu(cpu)
plpar_hcall_norets(H_PROD
-> scsi_dispatch_cmd
-> scsi_times_out
-> scsi_abort_command
-> queue_delayed_work
-> ibmvfc_queuecommand_lck
-> ibmvfc_send_event
-> ibmvfc_send_crq
- returns H_CLOSED
<- returns SCSI_MLQUEUE_HOST_BUSY
-> __blk_mq_requeue_request
-> scmd_eh_abort_handler
-> scsi_try_to_abort_cmd
- returns SUCCESS
-> scsi_queue_insert
Normally, the SCMD_STATE_COMPLETE bit would protect against the command
completion and the timeout, but that doesn't work here, since we don't
check that at all in the SCSI_MLQUEUE_HOST_BUSY path.
In this case we end up calling scsi_queue_insert on a request that has
already been queued, or possibly even freed, and we crash.
The patch below simply increases the default I/O timeout to avoid this race
condition. This is also the timeout value that nearly all IBM SAN storage
recommends setting as the default value.
Link: https://lore.kernel.org/r/1610463998-19791-1-git-send-email-brking@linux.vnet.ibm.com
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Kernel stack violation when getting unit_descriptor/wb_buf_alloc_units from
rpmb LUN. The reason is that the unit descriptor length is different per
LU.
The length of Normal LU is 45 while the one of rpmb LU is 35.
int ufshcd_read_desc_param(struct ufs_hba *hba, ...)
{
param_offset=41;
param_size=4;
buff_len=45;
...
buff_len=35 by rpmb LU;
if (is_kmalloc) {
/* Make sure we don't copy more data than available */
if (param_offset + param_size > buff_len)
param_size = buff_len - param_offset;
--> param_size = 250;
memcpy(param_read_buf, &desc_buf[param_offset], param_size);
--> memcpy(param_read_buf, desc_buf+41, 250);
[ 141.868974][ T9174] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: wb_buf_alloc_units_show+0x11c/0x11c
}
}
Link: https://lore.kernel.org/r/20210111095927.1830311-1-jaegeuk@kernel.org
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Some comments in this driver don't comply with the preferred multi-line
comment style, as reported by 'scripts/checkpatch.pl':
WARNING: Block comments use * on subsequent lines
WARNING: Block comments use a trailing */ on a separate line
Fix those comments, along with the (unreported for some reason?) starts of
the multi-line comments not being /* on their own line...
Link: https://lore.kernel.org/r/08c231e5-d86f-9d0b-19ac-ad46fa0c0b58@omprussia.ru
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Added a log message in SATA completion path to capture the status of failed
command. If the status does not match any expected status, another message
will be logged.
On IO failure with known status, the log message will be:
[ 1712.951735] pm80xx0:: mpi_sata_completion 2269: IO failed device_id 16385 status 0x1 tag XX
If the firmware returns unexpected status, a message of the following
format will be logged:
[ 1712.951735] pm80xx0:: mpi_sata_completion XXXX: Unknown status device_id XXXXX status 0xX tag XX
Link: https://lore.kernel.org/r/20210109123849.17098-8-Viswas.G@microchip.com
Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Vishakha Channapattan <vishakhavc@google.com>
Signed-off-by: Viswas G <Viswas.G@microchip.com>
Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: Ashokkumar N <Ashokkumar.N@microchip.com>
Signed-off-by: Radha Ramachandran <radha@google.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In check_fw_ready() we first wait for ILA to come up and then we wait for
RAAE to come up and IOPs and so on. This is a sequential check. Because of
this, ILA image seems to be not ready in the allocated time and so the
driver marks it as "not ready" and then moves on to other FW images.
ILA does become ready eventually, but is not checked again. The driver
concludes that FW is not ready when it actually is.
Instead of sequentially polling each image, we keep polling for all images
to be ready. The timeout for the polling has been set to the sum of what
was used for each individual image.
Link: https://lore.kernel.org/r/20210109123849.17098-7-Viswas.G@microchip.com
Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Bhavesh Jashnani <bjashnani@google.com>
Signed-off-by: Viswas G <Viswas.G@microchip.com>
Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: Ashokkumar N <Ashokkumar.N@microchip.com>
Signed-off-by: Radha Ramachandran <radha@google.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The function pm80xx_get_fatal_dump() has two issues that result in the
fatal dump not being able to complete successfully.
1. Trying to collect fatal_logs from the application fails because we are
not shifting the MEMBASE-II register properly. Once we read 64K region
of data we have to shift the MEMBASE-II register and read the next
chunk. Only then would we be able to get complete data.
2. If a timeout occurs, our application will get stuck.
Link: https://lore.kernel.org/r/20210109123849.17098-6-Viswas.G@microchip.com
Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Viswas G <Viswas.G@microchip.com>
Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: Ashokkumar N <Ashokkumar.N@microchip.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The driver initializes main configuration, general status, inbound queue
and outbound queue table addresses based on a value read from
MSGU_SCRATCH_PAD_0 register.
We should validate these addresses before dereferencing them.
Adds two validations:
1. Check if main configuration table offset lies within the pcibar
mapped
2. Check if first dword of main configuration table reads "PMCS"
There are two calls to init_pci_device_addresses() done during
pm8001_pci_probe() in this sequence:
1. First inside chip_soft_rst, where if init_pci_device_addresses fails we
will go ahead assuming MPI state is not ready and reset the device as
long as bootloader is okay. This gives chance to second call of
init_pci_device_addresses to set up the addresses after reset.
2. The second call is via pm80xx_chip_init, after soft reset is done and
firmware is checked to be ready. Once that is done we are safe to go
ahead and initialize default table values and use them.
Tests:
1. Enabled debugging logs and observed no issues during initialization,
with a controller with no issues:
pm80xx0:: pm8001_setup_msix 1034: pci_alloc_irq_vectors request ret:64 no of intr 64
pm80xx0:: init_pci_device_addresses 917: Scratchpad 0 Offset: 0x2000 value 0x40002000
pm80xx0:: init_pci_device_addresses 925: Scratchpad 0 PCI BAR: 0
pm80xx0:: init_pci_device_addresses 952: VALID main config signature 0x53434d50
pm80xx0:: init_pci_device_addresses 975: GST OFFSET 0xc4
pm80xx0:: init_pci_device_addresses 978: INBND OFFSET 0x20000128
pm80xx0:: init_pci_device_addresses 981: OBND OFFSET 0x24000928
pm80xx0:: init_pci_device_addresses 984: IVT OFFSET 0x8001408
pm80xx0:: init_pci_device_addresses 987: PSPA OFFSET 0x8001608
pm80xx0:: init_pci_device_addresses 991: addr - main cfg (ptrval) general status (ptrval)
pm80xx0:: init_pci_device_addresses 995: addr - inbnd (ptrval) obnd (ptrval)
pm80xx0:: init_pci_device_addresses 999: addr - pspa (ptrval) ivt (ptrval)
pm80xx0:: pm80xx_chip_soft_rst 1446: reset register before write : 0x0
pm80xx0:: pm80xx_chip_soft_rst 1478: reset register after write 0x40
pm80xx0:: pm80xx_chip_soft_rst 1544: SPCv soft reset Complete
pm80xx0:: init_pci_device_addresses 917: Scratchpad 0 Offset: 0x2000 value 0x40002000
pm80xx0:: init_pci_device_addresses 925: Scratchpad 0 PCI BAR: 0
pm80xx0:: init_pci_device_addresses 952: VALID main config signature 0x53434d50
pm80xx0:: init_pci_device_addresses 975: GST OFFSET 0xc4
pm80xx0:: init_pci_device_addresses 978: INBND OFFSET 0x20000128
pm80xx0:: init_pci_device_addresses 981: OBND OFFSET 0x24000928
pm80xx0:: init_pci_device_addresses 984: IVT OFFSET 0x8001408
pm80xx0:: init_pci_device_addresses 987: PSPA OFFSET 0x8001608
pm80xx0:: init_pci_device_addresses 991: addr - main cfg (ptrval) general status (ptrval)
pm80xx0:: init_pci_device_addresses 995: addr - inbnd (ptrval) obnd (ptrval)
pm80xx0:: init_pci_device_addresses 999: addr - pspa (ptrval) ivt (ptrval)
pm80xx0:: pm80xx_chip_init 1329: MPI initialize successful!
2. Tested controller with firmware known to have initialization issue and
observed no crashes with this fix:
pm80xx 0000:01:00.0: pm80xx: driver version 0.1.38
pm80xx 0000:01:00.0: Removing from 1:1 domain
pm80xx 0000:01:00.0: Requesting non-1:1 mappings
pm80xx0:: init_pci_device_addresses 948: BAD main config signature 0x0
pm80xx0:: mpi_uninit_check 1365: Failed to init pci addresses
pm80xx0:: pm80xx_chip_soft_rst 1435: MPI state is not ready scratch:0:8:62a01000:0
pm80xx0:: pm80xx_chip_soft_rst 1518: Firmware is not ready!
pm80xx0:: pm80xx_chip_soft_rst 1532: iButton Feature is not Available!!!
pm80xx0:: pm80xx_chip_init 1301: Firmware is not ready!
pm80xx0:: pm8001_pci_probe 1215: chip_init failed [ret: -16]
pm80xx: probe of 0000:01:00.0 failed with error -16
pm80xx 0000:07:00.0: pm80xx: driver version 0.1.38
pm80xx 0000:07:00.0: Removing from 1:1 domain
pm80xx 0000:07:00.0: Requesting non-1:1 mappings
scsi host6: pm80xx
pm80xx1:: pm8001_setup_sgpio 5568: failed sgpio_req timeout
pm80xx1:: mpi_phy_start_resp 3447: phy start resp status:0x0, phyid:0x0
pm80xx 0000:08:00.0: pm80xx: driver version 0.1.38
pm80xx 0000:08:00.0: Removing from 1:1 domain
pm80xx 0000:08:00.0: Requesting non-1:1 mappings
3. Without this fix we observe crash on the same controller:
pm80xx 0000:01:00.0: pm80xx: driver version 0.1.38
pm80xx 0000:01:00.0: Removing from 1:1 domain
pm80xx 0000:01:00.0: Requesting non-1:1 mappings
[<ffffffffc0451b3b>] pm80xx_chip_soft_rst+0x6b/0x4c0 [pm80xx]
[<ffffffffc043a933>] pm8001_pci_probe+0xa43/0x1630 [pm80xx]
RIP: 0010:pm80xx_chip_soft_rst+0x71/0x4c0 [pm80xx]
[<ffffffffc0451b3b>] ? pm80xx_chip_soft_rst+0x6b/0x4c0 [pm80xx]
[<ffffffffc043a933>] pm8001_pci_probe+0xa43/0x1630 [pm80xx]
pm80xx0:: mpi_uninit_check 1339: TIMEOUT:IBDB value/=2
pm80xx0:: pm80xx_chip_soft_rst 1387: MPI state is not ready scratch:0:8:62a01000:0
pm80xx0:: pm80xx_chip_soft_rst 1470: Firmware is not ready!
pm80xx0:: pm80xx_chip_soft_rst 1484: iButton Feature is not Available!!!
pm80xx0:: pm80xx_chip_init 1266: Firmware is not ready!
pm80xx0:: pm8001_pci_probe 1207: chip_init failed [ret: -16]
pm80xx: probe of 0000:01:00.0 failed with error -16
Link: https://lore.kernel.org/r/20210109123849.17098-4-Viswas.G@microchip.com
Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: akshatzen <akshatzen@google.com>
Signed-off-by: Viswas G <Viswas.G@microchip.com>
Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: Radha Ramachandran <radha@google.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
A race condition exists between the response handler getting called because
of exchange_mgr_reset() (which clears out all the active XIDs) and the
response we get via an interrupt.
Sequence of events:
rport ba0200: Port timeout, state PLOGI
rport ba0200: Port entered PLOGI state from PLOGI state
xid 1052: Exchange timer armed : 20000 msecs xid timer armed here
rport ba0200: Received LOGO request while in state PLOGI
rport ba0200: Delete port
rport ba0200: work event 3
rport ba0200: lld callback ev 3
bnx2fc: rport_event_hdlr: event = 3, port_id = 0xba0200
bnx2fc: ba0200 - rport not created Yet!!
/* Here we reset any outstanding exchanges before
freeing rport using the exch_mgr_reset() */
xid 1052: Exchange timer canceled
/* Here we got two responses for one xid */
xid 1052: invoking resp(), esb 20000000 state 3
xid 1052: invoking resp(), esb 20000000 state 3
xid 1052: fc_rport_plogi_resp() : ep->resp_active 2
xid 1052: fc_rport_plogi_resp() : ep->resp_active 2
Skip the response if the exchange is already completed.
Link: https://lore.kernel.org/r/20201215194731.2326-1-jhasan@marvell.com
Signed-off-by: Javed Hasan <jhasan@marvell.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Current code overestimates the value of max_outstanding_req_per_channel for
Win8 and newer hosts, since vmscsi_size_delta is set to the initial value
of sizeof(vmscsi_win8_extension) rather than zero. This may lead to wrong
decisions when using ring_avail_percent_lowater equals to zero. The
estimate of max_outstanding_req_per_channel is 'exact' for Win7 and older
hosts. A better choice, keeping the algorithm for the estimation simple,
is to err the other way around, i.e., to underestimate for Win7 and older
but to use the exact value for Win8 and newer.
Link: https://lore.kernel.org/r/20201217203321.4539-2-parri.andrea@gmail.com
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org
Suggested-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
While testing recent discovery node rework, several items were seen that
could be done better with respect to the new trace event logic.
1) in the following msg:
kernel: lpfc 0000:44:00.0: start 35 end 35 cnt 0
If cnt is zero in the 1st message, there is no reason to display the
1st message, which is just giving start/end positioning.
Fix by not displaying message if cnt is 0.
2) If the driver is loaded with module log verbosity off, and later a
single NPIV host instance verbosity is enabled via sysfs, it enables
messages on all instances. This is due to the trace log verbosity checks
(lpfc_dmp_dbg) looking at the phba only. It should look at the phba and
the vport.
Fix by enabling a check on both phba and vport.
3) in the following messages:
2904 Firmware Dump Image Present on Adapter
2887 Reset Needed: Attempting Port Recovery...
These messages are not necessary for the trace event log, which is
primarily for discovery.
Fix by changing log level on these 2 messages to LOG_SLI.
Link: https://lore.kernel.org/r/20210104180240.46824-15-jsmart2021@gmail.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Several errors have occurred where the adapter stops or fails but does not
raise the register values for the driver to detect failure. Thus driver is
unaware of the failure. The failure typically results in I/O timeouts, the
I/O timeout handler failing (after several seconds), and the error handler
escalating recovery policy and resulting in more errors. Eventually, the
driver is in a position where things have spiraled and it can't do recovery
because other recovery ops are still outstanding and it becomes unusable.
Resolve the situation by having the I/O timeout handler (actually a els,
SCSI I/O, NVMe ls, or NVMe I/O timeout), in addition to aborting the I/O,
perform a mailbox command and look for a response from the hardware. If
the mailbox command fails, it will mark the adapter offline and then invoke
the adapter reset handler to clean up.
The new I/O timeout test will be limited to a test every 5s. If there are
multiple I/O timeouts concurrently, only the 1st I/O timeout will generate
the mailbox command. Further testing will only occur once a timeout occurs
after a 5s delay from the last mailbox command has expired.
Link: https://lore.kernel.org/r/20210104180240.46824-14-jsmart2021@gmail.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When lpfc is running in NVMET mode and supports the NVME-1 addendum
changes, a LIP on a bound NVME Initiator or lipping the lpfc NVMET's link
resulted in an Oops in lpfc_nvmet_host_release.
The fix requires lpfc NVMET to maintain an additional reference on any node
structure that acts as the hosthandle for the NVMET transport. This
reference get is a one-time addition, is taken prior to the upcall of an
unsolicited LS_REQ, and is released when the NVMET transport releases the
hosthandle during the host_release downcall.
Link: https://lore.kernel.org/r/20210104180240.46824-13-jsmart2021@gmail.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
If a mailbox command times out, the SLI port is deemed in error and the
port is reset. The HBA cleanup is not returning I/Os to the NVMe layer
before the port is unregistered. This is due to the HBA being marked
offline (!SLI_ACTIVE) and cleanup being done by the mailbox timeout handler
rather than an general adapter reset routine. The mailbox timeout handler
mailbox handler only cleaned up SCSI I/Os.
Fix by reworking the mailbox handler to:
- After handling the mailbox error, detect the board is already in
failure (may be due to another error), and leave cleanup to the
other handler.
- If the mailbox command timeout is initial detector of the port error,
continue with the board cleanup and marking the adapter offline
(!SLI_ACTIVE). Remove the SCSI-only I/O cleanup routine. The generic
reset adapter routine that is subsequently invoked, will clean up the
I/Os.
- Have the reset adapter routine flush all NVMe and SCSI I/Os if the
adapter has been marked failed (!SLI_ACTIVE).
- Rework the NVMe I/O terminate routine to take a status code to fail the
I/O with and update so that cleaned up I/O calls the wqe completion
routine. Currently it is bypassing the wqe cleanup and calling the NVMe
I/O completion directly. The wqe completion routine will take care of
data structure and node cleanup then call the NVMe I/O completion
handler.
Link: https://lore.kernel.org/r/20210104180240.46824-11-jsmart2021@gmail.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Target reset is failed by the target as an invalid command.
The Target Reset TMF has been obsoleted in T10 for a while, but continues
to be used. On (newer) devices, the TMF is rejected causing the reset
handler to escalate to adapter resets.
Fix by having Target Reset TMF rejections be translated into a LOGO and
re-PLOGI with the target device. This provides the same semantic action
(although, if the device also supports nvme traffic, it will terminate nvme
traffic as well - but it's still recoverable).
Link: https://lore.kernel.org/r/20210104180240.46824-10-jsmart2021@gmail.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In the lpfc offline routine, called for various reasons such as sysfs
attribute, driver unload, or port error, the driver is calling
__lpfc_cpuhp_remove() to destroy the hot plug data. If the offline routine
is called while the driver is in the process of being unloaded, a request
using lpfc_cpuhp_remove() is also made from lpfc_sli4_hba_unset(). The
cpuhp elements are no longer valid when the second removal request is made.
Fix by only calling the cpuhp removal once when the adapter is in the
process of unloading.
Link: https://lore.kernel.org/r/20210104180240.46824-8-jsmart2021@gmail.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When lpfc generates a GEN_REQUEST wqe for the nvme LS (such as Create
Association), the timeout is set to R_A_TOV without regard to the timeout
value supplied by the nvme-fc transport. The driver should be setting the
timeout to the value passed into the routine. Additionally the caller
should be setting the timeout value to the value in the ls request set by
the nvme transport. Instead, it unconditionally is setting it to a driver
defined value. So the driver actually overrode the value twice.
Fix by using the timeout provided to the routine, and for the caller, set
the timeout to the ls request timeout value.
Link: https://lore.kernel.org/r/20210104180240.46824-6-jsmart2021@gmail.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The driver's management of the fabric controller (aka pseudo-scsi
initiator) node in SLI3 mode is causing this crash. The crash occurs
because of a node reference imbalance that frees the fabric controller node
while devloss is outstanding from the SCSI transport. This is triggered by
an odd behavior where the switch reacts to a rejected RDP request with a
PLOGI and nothing else, not even a LOGO. The driver ACKS the PLOGI and
after successfully registering the RPI, incorrectly registers the fabric
controller node because it has the NLP_FC4_FCP flag still set from the
fabric controller PRLI. If a LIP is issued, the driver attempts to cleanup
on Link Up and ends up executing too many puts.
Fix by detecting the fabric node type and clearing out the nodes internal
flags that triggered a SCSI transport registration and subsequence dev_loss
event. The driver cannot count on any persistence from fabric controller
nodes.
Link: https://lore.kernel.org/r/20210104180240.46824-5-jsmart2021@gmail.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Testing with target ports coming and going, the driver eventually reached a
state where it no longer discovered the target. When the driver has issued
a PRLI and receives a PRLI from the target, it is not properly updating the
node's initiator/target role flags. Thus, when a subsequent RSCN is
received for a target loss, the driver mis-identifies the target as an
initiator and does not initiate LUN scanning.
Fix by always refreshing the ndlp with the latest PRLI state information
whenever a PRLI is processed. Also clear the ndlp flags when processing a
PLOGI so that there is no carry over through a re-login.
Link: https://lore.kernel.org/r/20210104180240.46824-4-jsmart2021@gmail.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
A very long time ago, there was a feature: auto sli mode. It gave the user
the ability to auto select the SLI mode (SLI2 or SLI3) to run the port in,
or even force SLI2 mode if configured. Because of the convoluted logic,
the CONFIG_PORT mbox command ends up being called 2 or 3 times. It should
have been called only once. Additionally, the driver no longer supports
SLI-2, so only SLI-3 mode should be allowed.
The following changes were made:
- Force module parameter to SLI3 only.
- Rip out redundant CONFIG_PORT mbox commands.
- Force CONFIG_PORT mbox command to be in beginning of enable ISR routine.
- Added changes for offline to online behavior
Link: https://lore.kernel.org/r/20210104180240.46824-3-jsmart2021@gmail.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Under some pt2pt situations, the other end of the link may issue a LOGO
after successfully completing PLOGI and assigning addresses to the port.
Thus the driver may attempt a new PLOGI to re-create the login, but the
LOGO handling cleared the address back to 0. Once this happens, the other
end, which may be address 0, gets all confused and this cannot be resolved
without an administrative action to bounce the link.
Fix by assuming that address assignment only occurs on the 1st PLOGI after
link up, and regardless of login state, the address assignment sticks. The
FC standards aren't particularly clear in this situation (it only describes
initial PLOGI), but there is nothing that contradicts this and behaviors on
the devices tested appears to conform to the understanding.
Thus, don't reset the port address to 0 as part of LOGO handling. Port
addresses will only reset on link down.
Link: https://lore.kernel.org/r/20210104180240.46824-2-jsmart2021@gmail.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When non-fatal error like line-reset happens, ufshcd_err_handler() starts
to abort tasks by ufshcd_try_to_abort_task(). When it tries to issue a task
management request, we hit two warnings:
WARNING: CPU: 7 PID: 7 at block/blk-core.c:630 blk_get_request+0x68/0x70
WARNING: CPU: 4 PID: 157 at block/blk-mq-tag.c:82 blk_mq_get_tag+0x438/0x46c
After fixing the above warnings we hit another tm_cmd timeout which may be
caused by unstable controller state:
__ufshcd_issue_tm_cmd: task management cmd 0x80 timed-out
Then, ufshcd_err_handler() enters full reset, and kernel gets stuck. It
turned out ufshcd_print_trs() printed too many messages on console which
requires CPU locks. Likewise hba->silence_err_logs, we need to avoid too
verbose messages. This is actually not an error case.
Link: https://lore.kernel.org/r/20210107185316.788815-3-jaegeuk@kernel.org
Fixes: 69a6c269c0 ("scsi: ufs: Use blk_{get,put}_request() to allocate and free TMFs")
Reviewed-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
