Yes, I think it's too broken in anything other than 1.8 to get a working IOMMU. I tried quite a few things and eventually downgraded to 1.8, but I have a Phenom II X6 so that works.
Yes, I did the same thing. Only, I was eager to find a workaround. At least for me it did not work around, apparently.
I didn't see anything explicitly stating that an AM3+ CPU was being used. My point is that if you can, downgrade to 1.8. Nothing significant is really gained from higher versions aside from CPU support. The clowns that write the BIOS seem to break 6 things for every single "fix" in newer BIOS.
Well, even I was thinking at one time if it may be wise to upgrade to an FX CPU. That would get me once again multi-core (8 maybe?!?) and some additional CPU features, like AVX and FMA.
The question was of course "do I really need this?" And the answer was, in my case, no. But there are people who did upgrade and there are likely some who got their mainboard with a newer CPU to start with. Those are now stuck with a non-working IOMMU under Linux.
I thought to myself, since I can run both the older version 1.8 BIOS and the newer one, maybe I can figure out the correct configuration and thus not only help myself but also others. I failed. Sorry.
As for the BIOS "clowns" – I wouldn't dare call them that. I don't know what the problem is, but under Windows it all seems to work fine. Maybe they just didn't test under Linux. If I remember correctly, the bug was reported to MSI, but they didn't fix it. In that sense you're right – they definitely didn't take this bug seriously!
In defense for MSI I must say that it may be the wrong type of mainboard. After I bought it I watched a video of the presentation of this mainboard on YouTube (which I cannot find right now). The target for it was clearly gamers. The main feature of the MSI 890FXA-GD70 is that it features five full-speed PCIe-2.0-x16 expansion slots. They were, according to the presentation, intended for the use of graphics cards, even if only 2 are also electrically x16 and 2 electrically only x8 (and the last one electrically only x4). Graphics for games. For gamers. And gamers who with 99.9% certainty run Windows wouldn't need IOMMU on Linux anyway…
]]>FishB8 wrote:Use BIOS ver. 1.8
I don’t really get your point here.
If I use BIOS 1.8 the IOMMU works, yes.
It doesn’t work with version 1.9 and newer, including the latest update 1.F=1.15.Since BIOS version 1.9 AM3+ CPUs are supported. Owners of FX-CPUs (AM3+) have no choice and cannot use BIOS 1.8, so they cannot get a working IOMMU setup.
See also: http://www.msi.com/support/mb/890FXAGD7 … upport-cpu
Yes, I think it's too broken in anything other than 1.8 to get a working IOMMU. I tried quite a few things and eventually downgraded to 1.8, but I have a Phenom II X6 so that works.
I didn't see anything explicitly stating that an AM3+ CPU was being used. My point is that if you can, downgrade to 1.8. Nothing significant is really gained from higher versions aside from CPU support. The clowns that write the BIOS seem to break 6 things for every single "fix" in newer BIOS.
]]>Use BIOS ver. 1.8
I don’t really get your point here.
If I use BIOS 1.8 the IOMMU works, yes.
It doesn’t work with version 1.9 and newer, including the latest update 1.F=1.15.
Since BIOS version 1.9 AM3+ CPUs are supported. Owners of FX-CPUs (AM3+) have no choice and cannot use BIOS 1.8, so they cannot get a working IOMMU setup.
See also: http://www.msi.com/support/mb/890FXAGD7 … upport-cpu
]]>Add the following to the kernel boot command line:
iommu=1 ivrs_ioapic[6]=00:14.0
Note that if you use an Nvidia video card with their proprietary driver, it will not work correctly with the IOMMU enabled. It will work if you add an additional option "iommu=pt" but that kinda defeats the purpose.
]]>In other words: I’m out.
I’ll look for a replacement in the near future.
I wish you guys good luck!
]]>Btw, sometimes the pci-e 4 slot (where I have a wifi card) is not recognized in windows 7, and a reboot is necessary in order to get the card recognized again. IIRC this also happened with another pci-e wifi card and I also have had similar problems with the pci slot. However, this problems get solved either by a reboot or by clearing the cmos.
So I guess we all bought a buggy motherboard.
https://lkml.org/lkml/2014/9/5/325 by Joerg Roedel, 5 Sep 2014 (as reaction to the one from Su Friendly, maybe simpler)
https://lkml.org/lkml/2014/9/5/248 by Su Friendy, 5 Sep 2014
http://lists.xen.org/archives/html/xen- … 01552.html by Jan Beulich, 13 Sep 2013 (for Xen, not for the mainstream Linux kernel)
I didn’t test them yet, but I plan to. The plan is to patch the kernel and see if it uses the overrides. Then I will flash the BIOS once again and see if it still works then. Hopefully it will, otherwise I'll presumably finally give up…
I checked my running system. I currently run gentoo-sources-3.19.3 and it still ignores the command line override i.e. "early mapped IOPIC/HPET devid"…
UPDATE/CORRECTION: The patch by Joerg Roedel is already applied to gentoo-sources-3.19.3. So it must have been merged into the main kernel at some point after September 2014. In my defense, it seems noteworthy that the message "AMD-Vi: Command-line override present for HPET id 0 - ignoring" is still present, suggesting that it is still ignored…
]]>I’ve been enjoying my life, working, and just using my computer in my scarce spare time: BIOS 1.15 (1.F0) and Linux without IOMMU (using iommu=soft).
During X-Mas holiday I had a bit more spare time and decided to try BIOS 1.80 again. It boots and initializes the IOMMU, without the necessity of using a iommu kernel paramenter, obviously with the IOMMU enabled in the BIOS.
I have to confess I’d rather stay with BIOS 1.80 than again update just to find it’s still not possible to work around this issue. BUT, I’ve booted kernel 3.18.2-gentoo with kernel parameter amd_iommu_dump=1 and it gives me the following information:
AMD-Vi: device: 00:00.2 cap: 0040 seg: 0 flags: 3e info 1300
AMD-Vi: mmio-addr: 00000000f6000000
AMD-Vi: DEV_SELECT_RANGE_START devid: 00:00.0 flags: 00
AMD-Vi: DEV_RANGE_END devid: 00:00.2
AMD-Vi: DEV_SELECT devid: 00:02.0 flags: 00
AMD-Vi: DEV_SELECT_RANGE_START devid: 09:00.0 flags: 00
AMD-Vi: DEV_RANGE_END devid: 09:00.1
AMD-Vi: DEV_SELECT devid: 00:04.0 flags: 00
AMD-Vi: DEV_SELECT devid: 08:00.0 flags: 00
AMD-Vi: DEV_SELECT devid: 00:05.0 flags: 00
AMD-Vi: DEV_SELECT devid: 07:00.0 flags: 00
AMD-Vi: DEV_SELECT devid: 00:06.0 flags: 00
AMD-Vi: DEV_SELECT devid: 06:00.0 flags: 00
AMD-Vi: DEV_SELECT devid: 00:09.0 flags: 00
AMD-Vi: DEV_SELECT devid: 05:00.0 flags: 00
AMD-Vi: DEV_SELECT devid: 00:0b.0 flags: 00
AMD-Vi: DEV_SELECT devid: 04:00.0 flags: 00
AMD-Vi: DEV_SELECT devid: 00:11.0 flags: 00
AMD-Vi: DEV_SELECT_RANGE_START devid: 00:12.0 flags: 00
AMD-Vi: DEV_RANGE_END devid: 00:12.2
AMD-Vi: DEV_SELECT_RANGE_START devid: 00:13.0 flags: 00
AMD-Vi: DEV_RANGE_END devid: 00:13.2
AMD-Vi: DEV_SELECT devid: 00:14.0 flags: d7
AMD-Vi: DEV_SELECT devid: 00:14.2 flags: 00
AMD-Vi: DEV_SELECT devid: 00:14.3 flags: 00
AMD-Vi: DEV_SELECT devid: 00:14.4 flags: 00
AMD-Vi: DEV_ALIAS_RANGE devid: 03:00.0 flags: 00 devid_to: 00:14.4
AMD-Vi: DEV_RANGE_END devid: 03:1f.7
AMD-Vi: DEV_SELECT devid: 00:14.5 flags: 00
AMD-Vi: DEV_SELECT devid: 00:15.0 flags: 00
AMD-Vi: DEV_SELECT devid: 00:15.1 flags: 00
AMD-Vi: DEV_SELECT devid: 01:00.0 flags: 00
AMD-Vi: DEV_SELECT_RANGE_START devid: 00:16.0 flags: 00
AMD-Vi: DEV_RANGE_END devid: 00:16.2
AMD-Vi: DEV_SPECIAL(HPET[0]) devid: 00:14.0
AMD-Vi: DEV_SPECIAL(IOAPIC[7]) devid: 00:00.1
AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
pci 0000:00:00.2: irq 27 for MSI/MSI-X
AMD-Vi: Lazy IO/TLB flushing enabled
So, I’d have to use ivrs_hpet[0]=00:14.0 and ivrs_ioapic[7]=00:00.1, right? I’m uncertain if I should risk it to update my BIOS to 1.15 once again only to find trouble…
Anyway, maybe I will, and I’ll keep you informed.
BTW, others have the same problem: ASUS Crosshair IV Formula (Ubuntu), ASUS M4A89TD PRO USB3 (Fedora)… an my MSI 890FXA-GD70… a problem shared is a problem halved, right?
What makes me wonder is if the HPET and the IOAPIC index numbers and device IDs stay the same throu BIOS updates. Hopefully, otherwise these numbers are null and void. That said, why isn’t there a convenient way to probe for these settings, in case the IVRS table is invalid – apparently every board has different settings, so probing for them seems to be the cleanest way to solve this issue on buggy BIOSes. But I guess that would be something for a kernel developer…
And one more thing: does the kernel still have to be patched in order to not ignore those IVRS override settings? Because this LKML post from January 2015 still shows the line
AMD-Vi: Command-line override present for HPET id 0 - ignoring
…and as a side note: why would ivrs_hpet and ivrs_ioapic, whatever index they are set to, be using the same device? In this case the author of this post used ivrs_ioapic[6]=00:14.0 and ivrs_hpet[0]=00:14.0, but that doesn’t make any sense to me. (It too doesn’t make any sense to use overrides at all if they are ignored afterwards.)
Anyway, I’d be happy to hear some more advice on this issue. Thanks.
]]>--- a/amd_iommu_init.c 2013-04-29 00:36:01.000000000 +0000
+++ b/amd_iommu_init.c 2013-05-26 09:33:11.452098000 +0000
@@ -751,6 +751,10 @@ static void __init set_device_exclusion_
}
}
+/* SB IOAPIC is always on this device in AMD systems */
+#define IOAPIC_SB_DEVID ((0x00 << 8) | PCI_DEVFN(0x14, 0))
+#define IOAPIC_NB_DEVID ((0x00 << 8) | PCI_DEVFN(0x00, 1))
+
/*
* Takes a pointer to an AMD IOMMU entry in the ACPI table and
* initializes the hardware and our data structures with it.
@@ -922,6 +926,10 @@ static int __init init_iommu_from_acpi(s
else
var = "UNKNOWN";
+ if (type == IVHD_SPECIAL_HPET ){
+ devid = IOAPIC_SB_DEVID;
+ }
+
DUMP_printk(" DEV_SPECIAL(%s[%d])\t\tdevid: %02x:%02x.%x\n",
var, (int)handle,
PCI_BUS(devid),
@@ -1633,9 +1641,6 @@ static void __init free_on_init_error(vo
#endif
}
-/* SB IOAPIC is always on this device in AMD systems */
-#define IOAPIC_SB_DEVID ((0x00 << 8) | PCI_DEVFN(0x14, 0))
-
static bool __init check_ioapic_information(void)
{
bool ret, has_sb_ioapic;
this is an ugly hack but w/e, you could do the the same for the 2 ioapics
EDIT: Perhaps its hanging on these lines?
set_dev_entry_from_acpi(iommu, devid, e->flags, 0);
ret = add_special_device(type, handle, devid, false);
if (ret)
return ret;
break;
OR
static int __init add_early_maps(void)
{
int i, ret;
for (i = 0; i < early_ioapic_map_size; ++i) {
ret = add_special_device(IVHD_SPECIAL_IOAPIC,
early_ioapic_map[i].id,
early_ioapic_map[i].devid,
early_ioapic_map[i].cmd_line);
if (ret)
return ret;
}
for (i = 0; i < early_hpet_map_size; ++i) {
ret = add_special_device(IVHD_SPECIAL_HPET,
early_hpet_map[i].id,
early_hpet_map[i].devid,
early_hpet_map[i].cmd_line);
if (ret)
return ret;
}
return 0;
}
list_for_each_entry(entry, list, list) {
if (!(entry->id == id && entry->cmd_line))
continue;
pr_info("AMD-Vi: Command-line override present for %s id %d\n",
type == IVHD_SPECIAL_IOAPIC ? "IOAPIC" : "HPET", id);
/* return 0; */
}
So now if I use the override it doesn’t return anymore but continues inside the function.
It still freezes. The last message that is displayed is the very override pr_info as in the code above. I used "ivrs_hpet[0]=00:14.0" as the command line override argument.
]]>AMD-Vi: Command-line override present for HPET id 0 - ignoring
The same thing happens if I want to override the IOAPIC setting: apparently it is ignored and stalls.
It comes to my mind that this error on my system may be different to the error reported by the original poster…
I leave it at "iommu=soft" for now to keep my system running.
]]>ivrs_hpet[0]=00:14.0
I used "amd_iommu_debug" one time and it displays a lot of information, then stalls. The last two lines tell me this: HPET[0] is device 00:00.1, IOAPIC[7] is device 00:14.0. But I cannot scroll up to see all the messages, nor have I set up a serial console to copy&paste its output here.
I don’t know what to do next…
]]>