[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] P6T RMRR clarification please

I'm using
(XEN) Xen version 4.1.2 (Debian 4.1.2-2) (waldi at debian dot org) (gcc version 4.6.2 (Debian 4.6.2-6) ) Sat Dec 10 19:58:21 UTC 2011

With VT-d enabled in BIOS the ACPI Direct Memory Access remapping (DMAR) in the P6T Deluxe V2 (BIOS 1202, 2011/10/10) reports
RMRR (Reserved Memory Region Reporting Structure) is bf7dc000 - bf7dbfff

e820 table:
0000000000000000 - 000000000009e400 (usable)
000000000009e400 - 00000000000a0000 (reserved)
00000000000e4c00 - 0000000000100000 (reserved)
0000000000100000 - 00000000bf780000 (usable)
00000000bf780000 - 00000000bf798000 (ACPI data)
00000000bf798000 - 00000000bf7dc000 (ACPI NVS)
00000000bf7dc000 - 00000000c0000000 (reserved) <== RMRR in here
00000000fee00000 - 00000000fee01000 (reserved)
00000000ffe00000 - 0000000100000000 (reserved)
0000000100000000 - 00000001c0000000 (usable)

but Xen system log has:

(XEN) [VT-D]dmar.c:528:   RMRR address range not in reserved memory base = bf7dc000 end = bf7dbfff; iommu_inclusive_mapping=1 parameter may be needed.
(XEN) [VT-D]dmar.c:585:   The RMRR (bf7dc000, bf7dbfff) is incorrect!
(XEN) Failed to parse ACPI DMAR.  Disabling VT-d.
(XEN) Table is not found!

the log also has DMAR mentioned here:
(XEN) ACPI: DMAR BF7980C0, 0138 (r1    AMI  OEMDMAR        1 MSFT       97)
although I don't know what it means, or if it is relevant.

The iommu_inclusive_mapping parameter doesn't help.

If I compile the latest version from source instead of using the Debian repo will it help?

Is this still actually a problem with the latest BIOS? I'll email ASUS if it is ("good luck", I know...)

- Adam
Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.