* Re: [Bug 42679] New: DMA Read on Marvell 88SE9128 fails when Intel's IOMMU is on
[not found] ` <bug-42679-27-3bo0kxnWaOQUvHkbgXJLS5sdmw4N0Rt+2LY78lusg7I@public.gmane.org/>
@ 2012-01-30 20:59 ` Andrew Morton
[not found] ` <20120130125934.7971c815.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2012-01-30 20:59 UTC (permalink / raw)
To: linux-ide-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
David Woodhouse
Cc: pawel.zaq-Re5JQEeQqe8AvxtiuMwx3w,
bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Sat, 28 Jan 2012 17:55:38 GMT
bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=42679
I don't know if this is a SATA issue or intel-iommu. Could you guys
please take a look?
> 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/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org
> ReportedBy: pawel.zaq-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> Regression: No
>
>
> Created an attachment (id=72217)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=72217)
> Output of `dmesg' command
>
> I 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 clear
>
> 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.
>
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bug 42679] New: DMA Read on Marvell 88SE9128 fails when Intel's IOMMU is on
[not found] ` <20120130125934.7971c815.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
@ 2012-01-30 21:41 ` Don Dutile
2012-01-30 22:13 ` Paweł Żak
0 siblings, 1 reply; 6+ messages in thread
From: Don Dutile @ 2012-01-30 21:41 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-ide-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r, David Woodhouse,
pawel.zaq-Re5JQEeQqe8AvxtiuMwx3w
On 01/30/2012 03:59 PM, Andrew Morton wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Sat, 28 Jan 2012 17:55:38 GMT
> bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=42679
>
> I don't know if this is a SATA issue or intel-iommu. Could you guys
> please take a look?
>
>> 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/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org
>> ReportedBy: pawel.zaq-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>> Regression: No
>>
>>
>> Created an attachment (id=72217)
>> --> (https://bugzilla.kernel.org/attachment.cgi?id=72217)
>> Output of `dmesg' command
>>
>> I 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 clear
>>
>> 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.
>>
>> 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.
>
>
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bug 42679] New: DMA Read on Marvell 88SE9128 fails when Intel's IOMMU is on
2012-01-30 21:41 ` Don Dutile
@ 2012-01-30 22:13 ` Paweł Żak
2012-01-30 23:32 ` Chris Wright
0 siblings, 1 reply; 6+ messages in thread
From: Paweł Żak @ 2012-01-30 22:13 UTC (permalink / raw)
To: Andrew Morton, Don Dutile
Cc: linux-ide, iommu, David Woodhouse, bugzilla-daemon
On Mon, 30 Jan 2012 22:41:32 +0100, Don Dutile <ddutile@redhat.com> wrote:
> On 01/30/2012 03:59 PM, Andrew Morton wrote:
>>
>> (switched to email. Please respond via emailed reply-to-all, not via
>> the
>> bugzilla web interface).
>>
>> On Sat, 28 Jan 2012 17:55:38 GMT
>> bugzilla-daemon@bugzilla.kernel.org wrote:
>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=42679
>>
>> I don't know if this is a SATA issue or intel-iommu. Could you guys
>> please take a look?
>>
>>> 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@linux-foundation.org
>>> ReportedBy: pawel.zaq@gmail.com
>>> Regression: No
>>>
>>>
>>> Created an attachment (id=72217)
>>> --> (https://bugzilla.kernel.org/attachment.cgi?id=72217)
>>> Output of `dmesg' command
>>>
>>> I 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
>>> clear
>>>
>>> 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.
>>>
>>> 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.
>>
>>
>> _______________________________________________
>> iommu mailing list
>> iommu@lists.linux-foundation.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
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ł
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bug 42679] New: DMA Read on Marvell 88SE9128 fails when Intel's IOMMU is on
2012-01-30 22:13 ` Paweł Żak
@ 2012-01-30 23:32 ` Chris Wright
2012-01-30 23:44 ` Paweł Żak
0 siblings, 1 reply; 6+ messages in thread
From: Chris Wright @ 2012-01-30 23:32 UTC (permalink / raw)
To: Paweł Żak
Cc: bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Andrew Morton,
David Woodhouse
* Paweł Żak (pawel.zaq@gmail.com) wrote:
> On Mon, 30 Jan 2012 22:41:32 +0100, Don Dutile <ddutile@redhat.com> wrote:
> >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
>
> 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?
thanks,
-chris
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bug 42679] New: DMA Read on Marvell 88SE9128 fails when Intel's IOMMU is on
2012-01-30 23:32 ` Chris Wright
@ 2012-01-30 23:44 ` Paweł Żak
2012-05-11 9:18 ` Andrew Cooks
0 siblings, 1 reply; 6+ messages in thread
From: Paweł Żak @ 2012-01-30 23:44 UTC (permalink / raw)
To: Chris Wright
Cc: Andrew Morton, Don Dutile, linux-ide, iommu, bugzilla-daemon,
David Woodhouse
On Tue, 31 Jan 2012 00:32:11 +0100, Chris Wright <chrisw@sous-sol.org>
wrote:
> * Paweł Żak (pawel.zaq@gmail.com) wrote:
>> On Mon, 30 Jan 2012 22:41:32 +0100, Don Dutile <ddutile@redhat.com>
>> wrote:
>> >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
>>
>> 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ł
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bug 42679] New: DMA Read on Marvell 88SE9128 fails when Intel's IOMMU is on
2012-01-30 23:44 ` Paweł Żak
@ 2012-05-11 9:18 ` Andrew Cooks
0 siblings, 0 replies; 6+ messages in thread
From: Andrew Cooks @ 2012-05-11 9:18 UTC (permalink / raw)
To: linux-ide
On Tue, 31 Jan 2012, Chris Wright <chrisw <at> sous-sol.org> wrote:
>> >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!)
>> >
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-05-11 9:20 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <bug-42679-27@https.bugzilla.kernel.org/>
[not found] ` <bug-42679-27-3bo0kxnWaOQUvHkbgXJLS5sdmw4N0Rt+2LY78lusg7I@public.gmane.org/>
2012-01-30 20:59 ` [Bug 42679] New: DMA Read on Marvell 88SE9128 fails when Intel's IOMMU is on Andrew Morton
[not found] ` <20120130125934.7971c815.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2012-01-30 21:41 ` Don Dutile
2012-01-30 22:13 ` Paweł Żak
2012-01-30 23:32 ` Chris Wright
2012-01-30 23:44 ` Paweł Żak
2012-05-11 9:18 ` Andrew Cooks
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox