[Kaufberatung] Board mit VT-d Unterstützung gesucht * momentan P5Q-VM D0 im Test

Das P5Q-VM DO vielleicht, das P5QL-VM hat ja keinen Q45 Chipsatz. Aber ob VT-d bei dem funktioniert, steht ja auch nirgendwo, leider.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ok, habe gerade mal nachgesehen. Der B43 bietet tatsächlich keinen VT-d Support. Dann vergiss das P5QL-VM DO.
 
vielleicht sollte ich ja mal Fedora probieren, ist vielleicht zum Virtualisieren geeigneter als Ubuntu.
 
sagen wir es ist (verständlicherweise) für kvm geeigneter als ubuntu ;)
zu deiner frage, aktueller kernel bei fedora ist der 2.6.30.5

was mich noch interessieren würde wäre, wofür du das benötigst ... evtl kann ich ja die eine oder andere anregung für das nächste verregnete wochenende bekommen ;)
 
Ich wollte in einer VM einen VDR-Server mit 2 durchgereichten DVB-Karten einrichten. Das Durchreichen hat geklappt, aber die Karten hatten in der VM keinen Empfang.

Hab es auch mal mit Wlan-Karten probiert, ebenso kein Empfang in der VM, erst mit VT-d hatten sie Empfang.
 
und mit dem p5q (mit q45) hat das geklappt ?
hast du das board noch ? :d
 
Das P5E-VM DO hatte ich, was VT-d hatte. Hab jetzt das DFI LanParty DK P45-T2RS, hier, vorher das MSI P45 Neo3, vorher das P5B von Asus und mal ein MSI G31-Board.
 
ja das msi g31 hatte ich auch erst in meinem vdr und war nicht so wirklich begeistert, jetzt hab ich seit einiger zeit das p5e vm drinnen und bin sehr zufrieden, aber grad diese virtualisierungsgeschichte wollte ich "bald" mal ausprobieren, da ich nicht mehr mit verschiedenen platten hantieren wollte, wenn ich mal wieder versuche nen neuen vdr zu kompilieren (ich sach nur vdpau ...), nicht 100% glücklich bin und frauchen dann was gucken will ;)
da ich bei meinem setup aber eh auf matx angewiesen bin, hätte ich dir das q35/q45 board vielleicht "abgenommen" ;)
 
werd mir jetzt mal das ASUS P5Q-VM DO bestellen und testen.
 
also ich hab noch mal n bischen rumprobiert und es scheint sich definitiv was zu verändern wenn ich im bios vt-d aktiviere.
aber so wirklich klappen tut es nicht, ich werd die tage mal ne alte dvb-t karte rauskramen und mal gucken ob ich die an nen vm-vdr durchreichen kann.
mit dem firewire port hat es zumindest geklappt wie es scheint, ich konnte es nur nicht sinvoll testen.

wenn du magst könntest du ja mal schreiben wie das mit den p5q so klappt ... vdr in ner vm ... das wär mal was ;)
 
mach ich. das Board sollte morgen oder Dienstag kommen. Bin mal gespannt.
 
So, Board ist hier und grad eingebaut.

Aber entweder hab ich ein Montagsboard erwischt oder das ist im Beta-Stadium veröffentlicht worden.

* Lüftersteuerung funktioniert nicht (4Pin), egal welches Profil man auswählt, der pustet immer auf 100%
* beim Booten kommt nach 1min mit der Onboard-Graka mal ein Bild, dachte schon, das Board ist im Eimer

Werd jetzt mal probieren, ob VT-d geht oder nur wieder ein Bios-Gag ist.
 
Es gab erst letzte Woche ein neues Bios für das P5Q-VM DO (0216). Vielleicht löst das ja schon ein zwei von deinen Problemen :wink:
 
Das Bios ist schon drauf, scheint auch das einzige zu sein, was es gibt.

Grad mal eine Graka eingesteckt, da kommt auch erst nach 1min ein Bild.
Mit 4GB bootet es überhaupt nicht.

Mal kucken, ob es was bringt, das Bios neu zu flashen.

