- 12 Jul, 2019 7 commits
-
-
Shivasharan S authored
In megasas_get_target_prop(), driver is incorrectly calculating the target ID for devices with channel 1 and 3. Due to this, firmware will either fail the command (if there is no device with the target id sent from driver) or could return the properties for a target which was not intended. Devices could end up with the wrong queue depth due to this. Fix target id calculation for channel 1 and 3. Fixes: 96188a89 ("scsi: megaraid_sas: NVME interface target prop added") Cc: stable@vger.kernel.org Signed-off-by:
Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Arnd Bergmann authored
The lpfc_debug_dump_all_queues() function repeatedly calls into lpfc_debug_dump_qe() which has a temporary 128 byte buffer. This was fine before the introduction of CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE because each instance could occupy the same stack slot. However, now they each get their own copy, which leads to a huge increase in stack usage as seen from the compiler warning: drivers/scsi/lpfc/lpfc_debugfs.c: In function 'lpfc_debug_dump_all_queues': drivers/scsi/lpfc/lpfc_debugfs.c:6474:1: error: the frame size of 1712 bytes is larger than 100 bytes [-Werror=frame-larger-than=] Avoid this by not marking lpfc_debug_dump_qe() as inline so the compiler can choose to emit a static version of this function when it's needed or otherwise silently drop it. As an added benefit, not inlining multiple copies of this function means we save several kilobytes of .text section, reducing the file size from 47kb to 43. It is somewhat unusual to have a function that is static but not inline in a header file, but this does not cause problems here because it is only used by other inline functions. It would however seem reasonable to move all the lpfc_debug_dump_* functions into lpfc_debugfs.c and not mark them inline as a later cleanup. Fixes: 81a56f6d ("gcc-plugins: structleak: Generalize to all variable types") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
-
Marcos Paulo de Souza authored
Currently, all USB devices skip VPD pages, even when the device supports them (SPC-3 and later), but some of them support VPD, like Cruzer Blade. Signed-off-by:
Marcos Paulo de Souza <marcos.souza.org@gmail.com> Signed-off-by:
-
Deepak Ukey authored
Disabling the SATA drive interface cause kernel panic. When the drive Interface is disabled, device should be deregistered after aborting all pending I/Os. Also changed the port recovery timeout to 10000 ms for PM8006 controller. Signed-off-by:
Deepak Ukey <deepak.ukey@microchip.com> Signed-off-by:
Viswas G <Viswas.G@microchip.com> Reviewed-by:
Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by:
-
Denis Efremov authored
The function sas_wait_eh is declared static and marked EXPORT_SYMBOL, which is at best an odd combination. Because the function is not used outside of the drivers/scsi/libsas/sas_scsi_host.c file it is defined in, this commit removes the EXPORT_SYMBOL() marking. Signed-off-by:
Denis Efremov <efremov@linux.com> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
-
YueHaibing authored
Fix sparse warnings: drivers/scsi/megaraid/megaraid_sas_base.c:271:1: warning: symbol 'megasas_issue_dcmd' was not declared. Should it be static? drivers/scsi/megaraid/megaraid_sas_base.c:2227:6: warning: symbol 'megasas_do_ocr' was not declared. Should it be static? drivers/scsi/megaraid/megaraid_sas_base.c:3194:25: warning: symbol 'megaraid_host_attrs' was not declared. Should it be static? Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
-
Maurizio Lombardi authored
With a possibly faulty disk the following messages may appear in the logs: kernel: sd 0:0:9:0: timing out command, waited 180s kernel: sd 0:0:9:0: timing out command, waited 20s kernel: sd 0:0:9:0: timing out command, waited 20s kernel: sd 0:0:9:0: timing out command, waited 60s kernel: sd 0:0:9:0: timing out command, waited 20s This is not very informative because it's not possible to identify the command that timed out. This patch replaces sdev_printk() with scmd_printk(). Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Reviewed-by:
Ming Lei <ming.lei@redhat.com> Signed-off-by:
-
- 27 Jun, 2019 33 commits
-
-
Martin K. Petersen authored
-
Quinn Tran authored
On session deletion, current qla code would unregister an NVMe session before flushing IOs. This patch would move the unregistration of NVMe session after IO flush. This way FC-NVMe layer would not have to wait for stuck IOs. In addition, qla2xxx would stop accepting new IOs during session deletion. Signed-off-by:
Quinn Tran <qutran@marvell.com> Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Signed-off-by:
-
Quinn Tran authored
This patch uses kref to protect access between fcp_abort path and nvme command and LS command completion path. Stack trace below shows the abort path is accessing stale memory (nvme_private->sp). When command kref reaches 0, nvme_private & srb resource will be disconnected from each other. Any subsequence nvme abort request will not be able to reference the original srb. [ 5631.003998] BUG: unable to handle kernel paging request at 00000010000005d8 [ 5631.004016] IP: [<ffffffffc087df92>] qla_nvme_abort_work+0x22/0x100 [qla2xxx] [ 5631.004086] Workqueue: events qla_nvme_abort_work [qla2xxx] [ 5631.004097] RIP: 0010:[<ffffffffc087df92>] [<ffffffffc087df92>] qla_nvme_abort_work+0x22/0x100 [qla2xxx] [ 5631.004109] Call Trace: [ 5631.004115] [<ffffffffaa4b8174>] ? pwq_dec_nr_in_flight+0x64/0xb0 [ 5631.004117] [<ffffffffaa4b9d4f>] process_one_work+0x17f/0x440 [ 5631.004120] [<ffffffffaa4bade6>] worker_thread+0x126/0x3c0 Signed-off-by:
-
Quinn Tran authored
- on session delete or chip reset, reject all NVME commands. - on NVME command submission error, free srb resource. Signed-off-by:
-
Arun Easi authored
BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffc050d10c>] qla_nvme_unregister_remote_port+0x6c/0xf0 [qla2xxx] PGD 800000084cf41067 PUD 84d288067 PMD 0 Oops: 0000 [#1] SMP Call Trace: [<ffffffff98abcfdf>] process_one_work+0x17f/0x440 [<ffffffff98abdca6>] worker_thread+0x126/0x3c0 [<ffffffff98abdb80>] ? manage_workers.isra.26+0x2a0/0x2a0 [<ffffffff98ac4f81>] kthread+0xd1/0xe0 [<ffffffff98ac4eb0>] ? insert_kthread_work+0x40/0x40 [<ffffffff9918ad37>] ret_from_fork_nospec_begin+0x21/0x21 [<ffffffff98ac4eb0>] ? insert_kthread_work+0x40/0x40 RIP [<ffffffffc050d10c>] qla_nvme_unregister_remote_port+0x6c/0xf0 [qla2xxx] The crash is due to a bad entry in the nvme_rport_list. This list is not protected, and when a remoteport_delete callback is called, driver traverses the list and crashes. Actually, the list could be removed and driver could traverse the main fcport list instead. Fix does exactly that. Signed-off-by:
Arun Easi <aeasi@marvell.com> Signed-off-by:
Himanshu Madhani <hmadhani@redhat.com> Signed-off-by:
-
Chandrakanth Patil authored
Signed-off-by:
Chandrakanth Patil <chandrakanth.patil@broadcom.com> Signed-off-by:
-
Chandrakanth Patil authored
For Aero adapters, driver provides three different performance modes controlled through module parameter named 'perf_mode'. Below are those performance modes: 0: Balanced - Additional high IOPS reply queues will be enabled along with low latency queues. Interrupt coalescing will be enabled only for these high IOPS reply queues. 1: IOPS - No additional high IOPS queues are enabled. Interrupt coalescing will be enabled on all reply queues. 2: Latency - No additional high IOPS queues are enabled. Interrupt coalescing will be disabled on all reply queues. This is a legacy behavior similar to Ventura & Invader Series. Default performance mode settings: - Performance mode set to 'Balanced', if Aero controller is working in 16GT/s PCIe speed. - Performance mode will be set to 'Latency' mode for all other cases. Through module parameter 'perf_mode', user can override default performance mode to desired one. Captured some performance numbers with these performance modes. 4k Random Read IO performance numbers on 24 SAS SSD drives for above three performance modes. Performance data is from Intel Skylake and HGST SS300 (drive model SDLL1DLR400GCCA1). IOPS: ----------------------------------------------------------------------- |perf_mode | qd = 1 | qd = 64 | note | |-------------|--------|---------|------------------------------------- |balanced | 259K | 3061k | Provides max performance numbers | | | | | both on lower QD workload & | | | | | also on higher QD workload | |-------------|--------|---------|------------------------------------- |iops | 220K | 3100k | Provides max performance numbers | | | | | only on higher QD workload. | |-------------|--------|---------|------------------------------------- |latency | 246k | 2226k | Provides good performance numbers | | | | | only on lower QD worklaod. | ----------------------------------------------------------------------- Average Latency: ----------------------------------------------------- |perf_mode | qd = 1 | qd = 64 | |-------------|--------------|----------------------| |balanced | 92.05 usec | 501.12 usec | |-------------|--------------|----------------------| |iops | 108.40 usec | 498.10 usec | |-------------|--------------|----------------------| |latency | 97.10 usec | 689.26 usec | ----------------------------------------------------- Signed-off-by: -
Chandrakanth Patil authored
The driver will use round-robin method for IO submission in batches within the high IOPS queues when the number of in-flight ios on the target device is larger than 8. Otherwise the driver will use low latency reply queues. Signed-off-by:
Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by:
-
Chandrakanth Patil authored
High iops queues are mapped to non-managed IRQs. Set affinity of non-managed irqs to local numa node. Low latency queues are mapped to managed IRQs. Driver reserves some reply queues for high IOPS queues (through pci_alloc_irq_vectors_affinity and .pre_vectors interface). The rest of queues are for low latency. Based on IO workload, driver will decide which group of reply queues (either high IOPS queues or low latency queues) to be used. High IOPS queues will be mapped to local numa node of controller and low latency queues will be mapped to CPUs across numa nodes. In general, high IOPS and low latency queues should fit into 128 reply queues which is the max number of reply queues supported by Aero adapters. Signed-off-by:
-
Chandrakanth Patil authored
Driver should enable interrupt coalescing (during driver load and after Controller Reset) for High IOPS queues by masking appropriate bits in IOC INIT frame. Signed-off-by:
-
Chandrakanth Patil authored
Aero controllers support balanced performance mode through the ability to configure queues with different properties. Reply queues with interrupt coalescing enabled are called "high iops reply queues" and reply queues with interrupt coalescing disabled are called "low latency reply queues". The driver configures a combination of high iops and low latency reply queues if: - HBA is an AERO controller; - MSI-X vectors supported by the HBA is 128; - Total CPU count in the system more than high iops queue count; - Driver is loaded with default max_msix_vectors module parameter; and - System booted in non-kdump mode. Signed-off-by:
-
Chandrakanth Patil authored
Added driver support to allow passthrough MPI toolbox type MFI commands to firmware based on firmware capability. Signed-off-by:
-
Chandrakanth Patil authored
For RAID5/RAID6 volumes configured behind Aero, driver will be doing 64bit division operations on behalf of firmware as controller's ARM CPU is very slow in this division. Later, driver calculates Q-ARM, P-ARM and Log-ARM and passes those values to firmware by writing these values to RAID_CONTEXT. Signed-off-by:
-
Chandrakanth Patil authored
RAID1 PCI bandwidth limit algorithm is not applicable to Aero as it's PCIe Gen4 adapter. Signed-off-by:
-
Chandrakanth Patil authored
Signed-off-by:
-
Chandrakanth Patil authored
Issue: This issue is applicable to scenario when JBOD sequence map is unavailable (memory allocation for JBOD sequence map failed) to driver but feature is supported by firmware. If the driver sends a JBOD IO by not adding 255 (MAX_PHYSICAL_DEVICES - 1) to device ID when underlying firmware supports JBOD sequence map, it will lead to the IO failure. Fix: For JBOD IOs, driver will not use the RAID map to fetch the devhandle if JBOD sequence map is unavailable. Driver will set Devhandle to 0xffff and Target ID to 'device ID + 255 (MAX_PHYSICAL_DEVICES - 1)'. Signed-off-by:
-
Chandrakanth Patil authored
Firmware does not expect FastPath IO sent through Region Lock Bypass queue. Though firmware never exposes such settings when fastpath IO can be sent to RL bypass queue but it's safer to remove dead code which directs fastpath IO to RL Bypass queue. Signed-off-by:
-
Chandrakanth Patil authored
Issue: Under certain conditions, controller goes in FAULT state after IOC INIT fired to firmware. Such Fault can be recovered through controller reset. Fix: In driver probe context, if firmware fault is observed post IOC INIT, driver would do controller reset followed by retry logic for IOC INIT command. Signed-off-by:
-
Chandrakanth Patil authored
Issue: There is possibility of few DCMDs timing out with 'reset_mutex' lock held. As part of DCMD timeout handling, driver calls function megasas_reset_fusion which also tries to acquire same lock 'reset_mutex' and end up with deadlock. Fix: Upon timeout of DCMDs (which are fired with 'reset_mutex' lock held), driver will release 'reset_mutex' before calling OCR function and will acquire lock again after OCR function returns. Signed-off-by:
-
Chandrakanth Patil authored
On PowerPC architecture, calling disable_irq_nosync from IRQ context is not providing the required effect. In current megaraid_sas driver, disable_irq_nosync is being called from IRQ context before enabling IRQ poll. But due to the issue seen on PPC, after IRQ poll disable and legacy ISR is enabled, we are not seeing our ISR getting called. Fix: Call disable_irq from IRQ poll thread context instead of IRQ context. Signed-off-by:
-
Chandrakanth Patil authored
Signed-off-by:
-
Chandrakanth Patil authored
This patch will add support for non-secure Aero adapter PCI IDs. Driver will throw an error message when a non-secure type controller is detected. Purpose of this interface is to avoid interacting with any firmware which is not secured/signed by Broadcom. Any tampering on Firmware component will be detected by hardware and it will be communicated to the driver to avoid any further interaction with that component. Signed-off-by:
-
Chandrakanth Patil authored
Aero adapters provides Atomic Request Descriptor as an alternative method for posting an entry onto a request queue. The posting of an Atomic Request Descriptor is an atomic operation, providing a safe mechanism for multiple processors on the host to post requests without synchronization. This Atomic Request Descriptor format is identical to first 32 bits of Default Request Descriptor and uses only 32 bits. If Aero adapters support Atomic descriptor, driver should use it for posting IOs and DCMDs to firmware. Signed-off-by:
-
Deepak Ukey authored
Added the logic for collecting IOP log respective to event log size. Signed-off-by:
-
Deepak Ukey authored
Added support to read event log size from MPI configuration table and export through sysfs. Signed-off-by:
-
Sreekanth Reddy authored
Enable msix load balance only when combined reply queue mode is disabled on the SAS3 and above generation HBA devices. Earlier msix load balance used to enable if the number of online cpus is greater than the number of MSI-X vectors enabled on the HBA. Combined reply queue mode will be disabled only on those HBA which works in shared resources mode. I.e. on SAS3 HBAs it will be <= 8 and on SAS35 HBA devices it will be <= 16. - Before this patch if system has 256 logical CPUs and HBA exposes 128 MSI-X vectors, driver will enable msix load balance. - After this patch if system has 256 logical CPUs and HBA exposes 128 MSI-X vectors, driver will disable msix load balance. - After this patch if system has 256 logical CPUs and HBA exposes 16 MSI-X vectors (due to combined reply queue mode being off in HW), driver will enable msix load balance. Signed-off-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
-
Sreekanth Reddy authored
Even though 'smp_affinity_enable' module parameter is enabled, if the number of online CPUs is bigger than the number of msix vectors enabled on that HBA, then smp affinity settings should be disabled only for this HBA. But currently the smp affinity setting is disabled globally and hence smp affinity will be disabled for subsequent HBAs even though number of msix vectors enabled for this HBA matches the number of online CPU. To fix this, define a per HBA variable smp_affinity_enable. Initially this variable is initialized with smp_affinity_enable module parameter value. If this HBA has less number of msix vectors configured when compared to number of online cpus, then only this HBA's variable smp_affinity_enable is set to zero. Signed-off-by:
-
Sreekanth Reddy authored
When enabling high iops queues, the driver should use the HBA's configured PCIe link speed instead of looking for the maximum link speed. I.e. enable high iops queues only if Aero/Sea HBA's configured PCIe link speed is set to 16GT/s. Signed-off-by:
-
Sreekanth Reddy authored
Currently default perf_mode is set to 'balanced' on Intel architecture machines and on other machines default perf_mode is set to 'latency' mode. This CPU architecture check is removed and the default perf_mode mode is set to 'balanced' mode on all machines. User can choose the required performance mode using perf_mode module parameter. Signed-off-by:
-
Arthur Simchaev authored
The ufs-tool stable release v1.0 is available at: https://github.com/westerndigitalcorporation/ufs-tool Feedback and bug reports, as always, are welcomed. Signed-off-by:
Arthur Simchaev <Arthur.Simchaev@wdc.com> Signed-off-by:
-
Lin Yi authored
If cb_arg alloc failed, we can't release the struct orig_io_req refcount before we take its refcount. As Saurav said, move the srr_err label down to avoid unnecessary refcount release and nullptr free. Signed-off-by:
Lin Yi <teroincn@163.com> Acked-by:
Saurav Kashyap <skashyap@marvell.com> Signed-off-by:
-
Lin Yi authored
If cb_arg alloc failed, we can't release the struct orig_io_req refcount before we take its refcount. As Saurav said, move the rec_err label down to avoid unnecessary refcount release and nullptr free. Signed-off-by:
-
Saurav Kashyap authored
Update the driver version to 2.12.10. Signed-off-by:
-
