Re: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node
On 2020-11-06 16:26, Steven Price wrote: On 06/11/2020 16:17, Shameerali Kolothum Thodi wrote: -Original Message- From: Steven Price [mailto:steven.pr...@arm.com] Sent: 06 November 2020 15:22 To: Shameerali Kolothum Thodi ; linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org; iommu@lists.linux-foundation.org; de...@acpica.org Cc: lorenzo.pieral...@arm.com; j...@8bytes.org; Jonathan Cameron ; Linuxarm ; Guohanjun (Hanjun Guo) ; Sami Mujawar ; robin.mur...@arm.com; wanghuiqiang Subject: Re: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node On 28/10/2020 18:24, Shameerali Kolothum Thodi wrote: Hi Steve, -Original Message- From: Steven Price [mailto:steven.pr...@arm.com] Sent: 28 October 2020 16:44 To: Shameerali Kolothum Thodi ; linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org; iommu@lists.linux-foundation.org; de...@acpica.org Cc: lorenzo.pieral...@arm.com; j...@8bytes.org; Jonathan Cameron ; Linuxarm ; Guohanjun (Hanjun Guo) ; robin.mur...@arm.com; wanghuiqiang ; Sami Mujawar Subject: Re: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node On 27/10/2020 11:26, Shameer Kolothum wrote: The series adds support to IORT RMR nodes specified in IORT Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory ranges that are used by endpoints and require a unity mapping in SMMU. Hi Shameer, I've also been taking a look at RMR, and Sami is helping me get set up so that I can do some testing. We're hoping to be able to test an EFI framebuffer or splash screen - which has the added complication of the unity mapping becoming redundant if a native display driver takes over the display controller. I've looked through your series and the code looks correct to me. Thanks for taking a look and the details. Hopefully I'll be able to give it some testing soon. Cool. Please update once you get a chance run the tests. Hi Shameer, Hi Steve, Just to update on this, for the EFI framebuffer use case I hit exactly the issue that Robin has mentioned in another thread - the RMR is effectively ignored because the display controller isn't being handled by Linux (so there's no device to link it to). Thanks for the update. Here, by "ignored "you meant get_resv_regions() is not called or not? get_resv_regions() isn't called. Right, AIUI the EFI framebuffer "device" pretty much just represents a magic region of RAM, whose existence is based on EFI services - see register_gop_device() - regardless of whether the underlying physical hardware is described in DSDT and IORT such that a tangential iommu_probe_device() call might happen at all. Robin. The splash screen might similarly flicker as the SMMU reset will initially block the traffic before the RMR region is enabled. Does that mean you somehow managed to make the unity mapping but there was flicker during the SMMU reset to unity mapping setup period. Sorry I am trying to understand the exact behavior observed in this case. I haven't yet got this completely working (on the board which I'm testing the display controller doesn't have any existing ACPI bindings). However from what I understand the SMMU reset would block all memory access for the display controller before the RMR region would be setup. I'm going to try to get the display controller working with ACPI so I can test this properly. Steve ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node
On 06/11/2020 16:17, Shameerali Kolothum Thodi wrote: -Original Message- From: Steven Price [mailto:steven.pr...@arm.com] Sent: 06 November 2020 15:22 To: Shameerali Kolothum Thodi ; linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org; iommu@lists.linux-foundation.org; de...@acpica.org Cc: lorenzo.pieral...@arm.com; j...@8bytes.org; Jonathan Cameron ; Linuxarm ; Guohanjun (Hanjun Guo) ; Sami Mujawar ; robin.mur...@arm.com; wanghuiqiang Subject: Re: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node On 28/10/2020 18:24, Shameerali Kolothum Thodi wrote: Hi Steve, -Original Message- From: Steven Price [mailto:steven.pr...@arm.com] Sent: 28 October 2020 16:44 To: Shameerali Kolothum Thodi ; linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org; iommu@lists.linux-foundation.org; de...@acpica.org Cc: lorenzo.pieral...@arm.com; j...@8bytes.org; Jonathan Cameron ; Linuxarm ; Guohanjun (Hanjun Guo) ; robin.mur...@arm.com; wanghuiqiang ; Sami Mujawar Subject: Re: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node On 27/10/2020 11:26, Shameer Kolothum wrote: The series adds support to IORT RMR nodes specified in IORT Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory ranges that are used by endpoints and require a unity mapping in SMMU. Hi Shameer, I've also been taking a look at RMR, and Sami is helping me get set up so that I can do some testing. We're hoping to be able to test an EFI framebuffer or splash screen - which has the added complication of the unity mapping becoming redundant if a native display driver takes over the display controller. I've looked through your series and the code looks correct to me. Thanks for taking a look and the details. Hopefully I'll be able to give it some testing soon. Cool. Please update once you get a chance run the tests. Hi Shameer, Hi Steve, Just to update on this, for the EFI framebuffer use case I hit exactly the issue that Robin has mentioned in another thread - the RMR is effectively ignored because the display controller isn't being handled by Linux (so there's no device to link it to). Thanks for the update. Here, by "ignored "you meant get_resv_regions() is not called or not? get_resv_regions() isn't called. The splash screen might similarly flicker as the SMMU reset will initially block the traffic before the RMR region is enabled. Does that mean you somehow managed to make the unity mapping but there was flicker during the SMMU reset to unity mapping setup period. Sorry I am trying to understand the exact behavior observed in this case. I haven't yet got this completely working (on the board which I'm testing the display controller doesn't have any existing ACPI bindings). However from what I understand the SMMU reset would block all memory access for the display controller before the RMR region would be setup. I'm going to try to get the display controller working with ACPI so I can test this properly. Steve ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node
> -Original Message- > From: Steven Price [mailto:steven.pr...@arm.com] > Sent: 06 November 2020 15:22 > To: Shameerali Kolothum Thodi ; > linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org; > iommu@lists.linux-foundation.org; de...@acpica.org > Cc: lorenzo.pieral...@arm.com; j...@8bytes.org; Jonathan Cameron > ; Linuxarm ; > Guohanjun (Hanjun Guo) ; Sami Mujawar > ; robin.mur...@arm.com; wanghuiqiang > > Subject: Re: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node > > On 28/10/2020 18:24, Shameerali Kolothum Thodi wrote: > > Hi Steve, > > > >> -Original Message- > >> From: Steven Price [mailto:steven.pr...@arm.com] > >> Sent: 28 October 2020 16:44 > >> To: Shameerali Kolothum Thodi ; > >> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org; > >> iommu@lists.linux-foundation.org; de...@acpica.org > >> Cc: lorenzo.pieral...@arm.com; j...@8bytes.org; Jonathan Cameron > >> ; Linuxarm ; > >> Guohanjun (Hanjun Guo) ; > robin.mur...@arm.com; > >> wanghuiqiang ; Sami Mujawar > >> > >> Subject: Re: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node > >> > >> On 27/10/2020 11:26, Shameer Kolothum wrote: > >>> The series adds support to IORT RMR nodes specified in IORT > >>> Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory > >>> ranges that are used by endpoints and require a unity mapping > >>> in SMMU. > >> > >> Hi Shameer, > >> > >> I've also been taking a look at RMR, and Sami is helping me get set up > >> so that I can do some testing. We're hoping to be able to test an EFI > >> framebuffer or splash screen - which has the added complication of the > >> unity mapping becoming redundant if a native display driver takes over > >> the display controller. > >> > >> I've looked through your series and the code looks correct to me. > > > > Thanks for taking a look and the details. > > > >> Hopefully I'll be able to give it some testing soon. > > > > Cool. Please update once you get a chance run the tests. > > Hi Shameer, Hi Steve, > Just to update on this, for the EFI framebuffer use case I hit exactly > the issue that Robin has mentioned in another thread - the RMR is > effectively ignored because the display controller isn't being handled > by Linux (so there's no device to link it to). Thanks for the update. Here, by "ignored "you meant get_resv_regions() is not called or not? The splash screen might > similarly flicker as the SMMU reset will initially block the traffic > before the RMR region is enabled. Does that mean you somehow managed to make the unity mapping but there was flicker during the SMMU reset to unity mapping setup period. Sorry I am trying to understand the exact behavior observed in this case. Thanks, Shameer ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node
On 28/10/2020 18:24, Shameerali Kolothum Thodi wrote: Hi Steve, -Original Message- From: Steven Price [mailto:steven.pr...@arm.com] Sent: 28 October 2020 16:44 To: Shameerali Kolothum Thodi ; linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org; iommu@lists.linux-foundation.org; de...@acpica.org Cc: lorenzo.pieral...@arm.com; j...@8bytes.org; Jonathan Cameron ; Linuxarm ; Guohanjun (Hanjun Guo) ; robin.mur...@arm.com; wanghuiqiang ; Sami Mujawar Subject: Re: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node On 27/10/2020 11:26, Shameer Kolothum wrote: The series adds support to IORT RMR nodes specified in IORT Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory ranges that are used by endpoints and require a unity mapping in SMMU. Hi Shameer, I've also been taking a look at RMR, and Sami is helping me get set up so that I can do some testing. We're hoping to be able to test an EFI framebuffer or splash screen - which has the added complication of the unity mapping becoming redundant if a native display driver takes over the display controller. I've looked through your series and the code looks correct to me. Thanks for taking a look and the details. Hopefully I'll be able to give it some testing soon. Cool. Please update once you get a chance run the tests. Hi Shameer, Just to update on this, for the EFI framebuffer use case I hit exactly the issue that Robin has mentioned in another thread - the RMR is effectively ignored because the display controller isn't being handled by Linux (so there's no device to link it to). The splash screen might similarly flicker as the SMMU reset will initially block the traffic before the RMR region is enabled. Steve ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node
Hi Steve, > -Original Message- > From: Steven Price [mailto:steven.pr...@arm.com] > Sent: 28 October 2020 16:44 > To: Shameerali Kolothum Thodi ; > linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org; > iommu@lists.linux-foundation.org; de...@acpica.org > Cc: lorenzo.pieral...@arm.com; j...@8bytes.org; Jonathan Cameron > ; Linuxarm ; > Guohanjun (Hanjun Guo) ; robin.mur...@arm.com; > wanghuiqiang ; Sami Mujawar > > Subject: Re: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node > > On 27/10/2020 11:26, Shameer Kolothum wrote: > > The series adds support to IORT RMR nodes specified in IORT > > Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory > > ranges that are used by endpoints and require a unity mapping > > in SMMU. > > Hi Shameer, > > I've also been taking a look at RMR, and Sami is helping me get set up > so that I can do some testing. We're hoping to be able to test an EFI > framebuffer or splash screen - which has the added complication of the > unity mapping becoming redundant if a native display driver takes over > the display controller. > > I've looked through your series and the code looks correct to me. Thanks for taking a look and the details. > Hopefully I'll be able to give it some testing soon. Cool. Please update once you get a chance run the tests. Thanks, Shameer > Thanks, > > Steve > > > We have faced issues with 3408iMR RAID controller cards which > > fail to boot when SMMU is enabled. This is because these controllers > > make use of host memory for various caching related purposes and when > > SMMU is enabled the iMR firmware fails to access these memory regions > > as there is no mapping for them. IORT RMR provides a way for UEFI to > > describe and report these memory regions so that the kernel can make > > a unity mapping for these in SMMU. > > > > RFC because, Patch #1 is to update the actbl2.h and should be done > > through acpica update. I have send out a pull request[1] for that. > > > > Tests: > > > > With a UEFI, that reports the RMR for the dev, > > > > [16F0h 5872 1] Type : 06 > > [16F1h 5873 2] Length : 007C > > [16F3h 5875 1] Revision : 00 > > [1038h 0056 2] Reserved : > > [1038h 0056 2] Identifier : > > [16F8h 5880 4]Mapping Count : 0001 > > [16FCh 5884 4] Mapping Offset : 0040 > > > > [1700h 5888 4]Number of RMR Descriptors : 0002 > > [1704h 5892 4]RMR Descriptor Offset : 0018 > > > > [1708h 5896 8] Base Address of RMR : E640 > > [1710h 5904 8]Length of RMR : 0010 > > [1718h 5912 4] Reserved : > > > > [171Ch 5916 8] Base Address of RMR : 27B0 > > [1724h 5924 8]Length of RMR : 00C0 > > [172Ch 5932 4] Reserved : > > > > [1730h 5936 4] Input base : > > [1734h 5940 4] ID Count : 0001 > > [1738h 5944 4] Output Base : 0003 > > [173Ch 5948 4] Output Reference : 0064 > > [1740h 5952 4]Flags (decoded below) : 0001 > > Single Mapping : 1 > > ... > > > > Without the series the RAID controller initilization fails as > > below, > > > > ... > > [ 12.631117] megaraid_sas :03:00.0: FW supports sync > cache: Yes > > [ 12.637360] megaraid_sas :03:00.0: megasas_disable_intr_fusion is > called outbound_intr_mask:0x4009 > > [ 18.776377] megaraid_sas :03:00.0: Init cmd return status FAILED > for SCSI host 0 > > [ 23.019383] megaraid_sas :03:00.0: Waiting for FW to come to > ready state > > [ 106.684281] megaraid_sas :03:00.0: FW in FAULT state, Fault > code:0x1 subcode:0x0 func:megasas_transition_to_ready > > [ 106.695186] megaraid_sas :03:00.0: System Register set: > > [ 106.889787] megaraid_sas :03:00.0: Failed to transition controller to > ready for scsi0. > > [ 106.910475] megaraid_sas :03:00.0: Failed from megasas_init_fw > 6407 > > estuary:/$ > > > > With the series, now the kernel has direct mapping for the dev as > > below, > > > > estuary:/$ cat /sys/kernel/iommu_groups/0/reserved_regions > > 0x0800 0x080f msi > > 0x27b0 0x286f d
Re: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node
On 27/10/2020 11:26, Shameer Kolothum wrote: The series adds support to IORT RMR nodes specified in IORT Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory ranges that are used by endpoints and require a unity mapping in SMMU. Hi Shameer, I've also been taking a look at RMR, and Sami is helping me get set up so that I can do some testing. We're hoping to be able to test an EFI framebuffer or splash screen - which has the added complication of the unity mapping becoming redundant if a native display driver takes over the display controller. I've looked through your series and the code looks correct to me. Hopefully I'll be able to give it some testing soon. Thanks, Steve We have faced issues with 3408iMR RAID controller cards which fail to boot when SMMU is enabled. This is because these controllers make use of host memory for various caching related purposes and when SMMU is enabled the iMR firmware fails to access these memory regions as there is no mapping for them. IORT RMR provides a way for UEFI to describe and report these memory regions so that the kernel can make a unity mapping for these in SMMU. RFC because, Patch #1 is to update the actbl2.h and should be done through acpica update. I have send out a pull request[1] for that. Tests: With a UEFI, that reports the RMR for the dev, [16F0h 5872 1] Type : 06 [16F1h 5873 2] Length : 007C [16F3h 5875 1] Revision : 00 [1038h 0056 2] Reserved : [1038h 0056 2] Identifier : [16F8h 5880 4]Mapping Count : 0001 [16FCh 5884 4] Mapping Offset : 0040 [1700h 5888 4]Number of RMR Descriptors : 0002 [1704h 5892 4]RMR Descriptor Offset : 0018 [1708h 5896 8] Base Address of RMR : E640 [1710h 5904 8]Length of RMR : 0010 [1718h 5912 4] Reserved : [171Ch 5916 8] Base Address of RMR : 27B0 [1724h 5924 8]Length of RMR : 00C0 [172Ch 5932 4] Reserved : [1730h 5936 4] Input base : [1734h 5940 4] ID Count : 0001 [1738h 5944 4] Output Base : 0003 [173Ch 5948 4] Output Reference : 0064 [1740h 5952 4]Flags (decoded below) : 0001 Single Mapping : 1 ... Without the series the RAID controller initilization fails as below, ... [ 12.631117] megaraid_sas :03:00.0: FW supports sync cache: Yes [ 12.637360] megaraid_sas :03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x4009 [ 18.776377] megaraid_sas :03:00.0: Init cmd return status FAILED for SCSI host 0 [ 23.019383] megaraid_sas :03:00.0: Waiting for FW to come to ready state [ 106.684281] megaraid_sas :03:00.0: FW in FAULT state, Fault code:0x1 subcode:0x0 func:megasas_transition_to_ready [ 106.695186] megaraid_sas :03:00.0: System Register set: [ 106.889787] megaraid_sas :03:00.0: Failed to transition controller to ready for scsi0. [ 106.910475] megaraid_sas :03:00.0: Failed from megasas_init_fw 6407 estuary:/$ With the series, now the kernel has direct mapping for the dev as below, estuary:/$ cat /sys/kernel/iommu_groups/0/reserved_regions 0x0800 0x080f msi 0x27b0 0x286f direct 0xe640 0xe64f direct estuary:/$ [ 12.254318] megaraid_sas :03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x4009 [ 12.739089] megaraid_sas :03:00.0: FW provided supportMaxExtLDs: 0 max_lds: 32 [ 12.746628] megaraid_sas :03:00.0: controller type : iMR(0MB) [ 12.752694] megaraid_sas :03:00.0: Online Controller Reset(OCR) : Enabled [ 12.759798] megaraid_sas :03:00.0: Secure JBOD support : Yes [ 12.765778] megaraid_sas :03:00.0: NVMe passthru support : Yes [ 12.771931] megaraid_sas :03:00.0: FW provided TM TaskAbort/Reset timeou: 6 secs/60 secs [ 12.780503] megaraid_sas :03:00.0: JBOD sequence map support : Yes [ 12.787000] megaraid_sas :03:00.0: PCI Lane Margining support: No [ 12.819179] megaraid_sas :03:00.0: NVME page size: (4096) [ 12.825672] megaraid_sas :03:00.0: megasas_enable_intr_fusion is called outbound_intr_mask:0x4000 [ 12.835199] megaraid_sas :03:00.0: INIT adapter done [ 12.873932] megaraid_sas :03:00.0: pci id: (0x1000)/(0x0017)/(0x19e5)/(0xd213) [ 12.881644] megaraid_sas :03:00.0: unevenspan support: no [ 12.887451] megaraid_sas :03:00.0: firmware crash dump : no [ 12.893344] megaraid_sas :03:00.0: JBOD sequence map : enabled RAID controller init is now success and
[RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node
The series adds support to IORT RMR nodes specified in IORT Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory ranges that are used by endpoints and require a unity mapping in SMMU. We have faced issues with 3408iMR RAID controller cards which fail to boot when SMMU is enabled. This is because these controllers make use of host memory for various caching related purposes and when SMMU is enabled the iMR firmware fails to access these memory regions as there is no mapping for them. IORT RMR provides a way for UEFI to describe and report these memory regions so that the kernel can make a unity mapping for these in SMMU. RFC because, Patch #1 is to update the actbl2.h and should be done through acpica update. I have send out a pull request[1] for that. Tests: With a UEFI, that reports the RMR for the dev, [16F0h 5872 1] Type : 06 [16F1h 5873 2] Length : 007C [16F3h 5875 1] Revision : 00 [1038h 0056 2] Reserved : [1038h 0056 2] Identifier : [16F8h 5880 4]Mapping Count : 0001 [16FCh 5884 4] Mapping Offset : 0040 [1700h 5888 4]Number of RMR Descriptors : 0002 [1704h 5892 4]RMR Descriptor Offset : 0018 [1708h 5896 8] Base Address of RMR : E640 [1710h 5904 8]Length of RMR : 0010 [1718h 5912 4] Reserved : [171Ch 5916 8] Base Address of RMR : 27B0 [1724h 5924 8]Length of RMR : 00C0 [172Ch 5932 4] Reserved : [1730h 5936 4] Input base : [1734h 5940 4] ID Count : 0001 [1738h 5944 4] Output Base : 0003 [173Ch 5948 4] Output Reference : 0064 [1740h 5952 4]Flags (decoded below) : 0001 Single Mapping : 1 ... Without the series the RAID controller initilization fails as below, ... [ 12.631117] megaraid_sas :03:00.0: FW supports sync cache: Yes [ 12.637360] megaraid_sas :03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x4009 [ 18.776377] megaraid_sas :03:00.0: Init cmd return status FAILED for SCSI host 0 [ 23.019383] megaraid_sas :03:00.0: Waiting for FW to come to ready state [ 106.684281] megaraid_sas :03:00.0: FW in FAULT state, Fault code:0x1 subcode:0x0 func:megasas_transition_to_ready [ 106.695186] megaraid_sas :03:00.0: System Register set: [ 106.889787] megaraid_sas :03:00.0: Failed to transition controller to ready for scsi0. [ 106.910475] megaraid_sas :03:00.0: Failed from megasas_init_fw 6407 estuary:/$ With the series, now the kernel has direct mapping for the dev as below, estuary:/$ cat /sys/kernel/iommu_groups/0/reserved_regions 0x0800 0x080f msi 0x27b0 0x286f direct 0xe640 0xe64f direct estuary:/$ [ 12.254318] megaraid_sas :03:00.0: megasas_disable_intr_fusion is called outbound_intr_mask:0x4009 [ 12.739089] megaraid_sas :03:00.0: FW provided supportMaxExtLDs: 0 max_lds: 32 [ 12.746628] megaraid_sas :03:00.0: controller type : iMR(0MB) [ 12.752694] megaraid_sas :03:00.0: Online Controller Reset(OCR) : Enabled [ 12.759798] megaraid_sas :03:00.0: Secure JBOD support : Yes [ 12.765778] megaraid_sas :03:00.0: NVMe passthru support : Yes [ 12.771931] megaraid_sas :03:00.0: FW provided TM TaskAbort/Reset timeou: 6 secs/60 secs [ 12.780503] megaraid_sas :03:00.0: JBOD sequence map support : Yes [ 12.787000] megaraid_sas :03:00.0: PCI Lane Margining support: No [ 12.819179] megaraid_sas :03:00.0: NVME page size: (4096) [ 12.825672] megaraid_sas :03:00.0: megasas_enable_intr_fusion is called outbound_intr_mask:0x4000 [ 12.835199] megaraid_sas :03:00.0: INIT adapter done [ 12.873932] megaraid_sas :03:00.0: pci id:
