Description of problem:
One of the number one problems with Intel VTd support is that it is 100% dependent on an ACPI table called 'DMAR'. BIOS/ACPI errors in the DMAR have
created some looooong, VTD-IOMMU debugging sessions, which could have been
shortened if the acpi system exported the DMAR table via /sys/firmware/acpi/table/DMAR as is done upstream (& Fedora).
With the use of iasl (preferably an updated version to 2009), one can cat
the above file, input it into iasl, and decode the table in human-readable form
to confirm or deny the existence of a bad DMAR table.
Version-Release number of selected component (if applicable):
Can't cat /sys/firmware/acpi/table/DMAR on RHEL5.
Can do that on F11, upstream linux.
Steps to Reproduce:
none, due to lack of support.
Current workaround -- install & boot an F11 installation on suspect hw;
pull the DMAR table from /sys/firmware/acpi/table/DMAR.
cat /sys/firmware/acpi/table/DMAR > DMAR.raw works.
iasl -d DMAR.raw generates human readable DMAR output.
RHEL5's iasl is very old, and needs updating as well.
Filing another bz for it. It's output isn't quite correct,
thus leaves the user to wonder if DMAR is valid or not.
You can dump the DMAR in RHEL5 via the acpidump and acpiextract utilities, and examine the DMAR using iasl as mentioned above.
Since that is the case, it is unlikely that this will be fixed for 5.6 or even 5.7 .
Closing as WONTFIX.