- 19 Mar, 2019 36 commits
-
-
James Smart authored
If all the trunk links drop and a single link resumes, the link_state is not properly reported. When trunked, the driver receives two async cqes. One acqe reports the trunk link states, which the driver records. The other cqe reports the overall state of the trunk. In the failing case, the trunk link state acqe preceeds the overall trunk link state acqe. The trunk link state acqe, as it's an "up" transition, calls a code path which ensures a down transition before moving to the up state. The down transition had a side effect of clearing the just-saved trunk link states. Fix by not clearing the trunk link states if we've already transitioned to a down state. 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>
-
James Smart authored
Invalid test is allowing Loop to be a supported topology on G6 and G7 adapters. The chips do not support loop as their link speeds prohibit loop per standard. Correct the conditional so that loop is not reported. Signed-off-by:
-
James Smart authored
The driver is currently reporting the firmware revision not the actual boot bios version in FDMI data. Modify the driver to obtain the boot bios version from the adapter and use that data in the FMDI data sent to the switch. Signed-off-by:
-
James Smart authored
The switch is rejecting FDMI2 registration for symbolic name. There is a "\n" in the name string, which the switch dislikes thus rejects the registration. Signed-off-by:
-
James Smart authored
The driver is reporting support for NVME even when not configured for NVME operation. Fix (and make more readable) when NVME protocol support is indicated. Signed-off-by:
-
James Smart authored
The FDMI manufacturer value being reported on Linux is inconsistent with other OS's. Set the value to "Emulex Corporation" for consistency. Signed-off-by:
-
James Smart authored
If the driver undergoes repeated host resets it starts losing exchange structures and eventually returns SCSI_MLQUEUE_HOST_BUSY and does not recover. The offline path is not reclaiming the outstanding ios on the fcp pring txcmplq before calling lpfc_destroy_multixripool, which causes the txmcplq to be reinit and the resources lost. Flush the fcp rings before destroying the multixripools. Signed-off-by:
-
James Smart authored
The adapter initialization sequence enables interrupts, initializes the adapter link_state to LINK_DOWN, then issues commands to initialize the adapter. The interrupt handler on the adapter validates the link_state (has to be at least LINK_DOWN) and if invalid, will discard the interrupting event. In most cases, there is not a command completion, thus an interrupt until the initialization commands have been sent which is post the setting of state to LINK_DOWN. However, in cases of firmware reset, the reset will modify the link_state to an invalid value (indicating a reset of the adapter) and there occasionally are cases where the adapter will generate an asynchronous event which shares the eq/cq used for mailbox commands. In the failure case, an interrupt is generated immediately after enabling them due to the async event. As link_state is invalid, the eq is list and the CQ not serviced. At this point link_state is initialized and the mailbox command sent. As the CQ has not been serviced, it is not armed, so no interrupt event is generated when the mailbox command completes. Modify the initialization sequence so that interrupts are enabled after link_state is properly initialized, which avoids the race condition with the async event. Signed-off-by:
-
James Smart authored
It's possible for the scsi error handler to fire and call the target reset handler simultaneously to the driver logging out and relogging into the system. If hit just right, the re-login may not have fully re-established the remote port and the rdata->pnod structure may be null. Check for NULL in the reset handler and return failure if NULL. Signed-off-by:
-
James Smart authored
Current code incorrectly specifies a completion wait timeout duration in 5 jiffies, when it should have been 5 seconds. Fix the adjust for units for the completion timeout call. [mkp: manual merge] Signed-off-by:
-
James Smart authored
Current code is using msleep when polling for hw ready. Unfortunately the msleep routine isn't very accurate on rescheduling. In fact, on a busy systems which reset the adapter, it became 10s of seconds before it was rescheduled. Fix by busy waiting using udelay. As we're now busy waiting, significantly reduce the wait time so that we can exit the pool loop as soon as possible. Signed-off-by:
-
James Smart authored
The driver periodically checks for adapter error in a background thread. If the thread detects an error, the adapter will be reset including the deletion and reallocation of workqueues on the adapter. Simultaneously, there may be a user-space request to offline the adapter which may try to do many of the same steps, in parallel, on a different thread. As memory was deallocated while unexpected, the parallel offline request hit a bad pointer. Add coordination between the two threads. The error recovery thread has precedence. So, when an error is detected, a flag is set on the adapter to indicate the error thread is terminating the adapter. But, before doing that work, it will look for a flag that is set by the offline flow, and if set, will wait for it to complete before then processing the error handling path. Similarly, in the offline thread, it first checks for whether the error thread is resetting the adapter, and if so, will then wait for the error thread to finish. Only after it has finished, will it set its flag and offline the adapter. Signed-off-by:
-
James Smart authored
In a couple of cases, the driver detected a pci error (via pci device state or via failed register reads) but didn't take any action to disable the device. Additionally, the driver is ignoring the status of pci configuration space reads. Having the driver take the adapter offline whenever the pci error is detected. Pay attention to pci_config_space_read status and return failure if an error is seen. Signed-off-by:
-
James Smart authored
If an adapter fails, causing a board reset, the board reset routine lpfc_hba_down_s4() takes the hbalock out then calls lpfc_nvmet_ctxbuf_post() who then tries to take out the same lock. As the context lists are now protected under the buf_list_locks, there is no need for the hbalock to be held by the board reset routine. Fix by no longer taking the hbalock in the board reset routine. Signed-off-by:
-
James Smart authored
With negative test injection, the driver is receiving a command with first burst enabled, meaning Sequence initiative is not passed with the command frame. The driver notes the condition and discards the frame. However the driver calls the incorrect buffer free routine, resulting in a NULL pointer reference. For hbq buffer free, convert to using lpfc_rq_buf_free(). Signed-off-by:
-
James Smart authored
Currently, when lpfc_nvmet_mrq is 0 it could mean 2 different things depending on when its looked at. If at module load time it specifies the default number of hardware queues to allocate, with 0 meaning default to the number of CPUs. But post module load, a value of zero means to disable mrq use. Changed the driver so that enablement of mrq is based on whether nvme target mode is enabled or not. When enabled, mrq is enabled. Thus, the cfg_nvemt_mrq field only specifies the number of mrq queues to enable, with 0 defaulting to the number of cpus. Signed-off-by:
-
James Smart authored
Under circustances with high load, the driver is running out of async receive buffers which may result in one of the following messages: 0:6401 RQE Error x13, posted 226 err_cnt 0: 925c6050 925c604e 925c5d54 or 0:2885 Port Status Event: port status reg 0x81800000, port smphr reg 0xc000, error 1=0x52004a01, error 2=0x0 The driver is waiting for full io completion before returning receive buffers to the adapter. There is no need for such a relationship. Whenever a new command is received from the wire, the driver will have two contexts - an io context (ctxp) and a receive buffer context. In current code, the receive buffer context stays 1:1 with the io and won't be reposted to the hardware until the io completes. There is no need for such a relationship. Change the driver so that up on successful handing of the command to the transport, where the transport has copied what it needed thus the buffer is returned to the driver, have the driver immediately repost the buffer to the hardware. If the command cannot be successfully handed to the transport as transport resources are temporarily busy, have the driver allocate a new and separate receive buffer and post it to the hardware so that hardware can continue while the command is queued for the transport. When an io is complete, the transport returns the io context to the driver, and the driver may be waiting for more contexts, thus immediately reuse the io context. In this path, there was a buffer posted when the receive buffer was queued waiting for an io context so a replacement is not needed in the new code additions. Thus, exempt this the context reuse case from the buffer reposting. Signed-off-by: -
James Smart authored
The debug ktime counters that trace an io were inadvertently not placed in the common section of an io buffer. Thus, they generate an invalid opcode error when accessed. Move the ktime counters into the common area. Fixes: 0794d601 ("scsi: lpfc: Implement common IO buffers between NVME and SCSI") Signed-off-by:
-
James Smart authored
During debug, it was seen that the driver is issuing commands specific to SLI3 on SLI4 devices. Although the adapter correctly rejected the command, this should not be done. Revise the code to stop sending these commands on a SLI4 adapter. Signed-off-by:
-
James Smart authored
When unloading the driver, mailbox commands may be sent without holding a reference on the ndlp. By the time the mailbox command completes, the ndlp may have reduced its ref counts and been freed. The problem was reported by KASAN. While unregistering due to driver unload, have the completion noop'd by setting the ndlp context NULL'd. Due to the unload, no further action was necessary. Also, while reviewing this path, the generic nulling of the context after handling should be slightly moved. Reported by: Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
James Smart authored
A patch in the 12.2.0.0 set caused a new lockdep warning: WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected 5.0.0-rc8-next-20190301-dbg+ #1 Not tainted Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&(&qp->io_buf_list_put_lock)->rlock); local_irq_disable(); lock(&(&phba->hbalock)->rlock); lock(&(&qp->io_buf_list_put_lock)->rlock); <Interrupt> lock(&(&phba->hbalock)->rlock); see: https://www.spinics.net/lists/linux-scsi/msg128389.html In summary, the new patch added taking the io_buf_list_put_lock while under an irq-disabled hbalock. This created a lock heirarchy dependent upon irq being disabled, and there are paths that take the io_buf_list_put_lock without disabling irq. Looking at the lpfc_io_free routine, which is where the new heirarchy was introduced, there is no reason to be taking out the hbalock and raising irq, as the functionality is replaced by the io_buf_list_xxx locks. Resolve by removing the hbalock/irq calls in lpfc_io_free. Fixes: 5e5b511d ("scsi: lpfc: Partition XRI buffer list across Hardware Queues") Reported-by:Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
James Smart authored
A prior patch which added support for non-uniform allocation of MSIX vectors now causes a smatch complaint: drivers/scsi/lpfc/lpfc_scsi.c:3674 lpfc_scsi_cmd_iocb_cmpl() error: we previously assumed 'phba->sli4_hba.hdwq' could be null (see line 3667) Resolve by removing the unnecessary check for a NULL hdwq table. Fixes 6a828b0f: ("scsi: lpfc: Support non-uniform allocation of MSIX vectors to hardware queues") Reported-by:Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Himanshu Madhani authored
This version includes support for ISP28XX. Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
-
Michael Hernandez authored
This patch adds support for Secure flash update with ISP28xx. Signed-off-by:
Michael Hernandez <mhernandez@marvell.com> Signed-off-by:
-
Joe Carnuccio authored
Includes the following: - correction to 27xx image status struct; - factoring of 27xx image status validating routines to make common; - image status generation compare that works across zero wrap; - bsg interface to report current active images (as loaded by driver). Signed-off-by:
Joe Carnuccio <joe.carnuccio@cavium.com> Signed-off-by:
-
Joe Carnuccio authored
Reduce stack space on each fwdt routine by eliminating local variable reg. Signed-off-by:
-
Joe Carnuccio authored
This patch cleans up and fixes firmware dump template processing. These changes are added to support newer features for ISP27XX/ISP28XX. Signed-off-by:
-
Joe Carnuccio authored
This patch makes following changes to flash access routines: - update return type for read_optrom - use void instead of uint32_t * for buffer parameter in read and write optrom routines - fix flash/nvram addressing Signed-off-by:
-
Joe Carnuccio authored
This patch adds multipe firmware dump template and segments support for ISP27XX/28XX. Signed-off-by:
-
Joe Carnuccio authored
This patch does following: - Clean up NVRAM code. - Optimizes reading of primary/secondary flash image validation. - Remove 0xff mask and make correct width in FLT structure. - Use endian macros to assign static fields in fwdump header. - Correct fdwt checksum calculation. - Simplify ql_dump_buffer() interface usage. - Add endianizers to 27xx firmware image validator. - fixes compiler warnings for big endian architecture. Signed-off-by:
-
Joe Carnuccio authored
This patch fixes reported speed for min_link and max_supported speed. Also rename sysfs nodes link_speed and max_supported to be consistent with {min|max}_suuported_speed. Signed-off-by: -
Joe Carnuccio authored
This patch adds sysfs node for serdes_version and also cleans up port_speed display. Signed-off-by:
-
Joe Carnuccio authored
This patch adds PCI device ID ISP28XX for Gen7 support. Also signature determination for primary/secondary flash image for ISP27XX/28XX is aded as part of Gen7 support. Signed-off-by:
-
Joe Carnuccio authored
This patch fixes qla27xx_dump_{mpi|ram} api for ISP27XX. Signed-off-by: -
Joe Carnuccio authored
This patch removes FW default template as there will never be case where the default template would be invoked. Signed-off-by:
-
Joe Carnuccio authored
This patch adds new sysfs node to display firmware attributes and port number. Signed-off-by:
-
- 18 Mar, 2019 4 commits
-
-
Suganath Prabu authored
Updated driver version to 28.100.00.00, which is equivalent to OOB Phase 9. Signed-off-by:
Suganath Prabu <suganath-prabu.subramani@broadcom.com> Signed-off-by:
-
Suganath Prabu authored
* Reduce the threshold value to 1/4 of the queue depth. * With this FW can find enough entries to post the Reply Descriptors in the reply descriptor post queue. * With module param, user can play with threshold value, the same irqpoll_weight is used as the budget in processing of reply descriptor post queues in _base_process_reply_queue. Signed-off-by:
-
Suganath Prabu authored
Driver uses "reply descriptor post queues" in round robin fashion so that IO's are distributed to all the available reply descriptor post queues equally. With this each reply descriptor post queue load is balanced. This is enabled only if CPUs count to MSI-X vector count ratio is X:1 (where X > 1) This improves performance and also fixes soft lockups. Signed-off-by:
-
Suganath Prabu authored
Issue Description: We have seen cpu lock up issue from fields if system has greater (more than 96) logical cpu count. SAS3.0 controller (Invader series) supports at max 96 msix vector and SAS3.5 product (Ventura) supports at max 128 msix vectors. This may be a generic issue (if PCI device supports completion on multiple reply queues). Let me explain it w.r.t to mpt3sas supported h/w just to simplify the problem and possible changes to handle such issues. IT HBA (mpt3sas) supports multiple reply queues in completion path. Driver creates MSI-x vectors for controller as "min of (FW supported Reply queue, Logical CPUs)". If submitter is not interrupted via completion on same CPU, there is a loop in the IO path. This behavior can cause hard/soft CPU lockups, IO timeout, system sluggish etc. Example - one CPU (e.g. CPU A) is busy submitting the IOs and another CPU (e.g. CPU B) is busy with processing the corresponding IO's reply descriptors from reply descriptor queue upon receiving the interrupts from HBA. If the CPU A is continuously pumping the IOs then always CPU B (which is executing the ISR) will see the valid reply descriptors in the reply descriptor queue and it will be continuously processing those reply descriptor in a loop without quitting the ISR handler. Mpt3sas driver will exit ISR handler if it finds unused reply descriptor in the reply descriptor queue. Since CPU A will be continuously sending the IOs, CPU B may always see a valid reply descriptor (posted by HBA Firmware after processing the IO) in the reply descriptor queue. In worst case, driver will not quit from this loop in the ISR handler. Eventually, CPU lockup will be detected by watchdog. Above mentioned behavior is not common if "rq_affinity" set to 2 or affinity_hint is honored by irqbalance as "exact". If rq_affinity is set to 2, submitter will be always interrupted via completion on same CPU. If irqbalance is using "exact" policy, interrupt will be delivered to submitter CPU. If CPU counts to MSI-X vectors (reply descriptor Queues) count ratio is not 1:1, we still have exposure of issue explained above and for that we don't have any solution. Exposure of soft/hard lockup if CPU count is more than MSI-x supported by device. If CPUs count to MSI-x vectors count ratio is not 1:1, (Other way, if CPU counts to MSI-x vector count ratio is something like X:1, where X > 1) then 'exact' irqbalance policy OR rq_affinity = 2 won't help to avoid CPU hard/soft lockups. There won't be any one to one mapping between CPU to MSI-x vector instead one MSI-x interrupt (or reply descriptor queue) is shared with group/set of CPUs and there is a possibility of having a loop in the IO path within that CPU group and may observe lockups. For example: Consider a system having two NUMA nodes and each node having four logical CPUs and also consider that number of MSI-x vectors enabled on the HBA is two, then CPUs count to MSI-x vector count ratio as 4:1. e.g. MSIx vector 0 is affinity to CPU 0, CPU 1, CPU 2 & CPU 3 of NUMA node 0 and MSI-x vector 1 is affinity to CPU 4, CPU 5, CPU 6 & CPU 7 of NUMA node 1. numactl --hardware available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 --> MSI-x 0 node 0 size: 65536 MB node 0 free: 63176 MB node 1 cpus: 4 5 6 7 -->MSI-x 1 node 1 size: 65536 MB node 1 free: 63176 MB Assume that user started an application which uses all the CPUs of NUMA node 0 for issuing the IOs. Only one CPU from affinity list (it can be any cpu since this behavior depends upon irqbalance) CPU0 will receive the interrupts from MSIx vector 0 for all the IOs. Eventually, CPU 0 IO submission percentage will be decreasing and ISR processing percentage will be increasing as it is more busy with processing the interrupts. Gradually IO submission percentage on CPU 0 will be zero and it's ISR processing percentage will be 100 percentage as IO loop has already formed within the NUMA node 0, i.e. CPU 1, CPU 2 & CPU 3 will be continuously busy with submitting the heavy IOs and only CPU 0 is busy in the ISR path as it always find the valid reply descriptor in the reply descriptor queue. Eventually, we will observe the hard lockup here. Chances of occurring of hard/soft lockups are directly proportional to value of X. If value of X is high, then chances of observing CPU lockups is high. Solution: Use IRQ poll interface defined in " irq_poll.c". mpt3sas driver will execute ISR routine in Softirq context and it will always quit the loop based on budget provided in IRQ poll interface. In these scenarios (i.e. where CPUs count to MSI-X vectors count ratio is X:1 (where X > 1)), IRQ poll interface will avoid CPU hard lockups due to voluntary exit from the reply queue processing based on budget. Note - Only one MSI-x vector is busy doing processing. Irqstat output: IRQs / 1 second(s) IRQ# TOTAL NODE0 NODE1 NODE2 NODE3 NAME 44 122871 122871 0 0 0 IR-PCI-MSI-edge mpt3sas0-msix0 45 0 0 0 0 0 IR-PCI-MSI-edge mpt3sas0-msix1 We use this approach only if cpu count is more than FW supported MSI-x vector Signed-off-by:
-
