An error occurred fetching the project authors.
- 01 Oct, 2019 2 commits
-
-
James Smart authored
When target-side fault injections are made, the driver isn't reconnecting to the remote port. The driver is logging "2753" error messages which state: "PLOGI failure DID:1B2400 Status:x3/xf0240008" The failures status is indicating a Illegal field error, which points to the Temporary RPI field being used for the ELS. This error typically means the driver used an RPI that was already registered (shouldn't be registered if using it in this context). Study has found that if the driver were in discovery attempts and encountered an error, it wouldn't flag the temporary rpi in error. Yet the rpi was released for reallocation in these error paths and another ELS could allocate the rpi. In the failure situation a retry was done on an ELS that had encountered an error, and as the rpi wasn't marked in error, the ELS reused the rpi it originally allocated. But that rpi had been allocated by a different ELS issued after the original error and before the retry attempt. The different ELS had succeeded and the RPI was registered. Fix by marking the rpi state for the node to be in error, aka as needing reallocation, upon an error in the els processing. Error state marking is always done prior to release back to the internal rpi free list, which the driver wasn't doing in cases prior. Also enhanced some of the logging to help in the next case of problem troubleshooting. Link: https://lore.kernel.org/r/20190922035906.10977-7-jsmart2021@gmail.comSigned-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
A prior use-after-free mailbox fix solved it's problem by null'ing a ndlp pointer. However, further testing has shown that this change causes a later state change to occasionally be skipped, which results in a reference count never being decremented thus the rpi is never released, which causes a vport delete to never succeed. Revise the fix in the prior patch to no longer null the ndlp. Instead the RELEASE_RPI flag is set which will drive the release of the rpi. Given the new code was added at a deep indentation level, refactor the code block using a new routine that avoids the indentation issues. Fixes: 9b164068 ("scsi: lpfc: Fix use-after-free mailbox cmd completion") Link: https://lore.kernel.org/r/20190922035906.10977-6-jsmart2021@gmail.comSigned-off-by:
-
- 07 Sep, 2019 1 commit
-
-
Sakari Ailus authored
Convert the remaining %pf users to %ps to prepare for the removal of the old %pf conversion specifier support. Fixes: 32350664 ("scsi: lpfc: Migrate to %px and %pf in kernel print calls") Link: https://lore.kernel.org/r/20190904160423.3865-1-sakari.ailus@linux.intel.comSigned-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
-
- 20 Aug, 2019 6 commits
-
-
James Smart authored
In order to see real addresses, convert %p with %px for kernel addresses and replace %p with %pf for functions. While converting, standardize on "x%px" throughout (not %px or 0x%px). Signed-off-by:
-
James Smart authored
GetTrunkInfo is displaying an incorrect link speed when the link is a trunk and the link has gone down. The driver is not clearing the logical speed as part of the link down transition. Fix by setting the logical speed to UNKNOWN SPEED when the link goes down. Signed-off-by:
-
James Smart authored
During cable pull testing a deadlock was seen between lpfc_nlp_counters() vs lpfc_mbox_process_link_up() vs lpfc_work_list_done(). They are all waiting on the shost->host_lock. Issue is all of these cases raise irq when taking out the lock but use spin_unlock_irq() when unlocking. The unlock path is will unconditionally re-enable interrupts in cases where irq state should be preserved. The re-enablement allowed the other paths to execute which then causes the deadlock. Fix by converting the lock/unlock to irqsave/irqrestore. Signed-off-by:
-
James Smart authored
In tests with remote ports contantly logging out/logging coupled with occassional local link bounce, if a remote port is disocnnected for longer than devloss_tmo and then subsequently reconnected, eventually the test will fail to login with the remote port and remote port connectivity is lost. When devloss_tmo expires, the driver does not free the node struct until the port or npiv instances is being deleted. The node is left allocated but the state set to UNUSED. If the node was in the process of logging in when the local link drop occurred, meaning the RPI was allocated for the node in order to send the ELS, but not yet registered which comes after successful login, the node is moved to the NPR state, and if devloss expires, to UNUSED state. If the remote port comes back, the node associated with it is restarted and this path happens to allocate a new RPI and overwrites the prior RPI value. In the cases where the port was logged in and loggs out, the path did release the RPI but did not set the node rpi value. In the cases where the remote port never finished logging in, the path never did the call to release the rpi. In this latter case, when the node is subsequently restore, the new rpi allocation overwrites the rpi that was not released, and the rpi is now leaked. Eventually the port will run out of RPI resources to log into new remote ports. Fix by following changes: - When an rpi is released, do so under locks and ensure the node rpi value is set to a non-allocated value (LPFC_RPI_ALLOC_ERROR). Note: refactored to a small service routine to avoid indentation issues. - When re-enabling a node, check the rpi value to determine if a new allocation is necessary. If already set, use the prior rpi. Enhanced logging to help in the future. Signed-off-by:
-
James Smart authored
When connected to a high number of remote ports, the driver is encountering PLOGI errors. The errors are due to adapter detected failures indicating illegal field values. Turns out the driver was prematurely clearing an RPI bitmask before waiting for an UNREG_RPI mailbox completion. This allowed the RPI to be reused before it was actually available. Fix by clearing RPI bitmask only after UNREG_RPI mailbox completion. Signed-off-by:
-
Fuqian Huang authored
As spin_unlock_irq will enable interrupts. Function lpfc_findnode_rpi is called from lpfc_sli_abts_err_handler (./drivers/scsi/lpfc/lpfc_sli.c) <- lpfc_sli_async_event_handler <- lpfc_sli_process_unsol_iocb <- lpfc_sli_handle_fast_ring_event <- lpfc_sli_fp_intr_handler <- lpfc_sli_intr_handler and lpfc_sli_intr_handler is an interrupt handler. Interrupts are enabled in interrupt handler. Use spin_lock_irqsave/spin_unlock_irqrestore instead of spin_(un)lock_irq in IRQ context to avoid this. Signed-off-by:Fuqian Huang <huangfq.daxian@gmail.com> Reviewed-by:
-
- 21 Jun, 2019 1 commit
-
-
James Smart authored
This patch adds general RSCN support: - The ability to transmit an RSCN to the port on the other end of the link (regular port if pt2pt, or fabric controller if fabric). - And general recognition of an RSCN ELS when an ELS is received. Signed-off-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Arun Easi <aeasi@marvell.com> Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Christoph Hellwig <hch@lst.de>
-
- 13 Apr, 2019 1 commit
-
-
Hannes Reinecke authored
Currently the FC-NVMe driver is leverating the SCSI FC transport class to access the remote ports. Which means that all FC-NVMe remote ports will be visible to the fc transport layer, but due to missing definitions the port roles will always be 'unknown'. This patch adds the missing definitions to the fc transport class to that the port roles are correctly displayed. Signed-off-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Reviewed-by:
Giridhar Malavali <gmalavali@marvell.com> Reviewed-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
-
- 08 Apr, 2019 1 commit
-
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that, in this particular case, I replaced "Drop thru" with a "fall through" annotation, which is what GCC is expecting to find. Addresses-Coverity-ID: 114976 ("Missing break in switch") Addresses-Coverity-ID: 114977 ("Missing break in switch") Reviewed-by:Kees Cook <keescook@chromium.org> Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com>
-
- 04 Apr, 2019 1 commit
-
-
Bart Van Assche authored
This patch avoids that the compiler warns about missing fall-through annotation when building with W=1. Cc: James Smart <james.smart@broadcom.com> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Acked-by:
-
- 19 Mar, 2019 3 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:
-
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:
-
- 06 Feb, 2019 3 commits
-
-
James Smart authored
For files modified as part of 12.2.0.0 patches, update copyright to 2019 Signed-off-by:
-
James Smart authored
The conversion to enable SCSI and NVME fc4 support ran into an issue with NPIV support. With NVME, NPIV is not currently supported, but with SCSI it was. The driver reverted to its lowest setting meaning NPIV with SCSI was not allowed. Convert the NPIV checks and implementation so that SCSI can continue to allow NPIV support. Signed-off-by:
-
James Smart authored
Both NVME and SCSI aborts are now processed off the CQ workqueue and do not generate events for the slowpath any more. Remove the unused event code. Signed-off-by:
-
- 20 Dec, 2018 2 commits
-
-
James Smart authored
When a target's link dropped, an RSCN was received to communicate the change. The driver detected the loss of the target and issued and UNREG_RPI mailbox command. While that was being processed, another RSCN was received to communicate the port coming back. The driver deferred the PLOGI to the port until the mailbox command finishes. When the mailbox command completed it saw the pending port and called the routines to issue the PLOGI. However, it forgot to clear the UNREG_INP state flag, so the PLOGI xmt routine nooped the PLOGI request assuming it needed to wait for the mailbox command. At this point, login would never be re-attempted. Clear UNREG_INP before issuing the deferred PLOGI. Signed-off-by:
-
James Smart authored
If the adapter is taken offline, the trunk link port attributes continue to report trunk links as up even though all links are down as the adapter is offline. Clear the trunk links state as part of taking the adapter offline. Signed-off-by:
-
- 13 Dec, 2018 1 commit
-
-
James Smart authored
Addition of support for if_type=6 missed several checks for interface type, resulting in the failure of several key management features such as firmware dump and loopback testing. Correct the checks on the if_type so that both SLI4 IF_TYPE's 2 and 6 are supported. Signed-off-by:
-
- 08 Dec, 2018 3 commits
-
-
James Smart authored
The current discovery state machine the driver treated FLOGI oddly. When point to point, an FLOGI is to be exchanged by the two ports, with the port with the most significant WWN then proceeding with PLOGI. The implementation in the driver was keyed to closely with "what have I sent", not with what has happened between the two endpoints. Thus, it blatantly would ACC an FLOGI, but reject PLOGI's until it had its FLOGI ACC'd. The problem is - the sending of FLOGI may be delayed for some reason, or the response to FLOGI held off by the other side. In the failing situation the other side sent an FLOGI, which was ACC'd, then sent PLOGIs which were then rjt'd until the retry count for the PLOGIs were exceeded and the port gave up. The FLOGI may have been very late in transmit, or the response held off until the PLOGIs failed. Given the other port had the higher WWN, no PLOGIs would occur and communication stopped. Correct the situation by changing the FLOGI handling. Defer any response to an FLOGI until the driver has sent its FLOGI as well. Then, upon either completion of the sent FLOGI, or upon sending an ACC to a received FLOGI (which may be received before or just after FLOGI was sent). the driver will act on who has the higher WWN. if the other port does, the driver will noop any handling of an FLOGI response (if outstanding) and wait for PLOGI. If the local port does, the driver will transition to sending PLOGI and will noop any action on responding to an FLOGI (if not yet received). Fortunately, to implement this, it only took another state flag and deferring any FLOGI response if the FLOGI has yet to be transmit. All subsequent actions were already in place. Signed-off-by:
-
James Smart authored
The driver is getting hit with 100s of RSCNs during remote port address changes. Each of those RSCN's ends up generating UNREG_RPI and REG_PRI mailbox commands. The discovery engine within the driver doesn't wait for the mailbox command completions. Instead it sets state flags and moves forward. At some point, there's a massive backlog of mailbox commands which take time for the adapter to process. Additionally, it appears there were duplicate events from the switch so the driver generated duplicate mailbox commands for the same remote port. During this window, failures on PLOGI and PRLI ELS's are see as the adapter is rejecting them as they are for remote ports that still have pending mailbox commands. Streamline the discovery engine so that PLOGI log checks for outstanding UNREG_RPIs and defer the processing until the commands complete. This better synchronizes the ELS transmission vs the RPI registrations. Filter out multiple UNREG_RPIs being queued up for the same remote port. Beef up log messages in this area. Signed-off-by:
-
James Smart authored
The driver data structure for managing a mailbox command contained two context fields. Unfortunately, the context were considered "generic" to be used at the whim of the command code. Of course, one section of code used fields this way, while another did it that way, and eventually there were mixups. Refactored the structure so that the generic contexts become a node context and a buffer context and all code standardizes on their use. Signed-off-by:
-
- 07 Nov, 2018 4 commits
-
-
James Smart authored
Add trunking support to the driver. Trunking is found on more recent asics. In general, trunking appears as a single "port" to the driver and overall behavior doesn't differ. Link speed is reported as an aggregate value, while link speed control is done on a per-physical link basis with all links in the trunk symmetrical. Some commands returning port information are updated to additionally provide trunking information. And new ACQEs are generated to report physical link events relative to the trunk. This patch contains the following modifications: - Added link speed settings of 128GB and 256GB. - Added handling of trunk-related ACQEs, mainly logging and trapping of physical link statuses. - Added additional bsg interface to query trunk state by applications. - Augment link_state sysfs attribtute to display trunk link status Signed-off-by:
-
James Smart authored
The switches seem to respond faster to GID_PT vs GID_FT NameServer queries. Add support for GID_PT to be used over GID_FT to enable faster storage failover detection. Includes addition of new module parameter to select between GID_PT and GID_FT (GID_FT is default). Signed-off-by:
-
James Smart authored
Testing a point-to-point topology and a case of re-FLOGI without intervening link bouncing, showed an odd interaction with firmware and a resulting scenario where the driver no longer probed after accepting the new FLOGI. Work around the firmware issue by issuing a link bounce if a FLOGI is received after the link is already up and FLOGI's accepted. While debugging the issue, realized that some debug traces should be clarified to help in the future. Signed-off-by:
-
James Smart authored
On FCoE adapters, when running link bounce test in a loop, initiator failed to login with switch switch and required driver reload to recover. Switch reached a point where all subsequent FLOGIs would be LS_RJT'd. Further testing showed the condition to be related to not performing FCF discovery between FLOGI's. Fix by monitoring FLOGI failures and once a repeated error is seen repeat FCF discovery. Signed-off-by:
-
- 17 Oct, 2018 1 commit
-
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/scsi/lpfc/lpfc_hbadisc.c: In function 'lpfc_free_tx': drivers/scsi/lpfc/lpfc_hbadisc.c:5431:19: warning: variable 'psli' set but not used [-Wunused-but-set-variable] Since commit 895427bd ("scsi: lpfc: NVME Initiator: Base modifications") 'psli' is not used any more. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
- 12 Sep, 2018 2 commits
-
-
James Smart authored
When taking the board offline while performing i/o, unsafe locking errors occurred and irq level isn't properly managed. In lpfc_sli_hba_down, spin_lock_irqsave(&phba->hbalock, flags) does not disable softirqs raised from timer expiry. It is possible that a softirq is raised from the lpfc_els_retry_delay routine and recursively requests the same phba->hbalock spinlock causing deadlock. Address the deadlocks by creating a new port_list lock. The softirq behavior can then be managed a level deeper into the calling sequences. Signed-off-by:
-
James Smart authored
Driver only sends NVME PRLI to a device that also supports FCP. This resuls in remote ports that don't have fc_remote_ports created for them. The driver is clearing the nlp_fc4_type for a ndlp at the wrong time. Fix by moving the nlp_fc4_type clearing to the discovery engine in the DEVICE_RECOVERY state. Also ensure that rport registration is done for all nlp_fc4_types. Signed-off-by:
-
- 11 Jul, 2018 1 commit
-
-
James Smart authored
Change references from "Broadcom Limited" to "Broadcom Inc." in the copyright message. Update copyright duration if not yet updated for 2018. Signed-off-by:
-
- 29 May, 2018 1 commit
-
-
James Smart authored
MDS diagnostics fail because of frame count mismatch. Unavailability of SGL is the trigger for this issue. If ELS SGL is not available to process MDS frame, IOCB is put in FCP txq but not attempted to post afterwards. So, driver stops processing incoming frames as it runs out of IOCB. lpfc_drain_txq attempts to submit IOCBS that are queued in ELS txq but MDS frames are posted to FCP WQ. Attempt to submit IOCBs that are present in FCP txq when MDS loopback is running. Signed-off-by:
-
- 18 Apr, 2018 1 commit
-
-
James Smart authored
Remote port disappearance/reappearances would cause a series of RSCN events to be delivered to the driver. During the resulting GID_FT handling, the driver clears the fc4 settings on the remote port, which makes it skip registration. As such, the nvme associations eventually fail and return io errors to the applications. Correct by not clearng the nlp_fc4_types for all nodes in lpfc_issue_gidft. Instead, when the GID_FT response is handled, clear the nlp_fc4_types of FCP and NVME prior to evaluating the fc4_type returned by the GID_FT response. This approach leaves "skipped" nodes with their nlp_fc4_types intacted. Signed-off-by:
-
- 13 Mar, 2018 1 commit
-
-
James Smart authored
When a port is configured for NVME and SCSI Initiator support and it probes a target supporting both SCSI and NVME, NVME devices are discovered, but SCSI devices are not. The nlp_fc4_type for all NPorts should be cleared on Link Up or just before GID_FTs get issued, as opposed to just during GID_FT cmpl. RSCN activity as well as Link Up can trigger GID_FT. One GID_FT may complete before the next one is issued. Fix by clearng nlp_fc4_type on link up and just before both GID_FTs are issued. During port swapping, copy nlp_fc4_type to the new ndlp Signed-off-by:
-
- 23 Feb, 2018 1 commit
-
-
James Smart authored
The G7 adapter supports 64G link speeds. Add support to the driver. In addition, a small cleanup to replace the odd bitmap logic with a switch case. Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
-
- 12 Feb, 2018 2 commits
-
-
James Smart authored
Updated Copyright in files updated 11.4.0.7 Signed-off-by:
-
James Smart authored
During link bounce testing in a point-to-point topology, the host may enter a soft lockup on the lpfc_worker thread: Call Trace: lpfc_work_done+0x1f3/0x1390 [lpfc] lpfc_do_work+0x16f/0x180 [lpfc] kthread+0xc7/0xe0 ret_from_fork+0x3f/0x70 The driver was simultaneously setting a combination of flags that caused lpfc_do_work()to effectively spin between slow path work and new event data, causing the lockup. Ensure in the typical wq completions, that new event data flags are set if the slow path flag is running. The slow path will eventually reschedule the wq handling. Signed-off-by:
-
- 05 Dec, 2017 1 commit
-
-
James Smart authored
The driver currently registers any remote port that has NVME support. It should only be registering target ports. Register only target ports. Signed-off-by:
-
