acpidump skips the FADT table revision field and will ignore the 64-bit XFACS and XDSDT values if the FACS value is valid while XFACS is 0, even if the DSDT address is invalid while teh XDSDT address is (see comment and logic in
usr.sbin/acpi/acpidump/acpi.c:acpi_get_fadt_revision()). To put it concretely, on a Supermicro M11SDV-4C-LN4F with firmware 1.0a, acpidump hangs after printing the FACS table. By looking at the memory of the FADT, I could see these values:
the correct value for XDSDT is ignored, and an invalid address is assumed to be the DSDT address. The memory at 0x0 was (unsurprisingly) not a DSDT table (note the missing 'DSDT' signature):
# hexdump -C -s 0x0 -n 8 /dev/mem 00000000 f3 ee 00 f0 f3 ee 00 f0 |........| 00000008
Note that the next 4 bytes after the signature (0x4:8) are an unsigned 32-bit int that's supposed to be the size of the table. acpidump doesn't check for a valid signature, maps nearly 4GB of memory, then starts calculating the checksum over that memory.
This is surfaced in TrueNAS in the virtual machine PCIe passthrough configuration (src/middlewared/middlewared/plugins/vm/pci_freebsd.py). The check for VT-d support is looking for the DMAR table, but that hangs on my machine. A couple of fixes:
- A quick and dirty workaround for my particular setup would be to check for AMD-Vi first, but this doesn't handle the case where the IOMMU isn't enabled.
- A better fix is to patch acpidump so that it checks for DSDT and FACS table validity seperately.
- Even better still would be to significantly rewrite acpidump so that is uses more of the functionality from the ACPI CA sources that already handle cases like these (and I think is what is actually used by the kernel, but I haven't dug too far into this).
Attached is a patch for #2. It reworks how both the DSDT and FACS tables are chosen, preferring the 64-bit ones if they are valid. The previous changes to this area of the code were to add support for a buggy firmware on a Thinkpad T23, and while I don't have one of those handy to test with, I think that the changes would still work. The attached patch also refactors the DSDT printing a bit to reduce some code duplication. I'm also planning on submitting the patch upstream as well after I figure out how to do that.