mirrors
/
linux-stable
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
1
0
Fork 0
Code Issues Releases Wiki Activity
linux-stable/drivers/scsi/megaraid/Kconfig.megaraid

88 lines
3.0 KiB
Plaintext
Raw Normal View History

treewide: Add SPDX license identifier - Makefile/Kconfig Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-19 12:07:45 +00:00
# SPDX-License-Identifier: GPL-2.0-only
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
config MEGARAID_NEWGEN
bool "LSI Logic New Generation RAID Device Drivers"
scsi: Add HAS_IOPORT dependencies In a future patch HAS_IOPORT=n will result in inb()/outb() and friends not being declared. We thus need to add HAS_IOPORT as dependency for those drivers using them. Co-developed-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Link: https://lore.kernel.org/r/20230522105049.1467313-32-schnelle@linux.ibm.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2023-05-22 10:50:36 +00:00
depends on PCI && HAS_IOPORT && SCSI
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
help
LSI Logic RAID Device Drivers
config MEGARAID_MM
tristate "LSI Logic Management Module (New Driver)"
scsi: Add HAS_IOPORT dependencies In a future patch HAS_IOPORT=n will result in inb()/outb() and friends not being declared. We thus need to add HAS_IOPORT as dependency for those drivers using them. Co-developed-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Link: https://lore.kernel.org/r/20230522105049.1467313-32-schnelle@linux.ibm.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2023-05-22 10:50:36 +00:00
depends on PCI && HAS_IOPORT && SCSI && MEGARAID_NEWGEN
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
help
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
config MEGARAID_MAILBOX
tristate "LSI Logic MegaRAID Driver (New Driver)"
depends on PCI && SCSI && MEGARAID_MM
help
List of supported controllers
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
To compile this driver as a module, choose M here: the
module will be called megaraid_mbox
config MEGARAID_LEGACY
tristate "LSI Logic Legacy MegaRAID Driver"
scsi: Add HAS_IOPORT dependencies In a future patch HAS_IOPORT=n will result in inb()/outb() and friends not being declared. We thus need to add HAS_IOPORT as dependency for those drivers using them. Co-developed-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Link: https://lore.kernel.org/r/20230522105049.1467313-32-schnelle@linux.ibm.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2023-05-22 10:50:36 +00:00
depends on PCI && HAS_IOPORT && SCSI
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 22:20:36 +00:00
help
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
To compile this driver as a module, choose M here: the
module will be called megaraid
[SCSI] MegaRAID SAS RAID: new driver Signed-off-by: Sreenivas Bagalkote <Sreenivas.Bagalkote@lsil.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-09-20 21:46:58 +00: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 17:05:35 +00:00
select IRQ_POLL
[SCSI] MegaRAID SAS RAID: new driver Signed-off-by: Sreenivas Bagalkote <Sreenivas.Bagalkote@lsil.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-09-20 21:46:58 +00:00
help
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