Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Mar 2019 08:08:58 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 236513] HP Thin clients T620/T730 ACPI:  Only CPU core 0 detects C2 state
Message-ID:  <bug-236513-227-tupFdBdW1y@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-236513-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-236513-227@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236513

--- Comment #26 from stockhausen@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 c=
ore.
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 mana=
ger.
Port 0x414 is skipped because it is not correctly defined. There exists a B=
IOS
range 0x3e0 with 2328 ports but it is located directly under the PCI bridge=
.=20
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

Result:

nexus0
  acpi0
    I/O ports:
  cpu0 pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_PR_.P000
        I/O ports: <-- Notice no type ACPI!
            0x414=20=20

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 th=
at
also covers port 0x414
3. After a restart with the modified table port 0x414 is now covered by a r=
ange
under acpi0 > I/O ports.
4. During CPU startup all CPUs can correctly allocate port 0x414 and a "cop=
y"
named "ACPI I/O port" is placed under each CPU core.

Result:

nexus0
  acpi0
    I/O ports:
      0x400-0x41f
  cpu0 pnpinfo _HID=3Dnone _UID=3D0 at handle=3D\_PR_.P000
        ACPI I/O ports:  <-- Notice type ACPI!
            0x414

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-236513-227-tupFdBdW1y>