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): How reproducible: Can't cat /sys/firmware/acpi/table/DMAR on RHEL5. Can do that on F11, upstream linux. Steps to Reproduce: 1. 2. 3. Actual results: 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. Expected results: cat /sys/firmware/acpi/table/DMAR > DMAR.raw works. iasl -d DMAR.raw generates human readable DMAR output. Additional info: 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. P.