From owner-freebsd-bugs@freebsd.org Thu Mar 28 08:25:57 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 31B9B1550CFB for ; Thu, 28 Mar 2019 08:25:57 +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 BD9558AEC0 for ; Thu, 28 Mar 2019 08:25:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 80CE81550CF9; Thu, 28 Mar 2019 08:25:56 +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 598AD1550CF8 for ; Thu, 28 Mar 2019 08:25:56 +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 E44398AEBB for ; Thu, 28 Mar 2019 08:25:55 +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 26E9C1F683 for ; Thu, 28 Mar 2019 08:25:55 +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 x2S8Ptn0093713 for ; Thu, 28 Mar 2019 08:25:55 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x2S8PtZd093711 for bugs@FreeBSD.org; Thu, 28 Mar 2019 08:25:55 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: Thu, 28 Mar 2019 08:25:54 +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: avg@FreeBSD.org 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: Thu, 28 Mar 2019 08:25:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236513 --- Comment #34 from Andriy Gapon --- (In reply to stockhausen from comment #32) 1. Ah, you are right, I forgot that modern processors intercept C-state I/O accesses at a core level. Just to clarify, I assume that on your T620 cpucontrol -m 0xC0010073 /dev/cpuctl0 gives 0x414? 3.b(2) The root bridge has a range that covers 0x414, so that's okay. A. I do not think so. I think that the code currently expects BIOS to set = up everything correctly. We could try to think about how FreeBSD ACPI code cou= ld work around not having Cx I/O ports in the system resources... By the way, I see why acpi cpu devices cannot share a resource if it's not = an acpi system resource. If a resource is a system resource then it is alloca= ted from the nexus (very early) and the acpi bus manages it on its own. That m= eans that acpi_set_resource() -> resource_list_reserve(flags=3D0) -> resource_list_alloc() -> BUS_ALLOC_RESOURCE() -> nexus_alloc_resource() -> rman_reserve_resource(flags=3D0) would always fail. But that's okay, becau= se acpi_alloc_resource() has a fallback to acpi_alloc_sysres(). And if the resource is consistently allocated with RF_SHARED, then all allocations of = it succeed. If a resource is _not_ a system resource, then the resource is not allocate= d by the acpi bus in the nexus as the acpi bus is unaware of it. Then, when the first cpu calls acpi_PkgGas() -> acpi_bus_alloc_gas() -> bus_set_resource()= -> acpi_set_resource() -> resource_list_reserve(flags=3D0) -> resource_list_alloc(flags=3D0) -> BUS_ALLOC_RESOURCE(flags=3D0) -> nexus_alloc_resource(flags=3D0) -> rman_reserve_resource(flags=3D0), the re= source is allocated in the nexus and it is allocated without RF_SHARED flag. Beca= use the allocation is successful, the resource is added to the device's resource list. After bus_set_resource(), acpi_bus_alloc_gas() calls bus_alloc_resource_any() -> acpi_alloc_resource(flags=3DRF_ACTIVE|RF_SHARED= ) -> resource_list_alloc(). Because the resource already exists in the device's resource list, resource_list_alloc() would simply activate it and return. So, for the first cpu acpi_bus_alloc_gas() is successful. For any subsequent cpu, this call chain acpi_PkgGas() -> acpi_bus_alloc_gas= () -> bus_set_resource() -> acpi_set_resource() -> resource_list_reserve(flags= =3D0) -> resource_list_alloc(flags=3D0) -> BUS_ALLOC_RESOURCE(flags=3D0) -> nexus_alloc_resource(flags=3D0) -> rman_reserve_resource(flags=3D0) would f= ail because the resource is already allocated in nexus and it is not shared. T= hus, the resource would not be created in the device's resource list. Thus, the subsequent call to bus_alloc_resource_any() -> acpi_alloc_resource(flags=3DRF_ACTIVE|RF_SHARED) -> resource_list_alloc() w= ould not find that resource and it would have to call BUS_ALLOC_RESOURCE() -> nexus_alloc_resource() -> rman_reserve_resource() and that would fail again= for the same reason. And, in this case, acpi_alloc_resource()'s fallback to acpi_alloc_sysres() would also fail, because the resource is not a system resource. In the end, acpi_PkgGas() -> acpi_bus_alloc_gas() fails just as = you have seen. B. I would add 0x414 to CRS of Device S900. E.g. using 0x040B as an exampl= e, I would add this just after it: IO (Decode16, 0x0414, // Range Minimum 0x0414, // Range Maximum 0x00, // Alignment 0x04, // Length ) --=20 You are receiving this mail because: You are the assignee for the bug.=