ACPI BIOS Warning (bug): 32/64X length mismatch ...

[Winston]

On an amd64 machine, I never saw this warning prior to booting with
10.2-RELEASE (long line wrapped for readability):

+ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: \
64/32 (20150515/tbfadt-644)

* Why is this now a problem when it wasn't with 10.1-RELEASE and before?

* What's needed to resolve the problem?

TIA,
-WBE

[Lowell Gilbert]

Winston <w...@UBEBLOCK.psr.com.invalid> writes:

> On an amd64 machine, I never saw this warning prior to booting with
> 10.2-RELEASE (long line wrapped for readability):
>
> +ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: \
> 64/32 (20150515/tbfadt-644)
>
> * Why is this now a problem when it wasn't with 10.1-RELEASE and before?

Newer versions of ACPI introduced 64-bit representations of General
Purpose Event (GPE) descriptions. The old 32-bit representations are
still present as well, but are supposed to be consistent with the 64-bit
versions. On your system, they are not; this could be an indicator that
your firmware is corrupted, but in that case you would also (probably)
get warnings about failed checksums.

> * What's needed to resolve the problem?

This message shows a bug in your BIOS. If there are no other signs of
problems, you don't need to worry about it (some of the functionality
that GPE0 is likely to describe would include temperature sensors,
sleep/wake functionality, hyperthreading, and so on). A manufacturer
BIOS update might well fix the bug, but the kernel will (as the standard
requires) use the 64-bit GPE registers anyway.

Don't pull the Panic Lever too quickly for kernel warnings: if they were
guaranteed to be a problem, they would be "errors" instead of
"warnings". I think a system will usually run without GPE0/1 handlers,
but the power management may be less functional.

Good luck.
--
Lowell Gilbert, embedded/networking software engineer
http://be-well.ilk.org/~lowell/

[Winston]

I originally asked:

>> On an amd64 machine, I never saw this warning prior to booting with
>> 10.2-RELEASE (long line wrapped for readability):
>>
>> +ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: \
>> 64/32 (20150515/tbfadt-644)
>>
>> * Why is this now a problem when it wasn't with 10.1-RELEASE and before?

to which Lowell Gilbert <lgus...@be-well.ilk.org> kindly replied:

> Newer versions of ACPI introduced 64-bit representations of General
> Purpose Event (GPE) descriptions. The old 32-bit representations are
> still present as well, but are supposed to be consistent with the 64-bit
> versions. On your system, they are not; this could be an indicator that
> your firmware is corrupted, but in that case you would also (probably)
> get warnings about failed checksums.

Assuming that upgrading from 10.1 to 10.2 yesterday didn't corrupt
anything, that leaves the question of why now? Two obvious
possibilities are:
1) the same issue existed under 10.1, and 10.2 only added the warning
message,
and
2) 10.2 is stricter about this, which might mean trouble for anyone
upgrading to 10.2 on a system with an older BIOS (from before the
ACPI 64-bit GPE change).

Any idea which is the case or where to find out which is the case?

>> * What's needed to resolve the problem?

> This message shows a bug in your BIOS.

Quibble:

The BIOS in question is less than 3 years old. Would it have been a bug
in Oct. 2012? Changing FreeBSD in the direction of "we're not going to
accept that any more" (if, indeed, that's what's being done) for
something only 3 years old looks to me more like an end-of-life /
no-longer-supported-architecture type of decision, not what I'd call a
"bug".

> Don't pull the Panic Lever too quickly for kernel warnings: if they
> were guaranteed to be a problem, they would be "errors" instead of
> "warnings". I think a system will usually run without GPE0/1
> handlers, but the power management may be less functional.

No panic here, but I'm motivated to look for the cause and solution for
this because 1) I prefer full functionality over limping along :), and
2) there was no indication of any such problem under 10.1 two days ago.

> A manufacturer BIOS update might well fix the bug, but the kernel will
> (as the standard requires) use the 64-bit GPE registers anyway.

I just got a reply back from the motherboard manufacturer: in the
Release Notes for the latest AMIBIOS for the board (Nov. 2013), there is
no mention of any ACPI-related fixes. They're asking for more info
about the problem.

> Good luck.

Thanks, and thank you for the reply,
-WBE

[Winston]

I started the thread with:

>> On an amd64 machine, I never saw this warning prior to booting with
>> 10.2-RELEASE (long line wrapped for readability):

>> +ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: \
>> 64/32 (20150515/tbfadt-644)

Among all the lines produced by acpidump -dt, I see the following:

