Boot message: acpidump: RSDT entry 4 is corrupt

[acampbell]

"acpidump: RSDT entry 4 is corrupt"

I get this message during the boot sequence. Everything seems to work normally thereafter. I'd just upgraded to the latest snapshot but possibly it had appeared earlier - I only noticed it because I was sorting out an unrelated problem.

This is on a desktop; the message does not appear on a Thinkpad laptop.
After a search the only thing I could come up with was a bug report from 2014:
http://bugs.openbsd.narkive.com/mWGS...idump-problems

Should I just ignore it?

dmesg:

OpenBSD 6.0-current (GENERIC.MP) #150: Tue Jan 17 17:41:15 MST 2017
    build@amd64.openbsd.org:/usr/src/sys...ile/GENERIC.MP
real mem = 4268425216 (4070MB)
avail mem = 4134428672 (3942MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xfc670 (18 entries)
bios0: vendor American Megatrends Inc. version "R01-A3" date 08/28/2007
bios0: ACER Veriton M460
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIC OEMB HPET GSCI SSDT
acpi0: wakeup devices P0P2(S4) P0P1(S4) PS2M(S4) MC97(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) EUSB(S3) PWRB(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz, 2194.77 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,LONG,LAHF,PERF,SENSOR
cpu0: 2MB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz, 2194.50 MHz
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,LONG,LAHF,PERF,SENSOR
cpu1: 2MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec00000, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe0000000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (P0P1)
acpiprt2 at acpi0: bus 1 (P0P4)
acpiprt3 at acpi0: bus 2 (P0P5)
acpiprt4 at acpi0: bus -1 (P0P6)
acpiprt5 at acpi0: bus -1 (P0P7)
acpiprt6 at acpi0: bus -1 (P0P8)
acpiprt7 at acpi0: bus -1 (P0P9)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 110 degC
"PNP0700" at acpi0 not configured
"PNP0401" at acpi0 not configured
"PNP0F03" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0501" at acpi0 not configured
acpibtn0 at acpi0: PWRB
cpu0: Enhanced SpeedStep 2194 MHz: speeds: 2200, 1600, 1200 MHz
pci0 at mainbus0 bus 0

[jggimi]

An "RSDT" is an ACPI Root System Description Table. Something in yours (entry 4) apparently is incorrect, or at least it does not match ACPI standards.

I know that manufacturers' ACPI implementations do not necessarily follow the standards.

The acpidump(8) program can extract these tables, which may be of interest if you want to report this to the Project, conduct your own analysis, or even propose changes to the kernel -- you'll find ACPI management routines in /usr/src/sys/dev/acpi/.

And with that, you've reached the end of my ACPI knowledge.

[acampbell]

Thanks for your reply. My /usr/src is empty. I can't run acpidump because it says opening /dev/mem is not permitted. The man page says:

acpidump requires the ability to open /dev/kmem which may be restricted
based upon the value of the kern.allowkmem sysctl(8).

I tried changing this value with sysctl but that didn't work either. I guess I'd probably best just ignore the message. (Perhaps I could change system security temporarily to make acpidump work.)

[jggimi]

Originally Posted by acampbell

...My /usr/src is empty....

Source code is obtained by the administrator after installation. See "Fetching the source code" in the "Building the System from Source" chapter of the FAQ. The nearest link within that chapter is http://www.openbsd.org/faq/faq5.html#Bld

...I can't run acpidump...

You can run it as root, unless you decided to set your securelevel to 2. If you've done this, you have limited actions an administrator can perform to the running system. See securelevel(7) for the gory details.

[jggimi]

Hmmm. kern.allowkmem is a relatively new sysctl knob, added in -current. I don't have a test -current system at $DAYJOB. This is an opportunity to go install one.

[jggimi]

Installed, and in -current, one must be in single-user mode to run acpidump(8) unless you have set the sysctl before entering multuser mode in a normal boot

My apologies for the assumption; it was due to misunderstanding the operational change.

---


Just to level-set, you can boot into single user mode with boot> -s, or "drop" a running system into single user mode with # kill 1. See boot.conf(8) and init(8).

[jggimi]

Hah. On amd64, at least, you can set the sysctl non-zero, but the value will be ignored and you get a warning message.

Single-user mode is required for amd64.

[acampbell]

Thanks for your help, iggimi, following which I got acpidump to do its stuff in single-user mode. What it produced is actually the same as what I already have in /var/db/acpi, viz. a number of binary files plus a text file called headers:

SD PTR: Checksum=252, OEMID=ACPIAM, RsdtAddress=0xcf6b0000


RSDT: Length=68, Revision=1, Checksum=6,
        OEMID=ACRSYS, OEM Table ID=ACRPRDCT, OEM Revision=0x20070828,
        Creator ID=MSFT, Creator Revision=0x97


        Entries={ 0xcf6b0200, 0xcf6b0390, 0xcf6b0400, 0xcf6b0440, 0xcf6be040, 0xcf6b6040, 0xcf6be0c0, 0xcf6c0a10 }


        DSDT=0xcf6b05c0
        INT_MODEL=APIC
        SCI_INT=9
        SMI_CMD=0xb2, ACPI_ENABLE=0xe1, ACPI_DISABLE=0x1e, S4BIOS_REQ=0x0
        PM1a_EVT_BLK=0x800-0x803
        PM1a_CNT_BLK=0x804-0x805
        PM2_TMR_BLK=0x808-0x80b
        PM2_GPE0_BLK=0x828-0x82f
        P_LVL2_LAT=101ms, P_LVL3_LAT=1001ms
        FLUSH_SIZE=1024, FLUSH_STRIDE=16
        DUTY_OFFSET=1, DUTY_WIDTH=0
        DAY_ALRM=13, MON_ALRM=0, CENTURY=50
        Flags={WBINVD,PROC_C1,SLP_BUTTON,RTC_S4}


DSDT: Length=23154, Revision=1, Checksum=76,
        OEMID=1AAAA, OEM Table ID=1AAAA000, OEM Revision=0x0,
        Creator ID=INTL, Creator Revision=0x20051117


APIC: Length=108, Revision=1, Checksum=17,
        OEMID=082807, OEM Table ID=APIC1555, OEM Revision=0x20070828,
        Creator ID=MSFT, Creator Revision=0x97

MCFG: Length=60, Revision=1, Checksum=72,
        OEMID=082807, OEM Table ID=OEMMCFG, OEM Revision=0x20070828,
        Creator ID=MSFT, Creator Revision=0x97


SLIC: Length=374, Revision=1, Checksum=181,
        OEMID=ACRSYS, OEM Table ID=ACRPRDCT, OEM Revision=0x20070828,
        Creator ID=MSFT, Creator Revision=0x97

This doesn't mean a lot to me. I may ask on openbsd@.

[acampbell]

Just to report the outcome: I got no response on openbsd@ and google/duckduckgo produces very little (and mostly Windows stuff at that).

I found an option in the BIOS which allows me to disable acpi, which I've done. The boot error message goes away, of course, and everything seems to work normally so far. Man 4 acpi lists the devices that attach to acpi, none of which seem to be relevant to my desktop.

There is some discussion on the net about whether acpi is necessary for desktops; opinion seems to be divided, at least for Linux: see
https://www.experts-exchange.com/que...ux-Server.html

[jggimi]

Check your dmesg(8). With ACPI disabled in BIOS, does your kernel find and use apm(4)?

If not, the kernel will be unable to have any control over fans and heat management.

[acampbell]

There is no mention of apm in dmesg either with or without ACPI enabled. The two dmesgs are identical (I'd already checked that). There is also no sign of overheating without ACPI, over many hours.

Actually I don't see any mention of fan or temperature control in the man pages for apm and apmd unless I missed it.

[jggimi]

Originally Posted by acampbell

...The two dmesgs are identical...

Are you still seeing the acpi(4) driver in the dmesg(), then? If so, then it hasn't been disabled.

...There is also no sign of overheating without ACPI, over many hours....

The concern is heat management under high CPU load. And for amd64, ACPI is also needed for proper multiprocessor operation.

Actually I don't see any mention of fan or temperature control in the man pages for apm and apmd unless I missed it.

All such control is indirect -- direct temperature and fan knobs do not exist.

You will note in both apm(8) and apmd(8) the -A, -H and -L options for performance / power management. At one time there was also a -C for "cool" but it was removed during a tool redesign for OpenBSD 5.7.

[acampbell]

Sorry - yes, you are right. With ACPI disabled it says "acpi at bios0 not configured".

The temperature never goes above 48 degrees even when viewing a film online, which is the heaviest load I encounter.

But I note what you say about multiprocessor operation, which is obviously a concern. Both cpu0 and cpu1 appear to be recognised normally but perhaps I should keep acpi to make sure they work together correctly?

[jggimi]

If you wish to compare heat management with and without ACPI operating, try sysutils/stress. Keep a close eye on temperatures as you run it without ACPI.

Personally, I would not run any modern x86 hardware without it.

You may have both CPUs recognized, but are both being utilized?

(I run Core 2 Duos with Hyperthreading enabled, so there are 4 CPUs on my systems.)

[jggimi]

From misc@:

Originally Posted by Theo de Raadt

On almost all modern machines, acpi handling is *required*.

Originally Posted by Theo de Raadt

ACPI is REQUIRED. Any advice about disabling it is COMPLETELY AND UTTERLY FALSE AND MISLEADING. You will NOT get anywhere by disabling it. You might as well turn off cpu0 while at it.

-

https://www.mail-archive.com/misc@op.../msg99970.html
https://www.mail-archive.com/misc@op...msg124789.html

[acampbell]

Thanks for the further information. In view of this I will enable acpi and ignore the warning boot message. Perhaps it will go away in subsequent upgrades... Anyway, everything seems to work normally in spite of it as far as I can see.