acpidump: corrupt RSDT entry (sig SSDT)

JMOR · Sep 13, 2021

Hi,

How could I try and debug, and hopefully fix, the ACPI tables dumped by acpidump?

If I run acpidump -t, I get:

Code:

...
        Type=INT Override
        BUS=0
        IRQ=9
        INTR=9
        Flags={Polarity=active-lo, Trigger=level}
 */
acpidump: RSDT entry 21 (sig SSDT) is corrupt
/*
  FPDT: Length=68, Revision=1, Checksum=100,
        OEMID=ALASKA, OEM Table ID=A M I, OEM Revision=0x1072009,
        Creator ID=AMI, Creator Revision=0x1000013
 */

Here it is the complete output of dmesg, but I think the interesting part may be this:

Code:

acpi_wmi0: <ACPI-WMI mapping> on acpi0
acpi_wmi0: cannot find EC device
acpi_wmi0: Embedded MOF found
ACPI: \134AOD.WQBA: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
acpi_wmi1: <ACPI-WMI mapping> on acpi0
acpi_wmi1: cannot find EC device
acpi_wmi2: <ACPI-WMI mapping> on acpi0
acpi_wmi2: cannot find EC device
acpi_wmi2: Embedded MOF found
ACPI: \134_SB.WMIC.WQBA: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
acpi_wmi3: <ACPI-WMI mapping> on acpi0
acpi_wmi3: cannot find EC device

My motherboard is a MSI MEG X570 UNIFY, and I already flashed the BIOS to the latest (non-beta) version to no avail.

Thanks in advance.

JMOR · Sep 14, 2021

I disable acpi_wmi() in the kernel:

Code:

nodevice        acpi_wmi
makeoptions     WITHOUT_MODULES="acpi/acpi_wmi"

So the quoted part above in dmesg's output stopped showing anymore. But the problem persists, acpidump() can't get the tables.

Enabling acpi_wmi() again.

mer · Sep 14, 2021

It could something as simple as acpidump is not recognizing how the tables are formatted.
Or the tables themselves could be corrupt or non standard format.

It's not unknown for acpi tables to be bad and need to be fixed up.

George · Sep 14, 2021

Do these tables (RSDT SSDT) even matter?
Wikipedia says that for 64 bit systems, there is XSDT. https://wiki.osdev.org/RSDT

Code:

"XSDT": Extended System Description Table (XSDT; 64-bit version of the RSDT)

Or maybe I misread that..

VladiBG · Sep 14, 2021

George said:
Do these tables (RSDT SSDT) even matter?

This allows the OEM to provide the base support in one table and add smaller system options in other tables. For example, the OEM might put dynamic object definitions into a secondary table such that the firmware can construct the dynamic information at boot without needing to edit the static DSDT. A SSDT can only rely on the DSDT being loaded prior to it.

https://uefi.org/sites/default/files/resources/ACPI_5_0_Errata_B.pdf

JMOR · Sep 14, 2021

The thing is, in order to passthrough a PCI USB host controller to a Windows virtual machine - bhyve(), I need these ACPI tables going.
I could be missing something else, but the only thing off I detected (for the passthrough) was this.

And I am completely clueless, other than flash the BIOS to the lastest version (which I did) or open a ticket to MSI support, I don't know what to do.

I could install Linux and see how its acpidump behaves. But, backing up things here and changing the OS in the PC just to check that command, it will be a pain in the back.
For that matter, I may as well just install Proxmox(?) and launch everything (FreeBSD and Windows) as VMs from there. IF this ACPI tables "corruption" doesn't mess things there too.

VladiBG · Sep 14, 2021

According to the ACPI spec the checksum of the table must be 0 (mod 0x100). Maybe the table is corrupt or the OEM doesn't follow the ACPI spec.

freebsd-src/usr.sbin/acpi/acpidump/acpi.c at main · freebsd/freebsd-src

The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests.... - freebsd/freebsd-src

github.com

mer · Sep 14, 2021

JMOR said:
The thing is, in order to passthrough a PCI USB host controller to a Windows virtual machine - bhyve(), I need these ACPI tables going.
I could be missing something else, but the only thing off I detected (for the passthrough) was this.

And I am completely clueless, other than flash the BIOS to the lastest version (which I did) or open a ticket to MSI support, I don't know what to do.

I could install Linux and see how its acpidump behaves. But, backing up things here and changing the OS in the PC just to check that command, it will be a pain in the back.
For that matter, I may as well just install Proxmox(?) and launch everything (FreeBSD and Windows) as VMs from there. IF this ACPI tables "corruption" doesn't mess things there too.

Or see if a "live cd" of Linux has acpidump and just boot into that.

VladiBG · Sep 14, 2021

why did you need acpidump for bhyve anyway? To check if your computer support VT-d or something else?

iohyve / bhyve USB controller passthrough goodness

I used to have a Windows machine that was dedicated to running software for our printer since the open-source software wouldn't scan and pr...

baitisj.blogspot.com

JMOR · Sep 15, 2021

I didn't know about sysutils/iohyve. I am calling bhyve() directly.

I may indeed be doing something wrong for the PCI passthrough. I don't want to derail this thread. So, I will double check again to see what I may be missing. And, if I can't fix the issue, I will open another thread.

JMOR · Sep 17, 2021

Linux acpidump seems to dump the tables without problems.

I used acpidump from the package acpica-tools (ACPICA tools for the development and debug of ACPI tables). From an Ubuntu live cd:

Bash:

ubuntu@ubuntu:~$ sudo acpidump -sz

Intel ACPI Component Architecture
ACPI Binary Table Dump Utility version 20200925
Copyright (c) 2000 - 2020 Intel Corporation

ACPI: SSDT 0x0000000000000000 000024 (v01 AMD    BIXBY    00001000 INTL 20120913)
ACPI: MCFG 0x0000000000000000 00003C (v01 ALASKA A M I    01072009 MSFT 00010013)
ACPI: APIC 0x0000000000000000 00015E (v03 ALASKA A M I    01072009 AMI  00010013)
ACPI: CRAT 0x0000000000000000 001118 (v01 AMD    AmdTable 00000001 AMD  00000001)
ACPI: PCCT 0x0000000000000000 00006E (v02 AMD    AmdTable 00000001 AMD  00000001)
ACPI: SSDT 0x0000000000000000 003B1B (v01 AMD    AMD AOD  00000001 INTL 20120913)
ACPI: VFCT 0x0000000000000000 00EE84 (v01 ALASKA A M I    00000001 AMD  31504F47)
ACPI: SSDT 0x0000000000000000 00381A (v01 AMD    QOGIRN   00000001 INTL 20120913)
ACPI: CDIT 0x0000000000000000 000029 (v01 AMD    AmdTable 00000001 AMD  00000001)
ACPI: IVRS 0x0000000000000000 0001A4 (v02 AMD    AmdTable 00000001 AMD  00000001)
ACPI: DSDT 0x0000000000000000 006FD2 (v02 ALASKA A M I    01072009 INTL 20120913)
ACPI: SSDT 0x0000000000000000 0010B4 (v01 AMD    QOGIRTPX 00000001 INTL 20120913)
ACPI: WSMT 0x0000000000000000 000028 (v01 ALASKA A M I    01072009 AMI  00010013)
ACPI: SSDT 0x0000000000000000 005EF9 (v02 AMD    AmdTable 00000001 AMD  00000001)
ACPI: SSDT 0x0000000000000000 0010AF (v01 AMD    QOGIRC   00000001 INTL 20120913)
ACPI: SSDT 0x0000000000000000 000164 (v02 ALASKA CPUSSDT  01072009 AMI  01072009)
ACPI: FACP 0x0000000000000000 000114 (v06 ALASKA A M I    01072009 AMI  00010013)
ACPI: FPDT 0x0000000000000000 000044 (v01 ALASKA A M I    01072009 AMI  01000013)
ACPI: SSDT 0x0000000000000000 008C98 (v02 AMD    AmdTable 00000002 MSFT 04000000)
ACPI: SSDT 0x0000000000000000 00052C (v01 AMD    QOGIRNOI 00000001 INTL 20120913)
ACPI: HPET 0x0000000000000000 000038 (v01 ALASKA A M I    01072009 AMI  00000005)
ACPI: SSDT 0x0000000000000000 000293 (v01 AMD    QOGIRDGP 00000001 INTL 20120913)
ACPI: FIDT 0x0000000000000000 00009C (v01 ALASKA A M I    01072009 AMI  00010013)
ACPI: FACS 0x0000000000000000 000040
ACPI: BGRT 0x0000000000000000 000038 (v01 ALASKA A M I    01072009 AMI  00010013)

Here it is the whole dump for sudo acpidump. Well, a good chunk of it. I had to copy&paste by hand, and I got bored. But, all the rest is in the same vein. It dumped the whole thing.

And this is the ACPI tables directory

Bash:

ubuntu@ubuntu:~$ ll /sys/firmware/acpi/tables/
total 0
drwxr-xr-x 4 root root     0 Sep 17  2021 ./
drwxr-xr-x 6 root root     0 Sep 17  2021 ../
-r-------- 1 root root   350 Sep 16 22:38 APIC
-r-------- 1 root root    56 Sep 16 22:38 BGRT
-r-------- 1 root root    41 Sep 16 22:38 CDIT
-r-------- 1 root root  4376 Sep 16 22:38 CRAT
drwxr-xr-x 2 root root     0 Sep 16 22:38 data/
-r-------- 1 root root 28626 Sep 16 22:38 DSDT
drwxr-xr-x 2 root root     0 Sep 16 22:38 dynamic/
-r-------- 1 root root   276 Sep 16 22:27 FACP
-r-------- 1 root root    64 Sep 16 22:38 FACS
-r-------- 1 root root   156 Sep 16 22:38 FIDT
-r-------- 1 root root    68 Sep 17  2021 FPDT
-r-------- 1 root root    56 Sep 16 22:38 HPET
-r-------- 1 root root   420 Sep 16 22:38 IVRS
-r-------- 1 root root    60 Sep 16 22:38 MCFG
-r-------- 1 root root   110 Sep 16 22:38 PCCT
-r-------- 1 root root 35992 Sep 16 22:38 SSDT1
-r-------- 1 root root  4271 Sep 16 22:38 SSDT10
-r-------- 1 root root 15131 Sep 16 22:38 SSDT2
-r-------- 1 root root   356 Sep 16 22:38 SSDT3
-r-------- 1 root root    36 Sep 16 22:38 SSDT4
-r-------- 1 root root 24313 Sep 16 22:38 SSDT5
-r-------- 1 root root   659 Sep 16 22:38 SSDT6
-r-------- 1 root root  4276 Sep 16 22:38 SSDT7
-r-------- 1 root root  1324 Sep 16 22:38 SSDT8
-r-------- 1 root root 14362 Sep 16 22:38 SSDT9
-r-------- 1 root root 61060 Sep 16 22:38 VFCT
-r-------- 1 root root    40 Sep 16 22:38 WSMT

mer · Sep 17, 2021

That sounds like "version difference"; probably the FreeBSD version needs to be updated. I'd check the ports tree (packages) see if there is an updated version that may work.
A quick pkg search acpi on a 13.0-RELEASE shows acpica-tools-20210604. Perhaps that would work better.

JMOR · Sep 17, 2021

Well, this is strange.

There is that same tool in the ports: sysutils/acpica-tools.

I installed it, and this is its output:

Bash:

1011 /usr/ports/sysutils/acpica-tools # /usr/local/bin/acpidump -zs

Intel ACPI Component Architecture
ACPI Binary Table Dump Utility version 20210331
Copyright (c) 2000 - 2021 Intel Corporation


ACPI: XSDT 0x00000000DCBED728 0000DC (v01 ALASKA A M I    01072009 AMI  01000013)
ACPI: FACS 0x00000000DCBE8000 000040
ACPI: DSDT 0x00000000DB0F1000 006FD2 (v02 ALASKA A M I    01072009 INTL 20120913)
ACPI: FACP 0x00000000DB0F8000 000114 (v06 ALASKA A M I    01072009 AMI  00010013)
ACPI: SSDT 0x00000000DB0FE000 008C98 (v02 AMD    AmdTable 00000002 MSFT 04000000)
ACPI: SSDT 0x00000000DB0FA000 003B1B (v01 AMD    AMD AOD  00000001 INTL 20120913)
ACPI: SSDT 0x00000000DB0F9000 000164 (v02 ALASKA CPUSSDT  01072009 AMI  01072009)
ACPI: FIDT 0x00000000DB0F0000 00009C (v01 ALASKA A M I    01072009 AMI  00010013)
ACPI: MCFG 0x00000000DB0EF000 00003C (v01 ALASKA A M I    01072009 MSFT 00010013)
ACPI: HPET 0x00000000DB0EE000 000038 (v01 ALASKA A M I    01072009 AMI  00000005)
ACPI: SSDT 0x00000000DB0ED000 000024 (v01 AMD    BIXBY    00001000 INTL 20120913)
ACPI: IVRS 0x00000000DB0EC000 0001A4 (v02 AMD    AmdTable 00000001 AMD  00000001)
ACPI: VFCT 0x00000000DB0DD000 00EE84 (v01 ALASKA A M I    00000001 AMD  31504F47)
ACPI: PCCT 0x00000000DB0DC000 00006E (v02 AMD    AmdTable 00000001 AMD  00000001)
ACPI: SSDT 0x00000000DB0D6000 005EF9 (v02 AMD    AmdTable 00000001 AMD  00000001)
ACPI: CRAT 0x00000000DB0D4000 001118 (v01 AMD    AmdTable 00000001 AMD  00000001)
ACPI: CDIT 0x00000000DB0D3000 000029 (v01 AMD    AmdTable 00000001 AMD  00000001)
ACPI: BGRT 0x00000000DB0D2000 000038 (v01 ALASKA A M I    01072009 AMI  00010013)
ACPI: SSDT 0x00000000DB0D1000 000293 (v01 AMD    QOGIRDGP 00000001 INTL 20120913)
ACPI: SSDT 0x00000000DB0CF000 0010B4 (v01 AMD    QOGIRTPX 00000001 INTL 20120913)
ACPI: SSDT 0x00000000DB0CE000 00052C (v01 AMD    QOGIRNOI 00000001 INTL 20120913)
ACPI: SSDT 0x00000000DB0CA000 00381A (v01 AMD    QOGIRN   00000001 INTL 20120913)
ACPI: WSMT 0x00000000DB0C9000 000028 (v01 ALASKA A M I    01072009 AMI  00010013)
ACPI: APIC 0x00000000DB0C8000 00015E (v03 ALASKA A M I    01072009 AMI  00010013)
Firmware Warning (ACPI): Incorrect checksum in table [SSDT] - 0x04, should be 0x84 (20210331/tbprint-337)
ACPI: SSDT 0x00000000DB0C6000 0010AF (v01 AMD    QOGIRC   00000001 INTL 20120913)
ACPI: FPDT 0x00000000DB0C5000 000044 (v01 ALASKA A M I    01072009 AMI  01000013)

It is giving me a warning about the ACPI table. But the same application does not give me that warning from the Ubuntu live CD.

I assume, when bootstraping, the OS load those tables from the BIOS' ROM to RAM. And from RAM is where these acpidump programs, and everything else that access the tables, are getting the values.

So, maybe the way FreeBSD is reading those tables from BIOS may have some issues?

EDIT: The other 2 differences when executing acpidump (from sysutils/acpica-tools) in FreeBSD or in Linux are:

When run from Linux it gives zeros in the field for the memory address of the table(?), i.e. 0x0000000000000000. From FreeBSD it does report these adresses.
When run from FreeBSD it shows an additional table: XSDT. This table is not shown from Linux.

mer · Sep 17, 2021

I'm not sure exactly how it's done, but that sound like a reasonable path. Now the checksum error could be a simple "running over the wrong bits" or a bigger issue. Depending on the algorithm used it doesn't take much to change the calculated value.
Assuming that the other tables use the same algorithm and have checksums, it looks specific to the one table, not a general issue. I don't know or have any insight into how the tables are in ROM, in RAM, just that it is not unheard of for the data in ROM to be bad.
But, looks like 2 different versions of the tool (may or may not make a difference):

JMOR said:
Intel ACPI Component Architecture ACPI Binary Table Dump Utility version 20200925 Copyright (c) 2000 - 2020 Intel Corporation

JMOR said:
Intel ACPI Component Architecture ACPI Binary Table Dump Utility version 20210331 Copyright (c) 2000 - 2021 Intel Corporation