--> PM1a_EVT_BLK=0x800-0x803
--> PM1a_CNT_BLK=0x804-0x805
--> PM2_CNT_BLK=0xfe00-0xfe00
--> PM_TMR_BLK=0x808-0x80b
--> GPE0_BLK=0x820-0x827
CST_CNT=0xe3
P_LVL2_LAT=101 us, P_LVL3_LAT=1001 us
FLUSH_SIZE=1024, FLUSH_STRIDE=16
DUTY_OFFSET=1, DUTY_WIDTH=3
DAY_ALRM=13, MON_ALRM=0, CENTURY=50
IAPC_BOOT_ARCH={LEGACY_DEVICES,8042}
Flags={WBINVD,C1_SUPPORTED,SLEEP_BUTTON,S4_RTC_WAKE}
--> X_FACS=0x00000000dfeb2000, X_DSDT=0x00000000dfea0600
--> X_PM1a_EVT_BLK=0x800:0[32] (IO)
--> X_PM1a_CNT_BLK=0x804:0[16] (IO)
--> X_PM_TMR_BLK=0x808:0[32] (IO)
--> X_GPE0_BLK=0x820:0[32] (IO)

...
OperationRegion (GPE0, SystemIO, GP0B, 0x10)
Field (GPE0, ByteAcc, NoLock, Preserve)
{
Offset (0x04),
, 27,
GPM6, 1
}

Does any of that indicate anything helpful relevant to the warning?

Thanks in advance,
-WBE

[Lowell Gilbert]

Winston <w...@UBEBLOCK.psr.com.invalid> writes:

> I originally asked:
>>> On an amd64 machine, I never saw this warning prior to booting with
>>> 10.2-RELEASE (long line wrapped for readability):
>>>
>>> +ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: \
>>> 64/32 (20150515/tbfadt-644)
>>>
>>> * Why is this now a problem when it wasn't with 10.1-RELEASE and before?
>
> to which Lowell Gilbert <lgus...@be-well.ilk.org> kindly replied:
>> Newer versions of ACPI introduced 64-bit representations of General
>> Purpose Event (GPE) descriptions. The old 32-bit representations are
>> still present as well, but are supposed to be consistent with the 64-bit
>> versions. On your system, they are not; this could be an indicator that
>> your firmware is corrupted, but in that case you would also (probably)
>> get warnings about failed checksums.
>
> Assuming that upgrading from 10.1 to 10.2 yesterday didn't corrupt
> anything, that leaves the question of why now? Two obvious
> possibilities are:
> 1) the same issue existed under 10.1, and 10.2 only added the warning
> message,
> and
> 2) 10.2 is stricter about this, which might mean trouble for anyone
> upgrading to 10.2 on a system with an older BIOS (from before the
> ACPI 64-bit GPE change).
>
> Any idea which is the case or where to find out which is the case?

Number 1 is certainly true. My build machine is powered down at the
moment, so I can't check on whether number 2 has any basis at all.

>>> * What's needed to resolve the problem?
>
>> This message shows a bug in your BIOS.
>
> Quibble:
>
> The BIOS in question is less than 3 years old. Would it have been a bug
> in Oct. 2012? Changing FreeBSD in the direction of "we're not going to
> accept that any more" (if, indeed, that's what's being done) for
> something only 3 years old looks to me more like an end-of-life /
> no-longer-supported-architecture type of decision, not what I'd call a
> "bug".
>
>> Don't pull the Panic Lever too quickly for kernel warnings: if they
>> were guaranteed to be a problem, they would be "errors" instead of
>> "warnings". I think a system will usually run without GPE0/1
>> handlers, but the power management may be less functional.
>
> No panic here, but I'm motivated to look for the cause and solution for
> this because 1) I prefer full functionality over limping along :), and
> 2) there was no indication of any such problem under 10.1 two days ago.

It's a warning message. If you are having any actual problems with the
system, it may be a clue as to why, but (so far) you haven't mentioned
*any* problems that your system is actually having. Unless there's
something obviously wrong that you haven't included in your postings,
it's vastly unlikely that this bug (and the warning message noting it)
is anything other than benign.

>> A manufacturer BIOS update might well fix the bug, but the kernel will
>> (as the standard requires) use the 64-bit GPE registers anyway.
>
> I just got a reply back from the motherboard manufacturer: in the
> Release Notes for the latest AMIBIOS for the board (Nov. 2013), there is
> no mention of any ACPI-related fixes. They're asking for more info
> about the problem.

Assuming there is a problem in the first place...

[Winston]

I originally asked:
>>>> On an amd64 machine, I never saw this warning prior to booting with
>>>> 10.2-RELEASE (long line wrapped for readability):

>>>> +ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: \
>>>> 64/32 (20150515/tbfadt-644)

>>>> * Why is this now a problem when it wasn't with 10.1-RELEASE and before?

Lowell Gilbert <lgus...@be-well.ilk.org> kindly replied:

>>> ... if they were guaranteed to be a problem, they would be "errors"

>>> instead of "warnings". I think a system will usually run without
>>> GPE0/1 handlers, but the power management may be less functional.

and, in a later message, said:
> It's a warning message. If you are having any actual problems with the
> system, it may be a clue as to why, but (so far) you haven't mentioned
> *any* problems that your system is actually having. Unless there's
> something obviously wrong that you haven't included in your postings,
> it's vastly unlikely that this bug (and the warning message noting it)
> is anything other than benign.

I haven't noticed any actual problems so far, but if "power management
may be less functional" or the CPU temperature sensors or fan speed
control don't work or something of the sort, maybe it's something I
wouldn't see now but that shouldn't be left until it becomes an actual
problem. (This is mostly a statement based on fear of the unknown since
I don't have any feel for what, if anything, breaks when the Gpe0Block
has this sort of problem.)

Thanks, Lowell.
-WBE

[Lowell Gilbert]

In an ideal world, your preference is perfectly reasonable. However,
figuring this out requires access to the AMI BIOS source code.

I'll digress a bit to explain how the different pieces work together,
because you seem to be interested (ignore this paragraph otherwise). ACPI
provides the ability for an operating system to not only get the BIOS to
do specfic things for it, but also to enumerate those things, so that the
operating system can utilize a specific function on all systems that
provide it. The OS doesn't need to know anything about what the BIOS
provides and how to access them: it can just ask. FreeBSD doesn't develop
its own routines for looking things up in the ACPI tables: like most
operating systems, it uses the ACPI Component Architecture (an
Intel-backed open source project) with minor tweaks. All of this
complexity allows hardware to have a closed-source BIOS yet run operating
systems that the BIOS creators have never heard of.

I've looked at the code changes in enough detail to figure out that in the
case of the length mismatch in your BIOS, the changes from FreeBSD 10.1 to
10.2 will give the possibility of different behaviour. Specifically, the
length from the 64-bit definition of the registers will be used, where
previously it would use the 32-bit definition. Strangely enough, your
system has 32 events in its 64-bit event block, while it has 39 in the
32-bit version. In both cases, the address is the same, so the first 32
will work the same way. If there are events in that last nine, they
will no longer work. To check this would likely require looking at the
contents of the GPE Scope in the output of acpidump -d from an older
version of FreeBSD, assuming the the dump code works the way I assume, and
a fair amount of hacking to be sure. And it would only matter if FreeBSD
actually uses those events in the first place.

So: in theory, these changes might decrease functionality in your
system. But it would take a fair amount of work to to be sure, and it
seems quite unlikely, and is even less likely to be something you'd
notice.

If I were completely sure that Windows didn't contain code to special-case
this BIOS, I would be willing to promise that these changes would not be a
problem for you. However, since the motherboard manufacturer may well have
provided its own Windows drivers for the power functionality, I'm not
willing to go quite that far. But that's so unlikely that I'll promise to
help you fix any problem if I turn out to be wrong.

Good luck (not that I think you need it with this).

[Winston]

Wow. Thank you for taking the time to look into this and write it up.
I am, indeed, interested.

Lowell very kindly did some work looking into the issue and then posted:

> I've looked at the code changes in enough detail to figure out that in
> the case of the length mismatch in your BIOS, the changes from FreeBSD
> 10.1 to 10.2 will give the possibility of different behaviour.
> Specifically, the length from the 64-bit definition of the registers
> will be used, where previously it would use the 32-bit definition.
> Strangely enough, your system has 32 events in its 64-bit event block,

> while it has 39 in the 32-bit version. [...] To check this would

> likely require looking at the contents of the GPE Scope in the output
> of acpidump -d from an older version of FreeBSD, assuming the the dump

> code works the way I assume, ...

It'll probably be around Labor Day weekend before I get time to try it,
but I'll create a 10.1 memstick, boot from it, do acpidump -dt, and
compare the result with the 10.2 output. Perhaps that will at least
shed some light on what the other 7 events are. I'll post a follow up
once I have those results.

Thanks, again!
-WBE

[Winston]

My original question was in regard to the boot time warning:

+ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 (20150515/tbfadt-644)

Now that I have acpidump -dt from 10.1 to compare with 10.2 ...

Previously, Lowell very kindly did some work looking into the issue and

then posted:
>> I've looked at the code changes in enough detail to figure out that in
>> the case of the length mismatch in your BIOS, the changes from FreeBSD
>> 10.1 to 10.2 will give the possibility of different behaviour.
>> Specifically, the length from the 64-bit definition of the registers
>> will be used, where previously it would use the 32-bit definition.
>> Strangely enough, your system has 32 events in its 64-bit event block,
>> while it has 39 in the 32-bit version. [...] To check this would
>> likely require looking at the contents of the GPE Scope in the output
>> of acpidump -d from an older version of FreeBSD, assuming the the dump
>> code works the way I assume, ...

[It might use the smaller number. See below.]

I replied:

> It'll probably be around Labor Day weekend before I get time to try it,
> but I'll create a 10.1 memstick, boot from it, do acpidump -dt, and

> compare the result with the 10.2 output. [...] I'll post a follow up

> once I have those results.

This is that followup.

High order result:

There were many differences on a line-by-line basis including 32/64
bit pointer differences (e.g., X_FACS=0x00000000dfeb2000 vs.
X_FACS=0xdfeb2000), but I saw no structural difference between
the 10.1 and 10.2 acpidump -dt outputs. They both had the same
number of items with the same values.

That suggests to me there's no operational difference between 10.1
and 10.2 (my original concern).


Details:

There were lots of lines I had to compare "by eye" because the old/10.1
acpidump used what look like macros, while the new/10.2 acpidump
produced more "C"-like output and more comments. E.g.,

704,709c706,711
< Store (Arg0, Index (PRWP, Zero))
< Store (ShiftLeft (SS1, One), Local0)
< Or (Local0, ShiftLeft (SS2, 0x02), Local0)
< Or (Local0, ShiftLeft (SS3, 0x03), Local0)
< Or (Local0, ShiftLeft (SS4, 0x04), Local0)
< If (And (ShiftLeft (One, Arg1), Local0))
---
> Index (PRWP, Zero) = Arg0
> Local0 = (SS1 << One)
> Local0 |= (SS2 << 0x02)
> Local0 |= (SS3 << 0x03)
> Local0 |= (SS4 << 0x04)
> If (((One << Arg1) & Local0))


All those differences were pretty clear matches except six of the form:

5558,5562c5558
< If (LEqual (Arg0, Buffer (0x10)
< {
< /* 0000 */ 0x5B, 0x4D, 0xDB, 0x33, 0xF7, 0x1F, 0x1C, 0x40,
< /* 0008 */ 0x96, 0x57, 0x74, 0x41, 0xC0, 0x3D, 0xD7, 0x66
< }))
---
> If ((Arg0 == ToUUID ("33db4d5b-1ff7-401c-9657-7441c03dd766") /* PCI Host Bridge Device */))

where I have no way of knowing whether ToUUID() interprets the byte
order the same way (though I expect it does).


As to GPE/GPE0, the "GPE"-related lines in both 10.1 and 10.2 said:

GPE0_BLK=0x820-0x827

X_GPE0_BLK=0x820:0[32] (IO)

OperationRegion (GPE0, SystemIO, GP0B, 0x10)
Field (GPE0, ByteAcc, NoLock, Preserve)
{
Offset (0x04),
, 27,
GPM6, 1
}

Also, aside from the addition of comments in the 10.2 version,
Scope (\_GPE) { ... } was exactly the same in both.


Since the two "acpidump -dt"s appear to match functionally, can it be
concluded that the warning message is just about the discrepancy between
(0x) "27" (=39) vs. 32 and that:

* 10.1 used the smaller number but didn't complain about the mismatch,
and
* the functional match between the acpidumps strongly indicates there's
no operational problem?

Thanks!
-WBE

[Lowell Gilbert]

Winston <w...@UBEBLOCK.psr.com.invalid> writes:

> Since the two "acpidump -dt"s appear to match functionally, can it be
> concluded that the warning message is just about the discrepancy between
> (0x) "27" (=39) vs. 32 and that:
>
> * 10.1 used the smaller number but didn't complain about the mismatch,
> and
> * the functional match between the acpidumps strongly indicates there's
> no operational problem?

You seem to have conclusively proven that case.

[Winston]

I previously compared acpidump -dt from 10.1 and 10.2 and wrapped up with:

>> Since the two "acpidump -dt"s appear to match functionally, can it be
>> concluded that the warning message is just about the discrepancy between
>> (0x) "27" (=39) vs. 32 and that:
>>
>> * 10.1 used the smaller number but didn't complain about the mismatch,
>> and
>> * the functional match between the acpidumps strongly indicates there's
>> no operational problem?

to which Lowell Gilbert <lgus...@be-well.ilk.org> kindly replied:

> You seem to have conclusively proven that case.

Glad to hear it. Thanks for your replies, for elucidatingwhat's going
on, and for suggesting acpidump, since that provided evidence for
concluding there's not a problem in this case.

I'm hesitant to say "conclusively", though. I've written enough
software to know that the debugging tools can have bugs, too. ;-)
(Imagine if the 10.1 acpidump had a bug that caused it to skip events
32-39 when they're really important ones. :)

Thanks,
-WBE