Re: Can't boot new 4.4 kernel with IOMMU enabled

[Mark Hounschell <markh-n2QNKt385d+sTnJN9+BGXg@public.gmane.org>]

On 02/29/2016 12:42 PM, Joerg Roedel wrote:
> Hi Mark,
>
> On Fri, Feb 26, 2016 at 02:20:05PM -0500, Mark Hounschell wrote:
>> On 02/26/2016 11:23 AM, Joerg Roedel wrote:
>>> Can you please boot a v4.5-rc5 kernel with iommu enabled and
>>> 'amd_iommu_dump' on the kernel command line and send me dmesg after
>>> boot again?
>>>
>>>
>>
>> Here ya go Joerg,
>>
>> See ata7 and ata8 failure messages. These are the 2 disks that don't come up. They are hanging off one of these two Marvell chips.
>>
>> 07:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller (rev 12)
>> 13:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller (rev 12)
>
> Thanks for the dmesg. It does not contain IO_PAGE_FAULTs anymore, did it
> in the past? If yes, which device-ids were the faults reported against?
>

The original report from me at the top of this thread was that the 
machine would not come up at all. Many IO_PAGE_FAULTs.

The patch by Baoquan He <bhe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

iommu/amd: Correct the wrong setting of alias DTE in do_attach
commit 9b1a12d29109234d2b9718d04d4d404b7da4e794 upstream

fixed that issue but left me with these 2 disk not coming up. If I 
disable the iommu in the BIOS, all the disks work fine.


> I can't really say yet why it does not work on your system. The IOMMU
> core groups the devices 00:15.0-2 and 11-13:00.0 together. This means
> that they all end up in the same iommu group.
>
> But according to the IVRS ACPI table on your system none of these
> devices has an alias defined. So this doesn't explain why the commit
> you bisected it down to causes the problem, because the commit is about
> alias handling (which the devices in question don't need).
>
> Maybe I send you some debug patches to try out, but I stare at the code
> a little bit more first.
>

OK

Mark