Uploaded image for project: 'FreeNAS / TrueNAS'
  1. FreeNAS / TrueNAS
  2. NAS-107711

acpidump hangs when DSDT is 0 but XDSDT is valid

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Engineering Closed (View Workflow)
    • Priority: Low
    • Resolution: Third Party to Resolve
    • Affects Version/s: 12.0-RC1
    • Fix Version/s: N/A
    • Component/s: OS, VM
    • Labels:
      None

      Description

      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:

      FACS 0xda77ee80
      DSDT 0x0
      XFACS 0x0
      XDSDT 0xda419218

      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:

      1. 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.
      2. A better fix is to patch acpidump so that it checks for DSDT and FACS table validity seperately.
      3. 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.

        Attachments

          Attachments

            JEditor

              Activity

                People

                Assignee:
                releng Release Council
                Reporter:
                paxswill Will Ross
                Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: