On Tue, Dec 16, 2014 at 2:45 PM, Hrvoje Popovski <hrv...@srce.hr> wrote: > on R630 i have custom bios settings and noticed that even if C states are > disabled in bios i can see them in dmesg > acpicpu0 at acpi0: C1
Uh, ACPI *requires* that C1 exist. The halt instruction is defined as entering C1, so not having C1 would mean your CPU lacks a basic manadatory ia32 instruction. Hopefully the BIOS docs explain that you're just disabling "deep" C-states or something like that. If not, yell at the company that made it. With the exception of "C1E", I wouldn't tell a BIOS to disable C-states unless it was causing the OS to have a problem or you're actively trying to use the computer to heat your house. "C1E" is a cross between C1 and C3; the issue is that bugs in multiple early hardware implementations mean it'll behave poorly depending on exactly how the OS handles it. This is something to test...and then test again with each release you install... > X2Apic is disabled too but in dmesg i see > cpu0: FPU,CPI,.......SSE4.1,SSE4.2,x2APIC That just means the CPU has the feature bit set in the CPUID sets. The BIOS is presumably configuring ACPI (which is what OpenBSD pays attention to) to use the original LAPIC tables instead of the x2APIC tables for locating CPUs and interrupts. > R620 have similar settings and can't see C states in dmesg > acpicpu0 at acpi0 That's either insane, or a bug in our acpicpu code, IMO. > R620 bios settings ... > Monitor/Mwait - Disabled I would suggest leaving that on. We ain't using it *right now*, but, well, the source tree on my laptop is, and more than ever. :-) Philip Guenther
