Date: Wed, 13 Mar 2019 20:03:23 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 236513] Different power states (C1/C2/...) per CPU core Message-ID: <bug-236513-227-Ysd8O9o66b@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 #1 from Conrad Meyer <cem@freebsd.org> --- This is a Jaguar-class (Family 16h) AMD CPU. This information is probed automatically out of the ACPI information presen= ted by your BIOS. That code hasn't changed appreciably in 4 years. It seems y= our BIOS does not provide a _CST for all 4 cores, or it is invalid. Do you see any logs in dmesg about "skipping invalid Cx state" or similar? Ah, it might be possible that your CPU is new enough to define the cores as Device objects rather than Processor, but you're running too old of FreeBSD= to enumerate the Device objects and find appropriate C-states _CST tables? I don't know if r326956 has been MFCed to 11.x, but that change may address t= he issue. Early AP startup (present in 12.0, I think) may also affect this, but I'm n= ot sure. C-state enumeration on Family 17h AMD CPUs seems to work just fine on CURRE= NT. --=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-Ysd8O9o66b>