Edit: Das Bios neu zu flashen hat auch keine Verbesserung gebracht. Ausserdem ist das Bios vom Juni 2009, und nicht vom 26.8.09, wie Asus es auf der Homepage schreibt. Es ist das "First Release", ein Update wird wohl irgendwann vielleicht kommen.
Werd dann mal den Support anschreiben, ob das deren Ernst ist, so ein Board zu verkaufen.

---------- Beitrag hinzugefügt um 14:41 ---------- Vorheriger Beitrag war um 11:58 ----------

@Venice: was ist von dem Ausdruck hier zu halten?

Kernel ist der aktuelle 2.6.31.

Code:
0.000000] ACPI: DMAR 000000007bb80100 00150 (v01    AMI  OEMDMAR 00000001 MSFT 00000097)
[    0.013751] DMAR:Host address width 36
[    0.013753] DMAR:DRHD base: 0x000000fed91000 flags: 0x0
[    0.013758] DMAR:DRHD base: 0x000000fed92000 flags: 0x0
[    0.013763] DMAR:DRHD base: 0x000000fed93000 flags: 0x1
[    0.013766] DMAR:RMRR base: 0x000000000ed000 end: 0x000000000effff
[    0.013768] DMAR:RMRR base: 0x0000007bc00000 end: 0x0000007dffffff
[    0.013771] DMAR:RMRR base: 0x0000007bbe0000 end: 0x0000007bbeffff
[    0.013772] DMAR:No ATSR found
[    0.212017] Multi-level page-table translation for DMAR.
[    0.212023] DMAR:[DMA Write] Request device [00:02.0] fault addr 0
[    0.212023] DMAR:[fault reason 05] PTE Write access is not set
[    5.563879] DMAR:[DMA Write] Request device [00:02.0] fault addr 37d6f000
[    5.563880] DMAR:[fault reason 05] PTE Write access is not set
[    5.564656] DMAR:[DMA Write] Request device [00:02.0] fault addr 37d6f000
[    5.564657] DMAR:[fault reason 05] PTE Write access is not set
[    5.565139] DMAR:[DMA Write] Request device [00:02.0] fault addr 37d6f000
[    5.565140] DMAR:[fault reason 05] PTE Write access is not set
[    5.566734] DMAR:[DMA Write] Request device [00:02.0] fault addr 37d6f000
[    5.566734] DMAR:[fault reason 05] PTE Write access is not set
[    5.567584] DMAR:[DMA Write] Request device [00:02.0] fault addr 37d6f000
[    5.567585] DMAR:[fault reason 05] PTE Write access is not set
[    5.569263] DMAR:[DMA Write] Request device [00:02.0] fault addr 37d6f000
[    5.569264] DMAR:[fault reason 05] PTE Write access is not set
[    5.570182] DMAR:[DMA Write] Request device [00:02.0] fault addr 37d6f000
[    5.570183] DMAR:[fault reason 05] PTE Write access is not set
[    5.571792] DMAR:[DMA Write] Request device [00:02.0] fault addr 37d6f000
[    5.571793] DMAR:[fault reason 05] PTE Write access is not set
[    5.572575] DMAR:[DMA Write] Request device [00:02.0] fault addr 37d6f000
[    5.572576] DMAR:[fault reason 05] PTE Write access is not set
[    5.574150] DMAR:[DMA Write] Request device [00:02.0] fault addr 37d6f000
[    5.574151] DMAR:[fault reason 05] PTE Write access is not set
[    5.574989] DMAR:[DMA Write] Request device [00:02.0] fault addr 37d6f000
[    5.574990] DMAR:[fault reason 05] PTE Write access is not set
[   12.797456] DMAR:[DMA Write] Request device [00:02.0] fault addr 747d0000
[   12.797457] DMAR:[fault reason 05] PTE Write access is not set
[   12.797637] DMAR:[DMA Write] Request device [00:02.0] fault addr 7872c000
[   12.797638] DMAR:[fault reason 05] PTE Write access is not set
[   13.033321] DMAR:[DMA Write] Request device [00:02.0] fault addr 73644000
[   13.033322] DMAR:[fault reason 05] PTE Write access is not set
[   13.033629] DMAR:[DMA Write] Request device [00:02.0] fault addr 736a6000
[   13.033630] DMAR:[fault reason 05] PTE Write access is not set


---------- Beitrag hinzugefügt um 14:57 ---------- Vorheriger Beitrag war um 11:58 ----------

