IOMMU Support Gigabyte 990FXA-UD7

[LukasComputer]

Liebe Debian Community,
ich stehe vor einem Problem wo ich die Fehlerursache noch nicht ganz lokalisieren konnte.
Und zwar habe ich im September letzen Jahres einen Debian x64 Server mit VirtualBox und PHP Oberfläche zur Administration installiert.
Um nun einen ebenfalls vorhandenen HTPC zu virtualisieren und so einen Rechner einsparen zu können, wollte ich den IOMMU Support von VirtualBox nutzen.
In der Konfigdatei /boot/grub/grub.cfg habe ich dem Kernel den Parameter amd_iommu=on übergeben. Nachdem ich im Bios ebenfalls noch iommu aktiviert habe wollte ich den Server starten.
Jedoch kam es bereits bei Bootvorgang zu einer Fehlermeldung die besagte das die Raid Arrays nicht augebaut werden konnten. Das system startete aber trotzdem soweit das ich prüfen konnte welche Platten nicht erkannt worden. Und zwar handelt es sich um zwei Festplatten die sich an einem zusätzlihe Marvell Controller befinden. lspci sagt aber aus das der Controller gefunden wurde. Sobald ich iommu im Bios deaktiviere läuft alles wieder Ordnunggemäß.

Mein System

MB: GIGABYTE GA-990FXA-UD7
RAM: 24GB
CPU : AMD PHENOM II X6 1090T
8 x 2TB Platten
6 sind davon am Controller im Chipsatz angeschlossen.

Ich hofe ihr könnt mir helfen und ich bedanke mich schonmal für eventuelle Tipps Interessant wäre auch zu wissen ob es für den 990fx chipsatz spezielle Linux Treiber gibt

Grüße
Lukas

[rendegast]

Lang ist es her, da ging es etwas weiter:
http://forum.gigabyte.de/index.php?page ... eadID=5657

Der problematische Controller war ein Marvell 88SE9172, sowas:

Code: Alles auswählen

# cat /usr/share/misc/pci.ids | grep  88SE9172
        9172  88SE9172 SATA 6Gb/s Controller
        917a  88SE9172 SATA III 6Gb/s RAID Controller
        9192  88SE9172 SATA III 6Gb/s RAID Controller


Beim Kernel 3.2.0 (3.2.20):
# modprobe -c | grep -i 00001b4b
alias pci:v00001B4Bd00009123sv*sd*bc01sc06i01* ahci
alias pci:v00001B4Bd00009125sv*sd*bc*sc*i* ahci
alias pci:v00001B4Bd00009143sv*sd*bc*sc*i* mvumi
alias pci:v00001B4Bd0000917Asv*sd*bc*sc*i* ahci
alias pci:v00001B4Bd000091A0sv*sd*bc*sc*i* pata_marvell
alias pci:v00001B4Bd000091A3sv*sd*bc*sc*i* ahci
alias pci:v00001B4Bd000091A4sv*sd*bc*sc*i* pata_marvell
alias pci:v00001B4Bd00009445sv*sd00009480bc*sc*i* mvsas
alias pci:v00001B4Bd00009480sv*sd00009480bc*sc*i* mvsas
alias pci:v00001B4Bd00009485sv*sd00009480bc*sc*i* mvsas

[NAB]

man ... wo ich diesen alten Thread grad per Google gefunden habe, antworte ich doch mal darauf:

Das Problem betrifft etliche Marvell-Controller, egal auf welchem Mainboard. Die registrieren sich bei der MMU wohl mit PCI-Adresse .0 und antworten dann illegaler Weise auf PCI-Adresse .1, was dem Kernel egal sein kann, solange der DMA im selben Adressraum stattfindet. Soll der Adressraum aber per IOMMU auf einen anderen Bereich umgelenkt werden, ist das auf einmal gar nicht mehr egal.

Kurz gesagt, Marvell baut Müll.

Es wird versucht, im Kernel um das Problem herumzuflicken:
https://lkml.org/lkml/2012/12/19/104
aber das ist wohl ausgesprochen mühsam, weil Marvell absolut nicht kooperativ ist und man für jeden einzelnen Chip und jede Chiprevision herausfinden muss, wie die Fehlfunktionen aussehen.

Im Kernel 3.8 ist der Patch noch nicht, in Kernel 3.9 wohl auch nicht (danach suche ich gerade).
P.S.:
Den letzten Hinweis auf diesen Patch konnte ich hier entdecken:
http://www.spinics.net/lists/linux-pci/msg21217.html

Edit: Anderthalb Jahre später ...
Endlich ist Bewegung in die Sache mit IOMMU mit den kaputten Marvell Chips gekommen. Alex Williamson hat sich der Sache angenommen, und musste erst mal grundlegende Dinge im Kernel umstellen, um endlich einen funktionierenden Patch rausbringen zu können. Der aktuelle Bugreport findet sich hier:
https://bugzilla.kernel.org/show_bug.cgi?id=42679
Der Patch fließt in Kernel 3.17 ein, kommt also selbst für Jessie zu spät.
Da unterschiedliche Marvell-Chips unterschiedlich kaputt sind, und teilweise noch andere Macken haben, muss für jedes einzelne Modell geprüft werden, ob der Patch hilft. Der Patch ist also keine Universallösung, einzelne Device-IDs werden immer noch nachgepflegt, und ein möglichst neuer Kernel verspricht die besten Ergebnisse.