Date: Wed, 27 Mar 2019 23:36:53 +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-O3Wu9MaRpQ@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 Andriy Gapon <avg@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org --- Comment #31 from Andriy Gapon <avg@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 a= nd 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 fai= l 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. P.S. 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 are= a. And it seems that PMBS and PMLN constants are supposed to define the proces= sor power management I/O region as a system resource. The relevant section of the BKDG document for your processor is 3.25.15.5. 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 t= hem contributing to the problem. --=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-O3Wu9MaRpQ>