MARVELL 9230 und VT-d - gibt es dafür eine Lösung?

[drnicolas]

In einem anderen Thread schribe ich schon, dass ich nac einem BIOS-reset massiive Probleme hatte/habe.

Ich bin mir nicht sicher ob vor dem BIOS-reset VT-d aktiviert war; danach habe ich es auf jeden Fall eingeschaltet weil ich dachte, das muß so.

Folge: Ein storage mit Platten an einem MARVELL 9230 SATA-Controller funktioniert nicht, in PVE tauchen die Platten gar nicht erst auf!

Das Tücksiche daran:
- im BIOS sieht man die angeschlossenen Platten (mit VT-d ON)
- in PVE wird per lspci der Treiber als geladen gemeldet.
- lsblk ist aber dann doch leer!!!

- in einem Linux-Rettungssystem sieht man die Platten dennoch

- Abschalten von VT-d ändert alles; die Platten tauchen in PVE auf und der storage ist in Ordnung.

Das war anscheinend schon 2017 so, jedenfalls stammt die Lösung von damals.
Gibt es einen Workaround? Ich bin nicht sicher ob nicht zuvor es doch irgendwie MIT VT-d funktioinerte

 

[celemine1gig]

Wenn du den Marvell als Einsteckkarte besitzt, oder ihn auf deinem Mainboard deaktivieren und durch eine externe Karte ersetzen kannst, wird das vermutlich die einfachste Lösung sein.
Das Letzte Mal, als ich von (=über) Marvell SATA Controllern positives gehört habe ist eine GANZE Weil her. Das Zeug ist einfach schlecht gealtert, könnte man sagen. Die Aufwände die du vermutlich wegen dem Zeug investieren müsstest, könnten eventuell durch eine ~20,-EUR Investition hinfällig werden.

 

[Bu66as]

Das ist bei den Marvell-Controllern so ein DMA-Alias-Thema, die schicken DMA teilweise über eine andere PCI-Function als die, unter der sie sich melden, und die IOMMU blockt das dann. Im BIOS und im Rettungssystem fällt das nicht auf, weil dort die IOMMU nicht aktiv ist. Der Kernel hat für den 9230 zwar einen Quirk, der greift aber offenbar nicht immer. Bevor du Hardware tauschst, probier mal iommu=pt auf der Kernel-Cmdline. Dann laufen die Host-Geräte im Passthrough-Modus und die IOMMU übersetzt nur noch für Geräte, die du an VMs durchreichst. Bei GRUB in /etc/default/grub bei GRUB_CMDLINE_LINUX_DEFAULT ergänzen und update-grub ausführen. Bei systemd-boot (ZFS-Root mit UEFI) in /etc/kernel/cmdline eintragen und danach proxmox-boot-tool refresh. Danach neu starten.

Brauchst du VT-d überhaupt, also reichst du irgendwas an eine VM durch? Wenn nicht, kannst du es auch einfach auslassen, dann hast du keinen Nachteil. Dass es vorher lief, kann gut daran liegen, dass VT-d vor dem Reset aus war. Falls es mit iommu=pt nicht klappt, poste mal die Ausgabe von dmesg | grep -iE 'dmar|ahci|ata[0-9]'. Wenn dort DMAR-Faults auftauchen, sieht man, welche Function geblockt wird.

 

[celemine1gig]

Mit seinem Hinweis hat Bu66as wohl recht.
Ich persönlich würde es aber noch davon abhängig machen wie lange ich die Teile noch einsetzen will.
Wenn es nur drum geht das auf die Schnelle und absehbar lauffähig zu bekommen, mit dem Wissen es in ca. einem Jahr zu ersetzen, dann gut.
Wenn ich allerdings wüsste, dass ich einen Workaround noch länger eigenständig immer wieder prüfen und/oder aktivieren müsste, würde ich mir den Kauf eines neuen Controllers doch überlegen. Rein schon aus der eigenen Faulheit heraus.