Und hier ohne Onboard-Graka:

Code:
0.000000] ACPI: DMAR 000000007de80100 00120 (v01    AMI  OEMDMAR 00000001 MSFT 00000097)
[    0.013718] DMAR:Host address width 36
[    0.013720] DMAR:DRHD base: 0x000000fed92000 flags: 0x0
[    0.013724] DMAR:DRHD base: 0x000000fed93000 flags: 0x1
[    0.013730] DMAR:RMRR base: 0x000000000ed000 end: 0x000000000effff
[    0.013732] DMAR:RMRR base: 0x0000007e000000 end: 0x0000007dffffff
[    0.013734] DMAR:RMRR base: 0x0000007dee0000 end: 0x0000007deeffff
[    0.013736] DMAR:No ATSR found
[    0.208318] Multi-level page-table translation for DMAR.
 
Zuletzt bearbeitet:
urks ? das sieht ja lustig aus.
probier doch mal den kernel mit
intel_iommu=on
oder alternativ off zu starten.

und ist 00:02.0 die onboard graka ?
dann sieht ja so aus, als ob die versuchen würde in einen speicherberreich zu schreiben, das aber nicht darf ... toll ;)

wär doch aber auch total langweilig wenn es einfach klappen würde, oder ?

---------- Beitrag hinzugefügt um 16:33 ---------- Vorheriger Beitrag war um 15:37 ----------

ich hab mal google angeworfen, es scheint wirklich ein fehler (gewesen) zu sein, dass nur die pci-to-pci bridge weitergereicht wurde und nicht die dahinter liegende device.
( quelle : http://bugzilla.kernel.org/show_bug.cgi?id=12578 )
interessant für dich könnte comment 38 / 39 sein (stichwort CONFIG_DMAR_GFX_WA ).
lustig fand ich nur, dass der bug resolved ist, und zwar durch folgenden fix :
http://git.kernel.org/?p=linux/kern...ff;h=924b6231edfaf1e764ffb4f97ea382bf4facff58

im code steht nur nicht :
for (i = 0; i < drhd->devices_cnt; i++) {
if (drhd->devices &&
drhd->devices->bus->number == bus &&
drhd->devices->devfn == devfn)
return drhd->iommu;
if (drhd->devices->subordinate &&
drhd->devices->subordinate->number <= bus &&
drhd->devices->subordinate->subordinate >= bus)
return drhd->iommu;
}


sondern :
for (i = 0; i < drhd->devices_cnt; i++) {
if (drhd->devices &&
drhd->devices->bus->number == bus &&
drhd->devices->devfn == devfn)
return drhd->iommu;
if (drhd->devices &&
drhd->devices->subordinate &&
drhd->devices->subordinate->number <= bus &&
drhd->devices->subordinate->subordinate >= bus)
return drhd->iommu;
}



soll aber nix heißen an der datei ist auch bis vor einem monat relativ viel passiert
( http://git.kernel.org/?p=linux/kern...4ad7ee5fef4544ab2159cd7e253ed6e1d3889;hb=HEAD )

interessant könnte dieser commit sein
http://git.kernel.org/?p=linux/kern...it;h=62edf5dc4a524e4cb525e6020b955a1ad593d9ba

ich sach nur :
intel-iommu: Restore DMAR_BROKEN_GFX_WA option for broken graphics drivers

We need to give people a little more time to fix the broken drivers.

wobei ich immer dachte dass die linux unterstützung der intel graka chips so toll sei ;)


*conclusion* :

solltest du den kernel mit
CONFIG_DMAR_GFX_WA=y
gebaut haben, probiers doch mal ohne. die onboardgraka wirst du ja (vielleicht) nicht unbedingt weiterreichen wollen und ggf benötigst du das auch nicht für die tv-karten.

(oder du deaktivierst die onboard ... ) mit was für einer klappts denn ?
und welche onboard funzt denn nicht ? ist das ne 4000er intel in dem q45 ?
evtl gibts ja da einen weg .. wenn es (so wie es ja scheint) am treiber liegt ...
 
CONFIG_DMAR_GFX_WA hab ich nicht aktiviert.

00:02.0 war die Onboard (X4500HD), momentan hab ich eine 9400GT drin.
Werd dann mal ein paar PCI-Karten einbauen, mal kucken, wie die IRQ´s so verteilt sind.

Mit 4GB RAM startet es nun auch, nur dauert es da fast 1min, bis mal ein Bild kommt, mit weniger RAM dauerts 40-50s bis zum ersten Bild.
Zum Reboot ist das Board einfach nicht gemacht, mal kucken, was der Support meint.
 
Zuletzt bearbeitet:
@Venice: Ein PCI-Gerät (im mittleren PCI-Slot) konnte ich durchreichen, WLAN-Karte hat im Windows-Gast Empfang.
Der letzte PCI-Slot teilt sich leider den IRQ mit USB, aber auch das deaktivieren des USB-Krempels wollte die eingesteckte PCI-Karte nicht dazu bewegen, im Gast zu funktionieren.

Leider wird der erste PCI-Slot vom Kühler der Graka verdeckt, aber das bekomm ich morgen auch noch hin.
 
Ok, das Board geht wieder zurück. Ich konnte heute vom Einschalten bis zum ersten Bild am Monitor den Frühstückstisch decken und Kaffee kochen.

Der Asus-Support hat sich wie zu erwarten war auch nicht gemeldet, also wars das mit dem Board.

@venice: Ich bekomm immer nur eine PCI-Karte durchgereicht, egal in welchem Slot und egal in welcher Reihenfolge. Die anderen blieben im Windows-Gast mit einem gelben Ausrufezeichen und konnten nicht gestartet werden (Fehler 10 oder so).
 
hm, das ist ja echt mal strange

aber wenn es eine konstante im leben gibt, dann der asus support und die downloadserver :d

ich guck mal, ob ich nochmal zeit finde das an dem großen zu testen, bin nur im moment so dermaßen faul ;)
naja vielleicht gebe ich mir ja heute abend einen ruck ;)
 
