2019-05-19 05:07:45 -07:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2005-04-16 15:20:36 -07:00
|
|
|
config MEGARAID_NEWGEN
|
|
|
|
|
bool "LSI Logic New Generation RAID Device Drivers"
|
2023-05-22 03:50:36 -07:00
|
|
|
depends on PCI && HAS_IOPORT && SCSI
|
2005-04-16 15:20:36 -07:00
|
|
|
help
|
2024-03-11 05:11:27 -07:00
|
|
|
LSI Logic RAID Device Drivers
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
config MEGARAID_MM
|
|
|
|
|
tristate "LSI Logic Management Module (New Driver)"
|
2023-05-22 03:50:36 -07:00
|
|
|
depends on PCI && HAS_IOPORT && SCSI && MEGARAID_NEWGEN
|
2005-04-16 15:20:36 -07:00
|
|
|
help
|
2024-03-11 05:11:27 -07:00
|
|
|
Management Module provides ioctl, sysfs support for LSI Logic
|
|
|
|
|
RAID controllers.
|
|
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called megaraid_mm
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
config MEGARAID_MAILBOX
|
|
|
|
|
tristate "LSI Logic MegaRAID Driver (New Driver)"
|
|
|
|
|
depends on PCI && SCSI && MEGARAID_MM
|
|
|
|
|
help
|
2024-03-11 05:11:27 -07:00
|
|
|
List of supported controllers
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-03-11 05:11:27 -07:00
|
|
|
OEM Product Name VID :DID :SVID:SSID
|
|
|
|
|
--- ------------ ---- ---- ---- ----
|
|
|
|
|
Dell PERC3/QC 101E:1960:1028:0471
|
|
|
|
|
Dell PERC3/DC 101E:1960:1028:0493
|
|
|
|
|
Dell PERC3/SC 101E:1960:1028:0475
|
|
|
|
|
Dell PERC3/Di 1028:000E:1028:0123
|
|
|
|
|
Dell PERC4/SC 1000:1960:1028:0520
|
|
|
|
|
Dell PERC4/DC 1000:1960:1028:0518
|
|
|
|
|
Dell PERC4/QC 1000:0407:1028:0531
|
|
|
|
|
Dell PERC4/Di 1028:000F:1028:014A
|
|
|
|
|
Dell PERC 4e/Si 1028:0013:1028:016c
|
|
|
|
|
Dell PERC 4e/Di 1028:0013:1028:016d
|
|
|
|
|
Dell PERC 4e/Di 1028:0013:1028:016e
|
|
|
|
|
Dell PERC 4e/Di 1028:0013:1028:016f
|
|
|
|
|
Dell PERC 4e/Di 1028:0013:1028:0170
|
|
|
|
|
Dell PERC 4e/DC 1000:0408:1028:0002
|
|
|
|
|
Dell PERC 4e/SC 1000:0408:1028:0001
|
|
|
|
|
LSI MegaRAID SCSI 320-0 1000:1960:1000:A520
|
|
|
|
|
LSI MegaRAID SCSI 320-1 1000:1960:1000:0520
|
|
|
|
|
LSI MegaRAID SCSI 320-2 1000:1960:1000:0518
|
|
|
|
|
LSI MegaRAID SCSI 320-0X 1000:0407:1000:0530
|
|
|
|
|
LSI MegaRAID SCSI 320-2X 1000:0407:1000:0532
|
|
|
|
|
LSI MegaRAID SCSI 320-4X 1000:0407:1000:0531
|
|
|
|
|
LSI MegaRAID SCSI 320-1E 1000:0408:1000:0001
|
|
|
|
|
LSI MegaRAID SCSI 320-2E 1000:0408:1000:0002
|
|
|
|
|
LSI MegaRAID SATA 150-4 1000:1960:1000:4523
|
|
|
|
|
LSI MegaRAID SATA 150-6 1000:1960:1000:0523
|
|
|
|
|
LSI MegaRAID SATA 300-4X 1000:0409:1000:3004
|
|
|
|
|
LSI MegaRAID SATA 300-8X 1000:0409:1000:3008
|
|
|
|
|
INTEL RAID Controller SRCU42X 1000:0407:8086:0532
|
|
|
|
|
INTEL RAID Controller SRCS16 1000:1960:8086:0523
|
|
|
|
|
INTEL RAID Controller SRCU42E 1000:0408:8086:0002
|
|
|
|
|
INTEL RAID Controller SRCZCRX 1000:0407:8086:0530
|
|
|
|
|
INTEL RAID Controller SRCS28X 1000:0409:8086:3008
|
|
|
|
|
INTEL RAID Controller SROMBU42E 1000:0408:8086:3431
|
|
|
|
|
INTEL RAID Controller SROMBU42E 1000:0408:8086:3499
|
|
|
|
|
INTEL RAID Controller SRCU51L 1000:1960:8086:0520
|
|
|
|
|
FSC MegaRAID PCI Express ROMB 1000:0408:1734:1065
|
|
|
|
|
ACER MegaRAID ROMB-2E 1000:0408:1025:004D
|
|
|
|
|
NEC MegaRAID PCI Express ROMB 1000:0408:1033:8287
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-03-11 05:11:27 -07:00
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called megaraid_mbox
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
config MEGARAID_LEGACY
|
|
|
|
|
tristate "LSI Logic Legacy MegaRAID Driver"
|
2023-05-22 03:50:36 -07:00
|
|
|
depends on PCI && HAS_IOPORT && SCSI
|
2005-04-16 15:20:36 -07:00
|
|
|
help
|
2024-03-11 05:11:27 -07:00
|
|
|
This driver supports the LSI MegaRAID 418, 428, 438, 466, 762, 490
|
|
|
|
|
and 467 SCSI host adapters. This driver also support the all U320
|
|
|
|
|
RAID controllers
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-03-11 05:11:27 -07:00
|
|
|
To compile this driver as a module, choose M here: the
|
|
|
|
|
module will be called megaraid
|
2005-09-20 14:46:58 -07:00
|
|
|
|
|
|
|
|
config MEGARAID_SAS
|
|
|
|
|
tristate "LSI Logic MegaRAID SAS RAID Module"
|
|
|
|
|
depends on PCI && SCSI
|
scsi: megaraid_sas: IRQ poll to avoid CPU hard lockups
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: Kashyap Desai <kashyap.desai@broadcom.com>
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-05-07 10:05:35 -07:00
|
|
|
select IRQ_POLL
|
2005-09-20 14:46:58 -07:00
|
|
|
help
|
2024-03-11 05:11:27 -07:00
|
|
|
Module for LSI Logic's SAS based RAID controllers.
|
|
|
|
|
To compile this driver as a module, choose 'm' here.
|
|
|
|
|
Module will be called megaraid_sas
|