[Bug 236513] HP Thin clients T620/T730 ACPI: Only CPU core 0 detects C2 state

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Wed Mar 27 23:36:56 UTC 2019


Andriy Gapon <avg at FreeBSD.org> changed:

           What    |Removed                     |Added
                 CC|                            |jhb at FreeBSD.org

--- Comment #31 from Andriy Gapon <avg at FreeBSD.org> ---
I think I am starting to see what you've been saying.

So, first of all, as you discovered, your BIOS indeed provides a buggy ACPI
table.  But I am not sure where exactly the bug is.
It could be that the table does not provide a system resource for I/O port
0x414 by mistake.  Alternatively, it could be that 0x414 is a wrong value and
it should be something else (e.g., 0x814).  In that case, even when you get C2
state to appear it actually would not do its job.

The other problem, as you noted, that if 0x414 is not defined as a system
resource, then only cpu0 is able to allocate it.  All other cpu devices fail to
do it.  I haven't fully understood yet why that happens.  And also I am not
sure if that is what should really happen.

The best way to fix this problem is to fix the BIOS / ACPI, of course.
But I wonder if there is anything that FreeBSD could do to work around or
"quirk up" such a problem.

0x814 I mentioned is not an arbitrary port.
I see it on some AMD systems, although with different processors.
Also, all other processor related ACPI IO ports seem to be in the 0x800 area.
And it seems that PMBS and PMLN constants are supposed to define the processor
power management I/O region as a system resource.
The relevant section of the BKDG document for your processor is
So, I guess the only way to learn the true value of PLvl2 register is to
somehow read what's in PMx66 register.

P.P.S. The PCI root bridge settings appear to be correct and I do not see them
contributing to the problem.

You are receiving this mail because:
You are the assignee for the bug.

More information about the freebsd-bugs mailing list