This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-users] Re: VT-D RMRR is incorrect


I couldn't really get what you were trying to say (I never mentioned AMD...) but anyway this isn't really Linux specific it's a BIOS bug. Unfortunately the only way to get in contact with that bug is to either use Xen or enable DMRR in the vanilla Linux kernel. If this cannot be fixed in software I'll probably return the board to the store and get an Intel DX58SO instead...

Yoshiharu, have you tested Xen-unstable yet? When commenting out the EFAULT you mentioned I get an immediate panic related to the rmrr address conflict on the latest 3.4-unstable tree.

@Xen devs: Is this something that could be worked around in Xen or do we really have to rely on exact RMRR values for vtd to work? See http://permalink.gmane.org/gmane.comp.emulators.xen.user/43937 for more details.


Dustin Henning schrieb:
        I would recommend opening a new ticket with ASUS and telling them
you were running Windows if you can get the same output Yoshiharu-san did
and it fails to meet AMD specifications the way his fails to meet Intel
specifications, after all, that would mean their board was out of spec with
AMD, not Linux.  However, in my experience, ASUS can't fix anything (I tried
to be an early adopter of the SiI port multiplier via their P5WD2-Premium
onboard SiI SATA and a port multiplier from someone else, after all, their
documentation clearly stated that they supported port multipliers, and they
didn't make their own, however, it wouldn't work with port multipliers, they
"escalated it to their engineering," and I never heard back, so the issue
was never resolved).  I'd recommend going with Gigabyte or SuperMicro,
because I've had equally bad support from MSI (I have several computers
whose systems monitoring software goes off continuously until reboot after
using a floppy drive, that would have to be a firmware issue, and they can't
fix it).  All the other manufacturers are either awfully new to the market
or awfully unreliable (Biostar, for instance, isn't likely to have a board
last much longer than their warranty in my experience, regardless of
platform), SuperMicro would probably be the better bet compatibility wise,
but they have a short warranty and less features (read: less additional
features that probably don't work with Linux anyway).  Good luck finding
something that works, be sure to let everyone know what it is.

Xen-users mailing list