From owner-freebsd-bugs@freebsd.org Wed Mar 27 08:09:01 2019 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F5D71547925 for ; Wed, 27 Mar 2019 08:09:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C53D56ABF4 for ; Wed, 27 Mar 2019 08:09:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8420B1547924; Wed, 27 Mar 2019 08:09:00 +0000 (UTC) Delivered-To: bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5CB5C1547923 for ; Wed, 27 Mar 2019 08:09:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E73E06ABF2 for ; Wed, 27 Mar 2019 08:08:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 104271220A for ; Wed, 27 Mar 2019 08:08:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x2R88w4i098173 for ; Wed, 27 Mar 2019 08:08:58 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2R88wD4098172 for bugs@FreeBSD.org; Wed, 27 Mar 2019 08:08:58 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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 Date: Wed, 27 Mar 2019 08:08:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: stockhausen@collogia.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 08:09:01 -0000 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.=