[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 08:09:01 UTC 2019


--- Comment #26 from stockhausen at collogia.de ---
(In reply to Andriy Gapon from comment #25)

Sorry for the confusion. I'm totally new to the topic and try to do my best to
explain my observations more clear.

The thin clients I'm talking about have a C2 power saving state that is
controlled by port 0x414. This port is the same for all 4 cores. Due to the
ACPI cpu startup logic the port reservation must work for each individual core.
If it fails C2 is not available for a core.

In the buggy case we can see:

1. System registers all known ports in acpi_sysres_alloc() in resource manager.
Port 0x414 is skipped because it is not correctly defined. There exists a BIOS
range 0x3e0 with 2328 ports but it is located directly under the PCI bridge. 
2. So we have no range under acpi0 > I/O ports that covers port 0x414.
3. CPUs are fired up and do their initialization. The first CPU wants to
register port 0x414. As it is not yet managed the registration process hangs
the port as "I/O port" below CPU0.
4. The second CPU tries to do the same but it fails. For whatever reason


    I/O ports:
  cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.P000
        I/O ports: <-- Notice no type ACPI!

Now to the fixed case:

1. I found a port range 0x40B-0x40B in the ACPI tables that registers fine in
acpi_sysres_alloc() just before the CPUs.
2. I modified the ACPI tables and extended the range to something larger that
also covers port 0x414
3. After a restart with the modified table port 0x414 is now covered by a range
under acpi0 > I/O ports.
4. During CPU startup all CPUs can correctly allocate port 0x414 and a "copy"
named "ACPI I/O port" is placed under each CPU core.


    I/O ports:
  cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.P000
        ACPI I/O ports:  <-- Notice type ACPI!

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

More information about the freebsd-bugs mailing list