New: DMA Read on Marvell 88SE9128 fails when Intel's IOMMU is on
A message that is not in the archive (sent off-list or not yet received): [email protected]/
A message that is not in the archive (sent off-list or not yet received): bug-42679-27-3bo0kxnWaOQUvHkbgXJLS5sdmw4N0Rt+2LY78lusg7I@public.gmane.org/
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 1 line · On Sat, 28 Jan 2012 17:55:38 GMT bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq…
I don't know if this is a SATA issue or intel-iommu. Could you guys please take a look?
Quoted 60 lines
Summary: DMA Read on Marvell 88SE9128 fails when Intel's IOMMU
is on
Product: Memory Management
Version: 2.5
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: akpm-de/[email protected]
ReportedBy: [email protected]
Regression: NoCreated an attachment (id=72217)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72217)
Output of `dmesg' commandI have a MSI Z68A-GD80 B3 motherboard and when I try to enable Intel's IOMMU (kernel booted with intel_iommu=on), integrated Marvell 88SE9128 SATA controller doesn't work.
To reproduce:
1. Compile and prepare kernel with Intel IOMMU support enabled (CONFIG_INTEL_IOMMU=y).
2. Reboot the computer.
3. Enter BIOS and enable VT-d.
4. Boot the kernel with intel_iommu=on parameter.Right after boot, kernel reports the following errors (SATA controller is at 0b:00.0):
[ 2.639774] DRHD: handling fault status reg 3 [ 2.639782] DMAR:[DMA Read] Request device [0b:00.1] fault addr fff00000 [ 2.639783] DMAR:[fault reason 02] Present bit in context entry is clearAfter a while these entries appear:
[ 7.625837] ata14.00: qc timeout (cmd 0xa1) [ 7.628341] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 7.935483] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 17.908407] ata14.00: qc timeout (cmd 0xa1) [ 17.910935] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 17.912276] ata14: limiting SATA link speed to 1.5 Gbps [ 18.219077] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 48.134607] ata14.00: qc timeout (cmd 0xa1) [ 48.137508] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 48.444646] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310)When there is a disk connected to the controller it does not work. When there are none, computer starts normally, apart from the huge lag caused by, presumably, probing the device.
Since this is the secondary controller on these motherboards, to eliminate those symptoms you can just plug disk in one of available ports of the built-in Intel SATA controller and disable Marvell's one using BIOS. The other work-around, if you need to use eSATA capabilities of the latter, is to disable VT-d techonology also using BIOS.
A message that is not in the archive (sent off-list or not yet received): 20120130125934.7971c815.akpm-de/[email protected]
Quoted 74 lines · Andrew Morton
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 1 line · On Sat, 28 Jan 2012 17:55:38 GMT bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq…
I don't know if this is a SATA issue or intel-iommu. Could you guys please take a look?
Quoted 55 lines
Summary: DMA Read on Marvell 88SE9128 fails when Intel's IOMMU
is on
Product: Memory Management
Version: 2.5
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: akpm-de/[email protected]
ReportedBy: [email protected]
Regression: NoCreated an attachment (id=72217)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72217)
Output of `dmesg' commandI have a MSI Z68A-GD80 B3 motherboard and when I try to enable Intel's IOMMU (kernel booted with intel_iommu=on), integrated Marvell 88SE9128 SATA controller doesn't work.
To reproduce:
1. Compile and prepare kernel with Intel IOMMU support enabled (CONFIG_INTEL_IOMMU=y).
2. Reboot the computer.
3. Enter BIOS and enable VT-d.
4. Boot the kernel with intel_iommu=on parameter.Right after boot, kernel reports the following errors (SATA controller is at 0b:00.0):
[ 2.639774] DRHD: handling fault status reg 3 [ 2.639782] DMAR:[DMA Read] Request device [0b:00.1] fault addr fff00000 [ 2.639783] DMAR:[fault reason 02] Present bit in context entry is clearAfter a while these entries appear:
[ 7.625837] ata14.00: qc timeout (cmd 0xa1) [ 7.628341] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 7.935483] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 17.908407] ata14.00: qc timeout (cmd 0xa1) [ 17.910935] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 17.912276] ata14: limiting SATA link speed to 1.5 Gbps [ 18.219077] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 48.134607] ata14.00: qc timeout (cmd 0xa1) [ 48.137508] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 48.444646] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310)When there is a disk connected to the controller it does not work. When there are none, computer starts normally, apart from the huge lag caused by, presumably, probing the device.
Quoted 5 lines
Since this is the secondary controller on these motherboards, to eliminate those symptoms you can just plug disk in one of available ports of the built-in Intel SATA controller and disable Marvell's one using BIOS. The other work-around, if you need to use eSATA capabilities of the latter, is to disable VT-d techonology also using BIOS.
Quoted 4 lines
_______________________________________________
iommu mailing list iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Well, the lspci dump in the bugzilla report doesn't show a device w/BDF=0b:00.1; so, if the SATA device (which is 0b:00.0) is spitting out 0b:00.1 as the source of any of its DMA packets, the IOMMU will fault on it, since 0b:00.1 didn't request DMA mappings (0b:00.0 did).
I semi-recall someone else reporting this 'feature' on this list. Wonder if pci-quirk has to filter this case (0b:00.0 on this system means map for 0b:00.0 & 0b:00.1 -- ick!)
do another lspci -vvv to ensure that 0b:00.1 wasn't excluded in the list. if it doesn't exist, then the problem is the SATA device using an unknown/unrecognized BDF of 0b:00.1
Quoted 101 lines · Don Dutile
Quoted 84 lines · Andrew Morton
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).Quoted 1 line · On Sat, 28 Jan 2012 17:55:38 GMT [email protected] wrote:
I don't know if this is a SATA issue or intel-iommu. Could you guys please take a look?
Quoted 61 lines
Summary: DMA Read on Marvell 88SE9128 fails when Intel's
IOMMU
is on
Product: Memory Management
Version: 2.5
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: NoCreated an attachment (id=72217)
--> (https://bugzilla.kernel.org/attachment.cgi?id=72217)
Output of `dmesg' commandI have a MSI Z68A-GD80 B3 motherboard and when I try to enable Intel's IOMMU
(kernel booted with intel_iommu=on), integrated Marvell 88SE9128 SATA controller doesn't work.To reproduce:
1. Compile and prepare kernel with Intel IOMMU support enabled (CONFIG_INTEL_IOMMU=y).
2. Reboot the computer.
3. Enter BIOS and enable VT-d.
4. Boot the kernel with intel_iommu=on parameter.Right after boot, kernel reports the following errors (SATA controller is at
0b:00.0):[ 2.639774] DRHD: handling fault status reg 3 [ 2.639782] DMAR:[DMA Read] Request device [0b:00.1] fault addr fff00000 [ 2.639783] DMAR:[fault reason 02] Present bit in context entry isclear
After a while these entries appear:
[ 7.625837] ata14.00: qc timeout (cmd 0xa1) [ 7.628341] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 7.935483] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 17.908407] ata14.00: qc timeout (cmd 0xa1) [ 17.910935] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 17.912276] ata14: limiting SATA link speed to 1.5 Gbps [ 18.219077] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 48.134607] ata14.00: qc timeout (cmd 0xa1) [ 48.137508] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 48.444646] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310)When there is a disk connected to the controller it does not work. When there
are none, computer starts normally, apart from the huge lag caused by, presumably, probing the device.Quoted 8 lines
Since this is the secondary controller on these motherboards, to eliminate
those symptoms you can just plug disk in one of available ports of the built-in
Intel SATA controller and disable Marvell's one using BIOS. The other work-around, if you need to use eSATA capabilities of the latter, is to disable
VT-d techonology also using BIOS.Quoted 4 lines
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommuWell, the lspci dump in the bugzilla report doesn't show a device w/BDF=0b:00.1;
so, if the SATA device (which is 0b:00.0) is spitting out 0b:00.1 as the source
of any of its DMA packets, the IOMMU will fault on it, since 0b:00.1 didn't
request DMA mappings (0b:00.0 did).
I semi-recall someone else reporting this 'feature' on this list. Wonder if pci-quirk has to filter this case (0b:00.0 on this system means map for 0b:00.0 & 0b:00.1 -- ick!)
Quoted 4 lines
do another lspci -vvv to ensure that 0b:00.1 wasn't excluded in the list. if it doesn't exist, then the problem is the SATA device using an unknown/unrecognized
BDF of 0b:00.1
Yep, that's correct. I enabled all integrated peripherals on my motherboard and there were still no entries with BDF 0b:00.1 in lspci -vvv output. Should I take this problem to MSI then?
Paweł
Quoted 12 lines · * Paweł Żak ([email protected]) wrote:
Quoted 11 lines · Don Dutile
Well, the lspci dump in the bugzilla report doesn't show a device w/BDF=0b:00.1;
so, if the SATA device (which is 0b:00.0) is spitting out 0b:00.1 as the source
of any of its DMA packets, the IOMMU will fault on it, since 0b:00.1 didn't
request DMA mappings (0b:00.0 did).
I semi-recall someone else reporting this 'feature' on this list. Wonder if pci-quirk has to filter this case (0b:00.0 on this system means map for 0b:00.0 & 0b:00.1 -- ick!)
Quoted 8 lines
Quoted 4 lines
do another lspci -vvv to ensure that 0b:00.1 wasn't excluded in the list. if it doesn't exist, then the problem is the SATA device using an unknown/unrecognized
BDF of 0b:00.1Yep, that's correct. I enabled all integrated peripherals on my motherboard and there were still no entries with BDF 0b:00.1 in lspci -vvv output. Should I take this problem to MSI then?
Yeah, something is not right. Is there any BIOS control over that device?
thanks,
-chris
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Quoted 21 lines · Chris Wright
Quoted 20 lines · * Paweł Żak ([email protected]) wrote:
Quoted 9 lines · Don Dutile
Well, the lspci dump in the bugzilla report doesn't show a device w/BDF=0b:00.1;
so, if the SATA device (which is 0b:00.0) is spitting out 0b:00.1 as the source
of any of its DMA packets, the IOMMU will fault on it, since 0b:00.1 didn't
request DMA mappings (0b:00.0 did).
I semi-recall someone else reporting this 'feature' on this list. Wonder if pci-quirk has to filter this case (0b:00.0 on this systemmeans
Quoted 3 lines
map for 0b:00.0 & 0b:00.1 -- ick!)
do another lspci -vvv to ensure that 0b:00.1 wasn't excluded in the
list.
Quoted 3 lines
if it doesn't exist, then the problem is the SATA device using an unknown/unrecognized
BDF of 0b:00.1
Quoted 6 lines
Quoted 3 lines
Yep, that's correct. I enabled all integrated peripherals on my motherboard and there were still no entries with BDF 0b:00.1 in lspci -vvv output. Should I take this problem to MSI then?
Yeah, something is not right. Is there any BIOS control over that device?
As far as the BIOS is concerned I can only switch between:
- disabled,
- AHCI mode,
- IDE mode.
The problem occurs in both IDE and AHCI modes.
Apart from that I am also able to bring up RAID setup window for this controller, right after turning the computer on, but since there are no disks connected to it there's nothing I can alter.
Paweł
Quoted 9 lines · On Tue, 31 Jan 2012, Chris Wright <chrisw <at> sous-sol.org> wrote:
Quoted 9 lines
Quoted 9 lines
Well, the lspci dump in the bugzilla report doesn't show a device w/BDF=0b:00.1;
so, if the SATA device (which is 0b:00.0) is spitting out 0b:00.1 as the source
of any of its DMA packets, the IOMMU will fault on it, since 0b:00.1 didn't
request DMA mappings (0b:00.0 did).
I semi-recall someone else reporting this 'feature' on this list. Wonder if pci-quirk has to filter this case (0b:00.0 on this system
Quoted 3 lines
Quoted 3 lines
means
Quoted 2 lines
map for 0b:00.0 & 0b:00.1 -- ick!)
It would seem that there are multiple Marvell 88SE91xx controllers that use xx:00.0 and xx:00.1 and only report xx:00.0. I've got the same issue on a 88SE9172 and can't simply move to a different controller without buying more hardware. Besides, this should work ;)
Is this an issue of a missing entry in some ACPI table?
It's been suggested that a pci-quirk could handle this by mapping both the .0 and .1 entry when the .0 shows up, but what isn't clear to me is where this should be done. Is it a case of setting the "present" bit for an existing context entry, or adding an additional context entry?
AC.