Bug 121590
| Summary: | [est] [p4tcc] [acpi_perf] setting dev.cpu.0.freq sometimes gives "Invalid argument" | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Gu Xianjie <kevinxlinuz> |
| Component: | amd64 | Assignee: | freebsd-amd64 (Nobody) <amd64> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Gu Xianjie
2008-03-11 08:10:01 UTC
This has more to do with your cpufreq drivers than with powerd. Can you provide the dmesg lines for your CPU and its cpufreq drivers as well as the output of 'sysctl dev.cpu'? -- John Baldwin State Changed From-To: open->feedback Note that submitter has been asked for feedback. I have the same problem, so I'm hoping that my answering the question will help prevent this from being closed due to lack of feedback. CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2402.42-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0xe3bd<SSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM> AMD Features=0x20100800<SYSCALL,NX,LM> AMD Features2=0x1<LAHF> Cores per package: 4 cpu0: <ACPI CPU> on acpi0 acpi_perf0: <ACPI CPU Frequency Control> on cpu0 p4tcc0: <CPU Frequency Thermal Control> on cpu0 cpu1: <ACPI CPU> on acpi0 est1: <Enhanced SpeedStep Frequency Control> on cpu1 est: cpu_vendor GenuineIntel, msr 927092706000927 p4tcc1: <CPU Frequency Thermal Control> on cpu1 cpu2: <ACPI CPU> on acpi0 est2: <Enhanced SpeedStep Frequency Control> on cpu2 est: cpu_vendor GenuineIntel, msr 927092706000927 p4tcc2: <CPU Frequency Thermal Control> on cpu2 cpu3: <ACPI CPU> on acpi0 est3: <Enhanced SpeedStep Frequency Control> on cpu3 est: cpu_vendor GenuineIntel, msr 927092706000927 p4tcc3: <CPU Frequency Thermal Control> on cpu3 What's interesting is that it actually seems to work. The value from dev.cpu.0.freq changes as powerd runs. Finally, it's easy to show that it's not powerd. I can take it out of the equation: bhuda# sysctl dev.cpu.0.freq dev.cpu.0.freq: 2400 bhuda# sysctl dev.cpu.0.freq=200 dev.cpu.0.freq: 2400 sysctl: dev.cpu.0.freq: Invalid argument bhuda# sysctl dev.cpu.0.freq dev.cpu.0.freq: 200 bhuda# sysctl dev.cpu.0.freq=2400 dev.cpu.0.freq: 200 sysctl: dev.cpu.0.freq: Invalid argument bhuda# sysctl dev.cpu.0.freq dev.cpu.0.freq: 2400 And, as you can see, it sure looks like it actually works. State Changed From-To: feedback->open Feedback was received State Changed From-To: open->feedback My mistake, some feedback was received, but we still need the output of "sysctl dev.cpu" along with the rest of the information before we can figure out where the problem lies State Changed From-To: feedback->open Feedback was received from Mike Meyer: dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 800 dev.cpu.0.freq_levels: 2400/88000 2100/77000 1800/66000 1600/57000 1400/49875 1200/42750 1000/35625 800/28500 600/21375 400/14250 200/7125 dev.cpu.0.temperature: 59 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.temperature: 58 dev.cpu.1.cx_supported: C1/0 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% dev.cpu.2.%desc: ACPI CPU dev.cpu.2.%driver: cpu dev.cpu.2.%location: handle=_PR_.CPU2 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%parent: acpi0 dev.cpu.2.temperature: 50 dev.cpu.2.cx_supported: C1/0 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% dev.cpu.3.%desc: ACPI CPU dev.cpu.3.%driver: cpu dev.cpu.3.%location: handle=_PR_.CPU3 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%parent: acpi0 dev.cpu.3.temperature: 52 dev.cpu.3.cx_supported: C1/0 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% On Fri, 08 Aug 2008 12:21:26 +0100 Gavin Atkinson <gavin@FreeBSD.org> wrote: > On Wed, 2008-08-06 at 18:50 -0400, Mike Meyer wrote: > > Here's the sysctl dev.cpu output you requested. > > Thanks for that. The symptoms you were seeing was that > "sysctl dev.cpu.0.freq=200" would return "Invalid argument" but yet > appear to actually set the frequency. Are you able to confirm that the > CPU speed has actually dropped (e.g. by timing a compile, or similar)? > It's not clear from your info whether the CPU frequency is actually > changing, or if it's just the sysctl value that is changing. > > Please CC your response to bug-followup@FreeBSD.org so that it ends up > in the PR audit trail. I don't believe the cpu speed is actually changing: bhuda# sysctl dev.cpu.0.freq dev.cpu.0.freq: 200 bhuda# dhry Dhrystone(1.1) time for 500000000 passes = 171.9 This machine benchmarks at 2908712 dhrystones/second bhuda# sysctl dev.cpu.0.freq=2400 dev.cpu.0.freq: 200 sysctl: dev.cpu.0.freq: Invalid argument bhuda# sysctl dev.cpu.0.freq dev.cpu.0.freq: 2400 bhuda# dhry Dhrystone(1.1) time for 500000000 passes = 165.4 This machine benchmarks at 3022085 dhrystones/second <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org State Changed From-To: open->feedback Try to check it on newer OS. I think it could be fixed by r186154, merged to 7.2-STABLE. State Changed From-To: feedback->closed Feedback timeout. |