Grad eben hab ich alles verpackt und dann bekomm ich doch nicht etwa eine Mail von Asus mit einem Bios-Update? Mal kucken, was das bringt.

---------- Beitrag hinzugefügt um 11:21 ---------- Vorheriger Beitrag war um 10:30 ----------

So, das Bios-Update war voll für die Tonne, die selben Fehler wie vorher.
 
Hab eben mal Fedora11 auf dem DFI installiert, mit dem 2.6.29er Kernel, der dabei ist, bekomm ich auch die Meldung wie bei dir:

Code:
dmesg | grep DMAR
ACPI: DMAR 7FEE8F40, 0098 (r1 IntelR AWRDACPI 322E3030 DRWA        2)
DMAR:Host address width 36
DMAR:DRHD (flags: 0x00000001)base: 0x00000000fed93000
DMAR:RMRR base: 0x000000007fef0000 end: 0x000000007fefffff
 
mach grad bei FC11 ein Upgrade, der rödelt hier noch etwas rum. Dann muss ich erstmal kucken, wie ich unter Fedora das so alles installiere, hatte ja vorher immer Ubuntu.
 
zur not nutzt du einfach das klickibunti "virtual machine manger" gui von gnome
(anwendungen, Systmwerkzeuge)
klappt erschreckend gut, die dazugehörigen files findest du unter /etc/libvirt/qemu/
 
die libvirt-Version unter Fedora ist leider schon etwas alt, 0.6.2 gibts da, mittlerweile ist aber schon die 0.7.1 draussen.
Das kompilieren von kvm-88 und libvirt aus dem cvs schlug fehl, was mich daran gehindert hat, da groß weiter zu probieren.

Mal kucken, ob sich morgen der Asus-Support nochmal meldet, ansonsten wird das DFI verkauft und das Asus zurückgeschickt.
 
warum kompilierst du kvm neu ?
ging mit der die dabei ist gar nix ?
 
ne, da ging nix. Werd das Thema wohl erstmal ruhen lassen, bis es mal etwas ausgereiftes rauskommt.

Momentan steh ich im regen Schriftverkehr mit Asus, wahrscheinlich bin ich der erste Kunde, der sich das P5Q-VM D0 hat andrehen lassen.
Die Entwicklungsabteilung aus Taiwan hängt da jetzt auch schon mit drin.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh