- 18 Jun, 2019 40 commits
-
-
James Smart authored
Turns out the message change in 12.2.0.1 for unsupported topology makes the linux driver out of sync with other products. Revert the message back to the prior content for product consistency. 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
The driver currently is relying on firmware to match ABTSs to existing exchanges. This works fine as long as an exchange has been assigned to the io and work posted to it. However, for unmapped frames (rxid=0xFFFF), the driver has yet to assign an xri. The driver was blindly saying it couldn't match the ABTS and sending the BA_xxx. However, the command frame may have been in queues waiting on xri's before posting to the nvmet_fc layer. When xri's became available, the command frame would still be pushed to the transport and that io would execute, even though the io had been killed by ABTS. The initiator, seeing the io ABTS'd, would reuse the exchange for a different io which would be received on the target and pushed up. If the "zombie" io then came back down and started transmitting, the initiator would match the oxid and accept erroneous data. Bad things happened. Add tracking of active exchanges in the target to allow matching of a received ABTS against active or pending IO requests. If the ABTS is matched to a pending or active IO, the drive initiates cleanup and conditionally notifies the transport. Signed-off-by:
-
James Smart authored
Currently the driver is notified of new command frame receipt by CQEs. As part of the CQE processing, the driver upcalls the nvmet_fc transport to deliver the command. nvmet_fc, as part of receiving the command builds out a context for it, where one of the first steps is to allocate memory for the io. When running with tests that do large ios (1MB), it was found on some systems, the total number of outstanding I/O's, at 1MB per, completely consumed the system's memory. Thus additional ios were getting blocked in the memory allocator. Given that this blocked the lpfc thread processing CQEs, there were lots of other commands that were received and which are then held up, and given CQEs are serially processed, the aggregate delays for an IO waiting behind the others became cummulative - enough so that the initiator hit timeouts for the ios. The basic fix is to avoid the direct upcall and instead schedule a work item for each io as it is received. This allows the cq processing to complete very quickly, and each io can then run or block on it's own. However, this general solution hurts latency when there are few ios. As such, implemented the fix such that the driver watches how many CQEs it has processed sequentially in one run. As long as the count is below a threshold, the direct nvmet_fc upcall will be made. Only when the count is exceeded will it revert to work scheduling. Given that debug of this showed a surprisingly long delay in cq processing, the io timer stats were updated to better reflect the processing of the different points. Signed-off-by:
-
James Smart authored
Revise a stalled adapter message to also include the number of jobs that are stalling the thread. Signed-off-by:
-
James Smart authored
A race condition resulted in receive buffers being placed in the free list twice. Change the locking and handling to check whether the "other" path will be freeing the entry in a later thread and skip it if it is. Signed-off-by:
-
James Smart authored
After receiving an unsolicited ABTS (meaning rxid is 0xFFFF), the driver used the oxid from the initiator to match against a local xri which may have been allocated for the io. The xri would be the rxid - it's an invalid check resulting in the command not being matched or erroneously matched. Change the lookup to use the oxid and the SID to match against received IO's original values. Signed-off-by:
-
James Smart authored
Softlockups are seen in low memory situations. They are due to doing oas_lun allocation with GFP_KERNEL in atomic contexts. Change the calls to oas_lun to indicate atomic context so that GFP_ATOMIC is used. Signed-off-by:
-
Shivasharan S authored
Signed-off-by:
Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by:
-
Shivasharan S authored
Create a debugfs interface for megaraid_sas driver. Provide interface to dump driver RAID map in debugfs. Signed-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
-
Shivasharan S authored
Print FW supported MSI-X vector count only if FW supports MSI-X. Signed-off-by:
-
Shivasharan S authored
Add debug prints related to device list being returned by firmware. The a debug flag to activate these prints. Signed-off-by:
-
Shivasharan S authored
Add prints in resume/suspend path to help in debugging hibernation issues. The print gives an indication when the driver entry points are called. Signed-off-by:
-
Shivasharan S authored
Add a print to dump the interrupt status in system log for debugging. Signed-off-by:
-
Shivasharan S authored
When driver detects a firmware fault during load, dump additional information on fault code and subcode that will help in debugging. Signed-off-by:
-
Shivasharan S authored
Add a sysfs interface to get the raid map index that is being used by driver. Signed-off-by:
-
Shivasharan S authored
Add prints for BAR address information during driver load. This helps in debugging issues with BAR address changing during OS boot. Signed-off-by:
-
Shivasharan S authored
When controller fails to transition to READY state during driver probe, dump the system interface register set. This will give snapshot of the firmware status for debugging driver load issues. Signed-off-by:
-
Shivasharan S authored
Add a sysfs interface to dump the controller's system interface registers. Signed-off-by:
-
Shivasharan S authored
Add option to format the buffer that is being dumped. Currently, the IO frame and chain frame dumped in the syslog is getting split across multiple lines based on the formatting. Fix this by using KERN_CONT in printk. Signed-off-by:
-
Shivasharan S authored
Add prints to identify the internal DCMD opcode that has timed out. Signed-off-by:
-
Shivasharan S authored
This patch enhances the existing debug prints in reset and task management path. These debug prints in adapter reset path helps with debugging issues related to IO timeouts that are seen frequently in the field. Add additional debug prints to dump the pending command frames before initiating an adapter reset. Also, print FastPath IOs that are outstanding. Signed-off-by:
-
Shivasharan S authored
Driver will use "reply descriptor post queues" in round robin fashion when the combined MSI-X mode is not enabled. With this IO completions are distributed and load balanced across all the available reply descriptor post queues equally. This is enabled only if combined MSI-X mode is not enabled in firmware. This improves performance and also fixes soft lockups. When load balancing is enabled, IRQ affinity from driver needs to be disabled. Signed-off-by:
Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by:
-
Shivasharan S authored
Issue Description: We have seen cpu lock up issues from field if system has a large (more than 96) logical cpu count. SAS3.0 controller (Invader series) supports max 96 MSI-X vector and SAS3.5 product (Ventura) supports max 128 MSI-X vectors. This may be a generic issue (if PCI device support completion on multiple reply queues). Let me explain it w.r.t megaraid_sas supported h/w just to simplify the problem and possible changes to handle such issues. MegaRAID controller supports multiple reply queues in completion path. Driver creates MSI-X vectors for controller as "minimum of (FW supported Reply queues, 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 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. megaraid_sas 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 irqbalancer as "exact". If rq_affinity is set to 2, submitter will be always interrupted via completion on same CPU. If irqbalancer is using "exact" policy, interrupt will be delivered to submitter CPU. Problem statement: If CPU count 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 is seen 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. MSI-X 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 MSI-X 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% 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". megaraid_sas driver will execute ISR routine in softirq context and it will always quit the loop based on budget provided in IRQ poll interface. Driver will switch to IRQ poll only when more than a threshold number of reply descriptors are handled in one ISR. Currently threshold is set as 1/4th of HBA queue depth. 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. Select CONFIG_IRQ_POLL from driver Kconfig for driver compilation. Signed-off-by:
-
Shivasharan S authored
While an online controller reset(OCR) is in progress, there is short duration where all access to controller's PCI config space from the host needs to be blocked. This is due to a hardware limitation of MegaRAID controllers. With this patch, driver will block all access to controller's config space from userland applications by calling pci_cfg_access_lock() while OCR is in progress and unlocking after controller comes back to ready state. Added helper function which locks the config space before initiating OCR and wait for controller to become READY. Signed-off-by:
-
Shivasharan S authored
No functional change. This patch reworks code around controller reset path which gets rid of a couple of goto labels. This is in preparation for the next patch which adds PCI config space access locking while controller reset is in progress. Signed-off-by:
-
Shivasharan S authored
fw_reset_no_pci_access is only applicable for MFI controllers and is not used for Fusion controllers. For all Fusion controllers, driver can check reset adapter bit in status register before performing a chip reset without setting "fw_reset_no_pci_access". Signed-off-by:
-
Shivasharan S authored
No functional change. Remove set but unused variable in megasas_set_static_target_properties. Signed-off-by:
-
Ondrej Zary authored
Future Domain 16xx ISA SCSI support card support. Tested on IBM 92F0330 card (18C50 chip) with v1.00 BIOS. Signed-off-by:
Ondrej Zary <linux@zary.sk> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Ondrej Zary authored
Future Domain TMC-3260/AHA-2920A PCI card support. Tested on Adaptec AHA-2920A PCI card. Signed-off-by:
-
Ondrej Zary authored
Future Domain TMC-16xx/TMC-3260 SCSI driver. This is the core driver, common for PCI, ISA and PCMCIA cards. Signed-off-by:
-
Don Brace authored
[mkp: wrong baseline, applied by hand] Reviewed-by:
Gerry Morong <gerry.morong@microsemi.com> Signed-off-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
-
Don Brace authored
Correct a race condition that occurs between the reset handler and the completion handler. There are times when the wait_event condition is never met due to this race condition and the reset never completes. The reset_pending field is NULL initially. t Reset Handler Thread Completion Thread -- -------------------- ----------------- t1 if (c->reset_pending) t2 c->reset_pending = dev; if (atomic_dev_and_test(counter)) t3 atomic_inc(counter) wait_up_all(event_sync_wait_queue) t4 t5 wait_event(...counter == 0) Kernel.org Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=1994350 Bug 199435 - HPSA + P420i resetting logical Direct-Access never complete Reviewed-by:Justin Lindley <justin.lindley@microsemi.com> Reviewed-by:
David Carroll <david.carroll@microsemi.com> Reviewed-by:
Scott Teel <scott.teel@microsemi.com> Signed-off-by:
-
Don Brace authored
Close up a rare multipath issue. Close up small hole where a command completes after a device has been removed from SML and before the device is re-added. - Mark device as removed in slave_destroy - Do not complete commands for deleted devices Reviewed-by:
-
Don Brace authored
Wait longer for outstanding commands before removing a multipath device. Increase the timeout value for ptraid commands. Reviewed-by:
-
Don Brace authored
Correct rare multipath issue where a device is deleted with an outstanding cmd which results in a tag collision. The cmd eventually completes. If a collision is detected wait until the command slot is cleared. Reviewed-by:
-
Don Brace authored
Avoid system stalls by switching to local workqueue. Reviewed-by:
-
Don Brace authored
Correct issue with hpsa_simple_mode module parameter. Driver was hanging due to incorrect interrupt setup. Reviewed-by:
-
Hannes Reinecke authored
The osst driver is becoming obsolete, as the manufacturer went out of business ages ago, and the maintainer has no means of testing any improvements anymore. Plus these days flash drives are cheaper and offer a higher capacity. So drop it completely. Cc: Willem Riede <osst@riede.org> Signed-off-by:
Hannes Reinece <hare@suse.com> Signed-off-by:
-
Bart Van Assche authored
Make sd_probe() easier to read by inlining sd_probe_part2(). This patch does not change any functionality. [mkp: applied by hand] Cc: Lee Duncan <lduncan@suse.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: Johannes Thumshirn <jthumshirn@suse.de> Cc: Christoph Hellwig <hch@lst.de> Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
-
Bart Van Assche authored
As explained during the 2018 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 SCSI disk probes. - There is unnecessary serialization between sd_probe() and sd_remove(). This can lead to a deadlock. Hence this patch that modifies the sd driver such that it uses the driver core framework for asynchronous probing. The async domain and get_device()/put_device() pairs that became superfluous due to this change are removed. This patch does not affect the time needed for loading the scsi_debug kernel module with parameters delay=0 and max_luns=256. This patch depends on commit ef0ff683 ("driver core: Probe devices asynchronously instead of the driver") that went upstream in kernel version v5.1-rc1. Cc: Lee Duncan <lduncan@suse.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: Johannes Thumshirn <jthumshirn@suse.de> Cc: Christoph Hellwig <hch@lst.de> Cc: Pavel Machek <pavel@ucw.cz> Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
