enhanced speed step on AMD64

1 view
Skip to first unread message

b...@methodlogic.net

unread,
May 23, 2010, 3:40:28 AM5/23/10
to

Hi.

I'm running -current (NetBSD kamloops 5.99.29 NetBSD
5.99.29 (kamloops) #55: Sat May 22 13:54:04 PDT 2010
root@kamloops:/usr/obj/sys/arch/amd64/compile/kamloops amd64) on a
Thinkpad t410 (core i7). I've got no indication that the Intel Speedstep
CPU frequency scaling is supported, but the Intel datasheets say the
CPU supports it (http://ark.intel.com/Product.aspx?id=43560).

Is anybody else running this chip w/ Speedstep working correctly? I've
got "options ENHANCED_SPEEDSTEP" enabled in my kernel -- is
there something else I need?

dmesg:

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.

NetBSD 5.99.29 (kamloops) #55: Sat May 22 13:54:04 PDT 2010
root@kamloops:/usr/obj/sys/arch/amd64/compile/kamloops
total memory = 3891 MB
avail memory = 3758 MB
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
LENOVO 2516CTO (ThinkPad T410)
mainbus0 (root)
cpu0 at mainbus0 apid 0: Intel 686-class, 2660MHz, id 0x20652
cpu0: Intel(R) On Demand Clock Modulation (state disabled)
cpu1 at mainbus0 apid 4: Intel 686-class, 2660MHz, id 0x20652
ioapic0 at mainbus0 apid 1: pa 0xfec00000, version 20, 24 pins
acpi0 at mainbus0: Intel ACPICA 20100121
acpi0: X/RSDT: OemId <LENOVO,TP-6I ,00001120>, AslId < LTP,00000000>
acpiecdt0 at acpi0: ACPI Embedded Controller via ECDT
acpi0: SCI interrupting at int 9
timecounter: Timecounter "ACPI-Safe" frequency 3579545 Hz quality 900
ACPI-Safe 24-bit timer
acpilid0 at acpi0 (LID, PNP0C0D): ACPI Lid Switch
acpibut0 at acpi0 (SLPB, PNP0C0E): ACPI Sleep Button
attimer0 at acpi0 (TIMR, PNP0100): io 0x40-0x43 irq 0
hpet0 at acpi0 (HPET, PNP0103): mem 0xfed00000-0xfed003ff
timecounter: Timecounter "hpet0" frequency 14318179 Hz quality 2000
pcppi0 at acpi0 (SPKR, PNP0800): io 0x61
midi0 at pcppi0: PC speaker
sysbeep0 at pcppi0
pckbc0 at acpi0 (KBD, PNP0303) (kbd port): io 0x60,0x64 irq 1
pckbc1 at acpi0 (MOU, LEN0015) (aux port): irq 12
TPM (SMO1200) at acpi0 not configured
acpiec0 at acpi0 (EC, PNP0C09-0): using acpiecdt0
acpibat0 at acpi0 (BAT0, PNP0C0A-0): ACPI Battery
acpibat0: SANYO LION rechargeable battery
acpibat0: serial number 5780, model number 42T4799
acpibat0: low->warn granularity: 0.001Ah, warn->full granularity: 0.001Ah
acpiacad0 at acpi0 (AC, ACPI0003-0): ACPI AC Adapter
thinkpad0 at acpi0 (HKEY, IBM0068)
WMI1 (pnp0c14) at acpi0 not configured
acpiwmi0 at acpi0 (WMI1, PNP0C14-1): ACPI WMI Interface
acpiwmibus at acpiwmi0 not configured
acpitz0 at acpi0 (THM0): ACPI Thermal Zone
acpitz0: critical 100.0 C, passive 95.5 C, passive cooling
attimer0: attached to pcppi0
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
pms0 at pckbc0 (aux slot)
pms0: Synaptics touchpad version 7.2
pms0: Passthrough, Palm detect
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0: vendor 0x8086 product 0x0044 (rev. 0x02)
vga0 at pci0 dev 2 function 0: vendor 0x8086 product 0x0046 (rev. 0x02)
wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using wskbd0
wsmux1: connecting to wsdisplay0
drm at vga0 not configured
vendor 0x8086 product 0x3b64 (miscellaneous communications, revision 0x06) at pci0 dev 22 function 0 not configured
wm0 at pci0 dev 25 function 0: PCH LAN (82578LM) Controller, rev. 6
wm0: interrupting at ioapic0 pin 20
wm0: PCI-Express bus
wm0: FLASH
wm0: Ethernet address [snip]
ukphy0 at wm0 phy 2: OUI 0x00aa00, model 0x0005, rev. 3
ukphy0: no media present
ifmedia_set: no match for 0x20/0xfffffff
ehci0 at pci0 dev 26 function 0: vendor 0x8086 product 0x3b3c (rev. 0x06)
ehci0: interrupting at ioapic0 pin 23
ehci0: EHCI version 1.0
usb0 at ehci0: USB revision 2.0
hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
hdaudio0: interrupting at ioapic0 pin 17
hdafg0 at hdaudio0 vendor 0x14F1 product 0x5069 nid 0x01 (firmware configuration)
hdafg0: DAC0:10, Analog HP Out: Jack (Black, 19)
hdafg0: ADC1:14, Analog Mic In: Jack (Black, 1B)
hdafg0: ADC2:15, Analog Mic In: Fixed Function (Unknown, 23)
hdafg0: 2ch/2ch 44100Hz-96000Hz 16/16 20/32 24/32
audio0 at hdafg0: full duplex, playback, capture, independent
hdvsmfg at hdaudio0 vendor 0x14F1 product 0x5069 nid 0x02 not configured
hdafg1 at hdaudio0 vendor 0x8086 product 0x2804 nid 0x01 (firmware configuration)
hdafg1: DAC0:02, Digital Digital Other Out: Jack (Unknown, 04)
hdafg1: DAC1:03, Digital Digital Other Out: Jack (Unknown, 05)
hdafg1: 2ch/0ch 48000Hz 16/16*
audio1 at hdafg1: full duplex, playback, capture, independent
ppb0 at pci0 dev 28 function 0: vendor 0x8086 product 0x3b42 (rev. 0x06)
ppb0: unsupported PCI Express version
pci1 at ppb0 bus 2
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
ppb1 at pci0 dev 28 function 1: vendor 0x8086 product 0x3b44 (rev. 0x06)
ppb1: unsupported PCI Express version
pci2 at ppb1 bus 3
pci2: i/o space, memory space enabled, rd/line, wr/inv ok
iwn0 at pci2 dev 0 function 0: vendor 0x8086 product 0x4238 (rev. 0x35)
iwn0: interrupting at ioapic0 pin 17
iwn0: MIMO 3T3R, MoW, address [snip]
iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
ppb2 at pci0 dev 28 function 3: vendor 0x8086 product 0x3b48 (rev. 0x06)
ppb2: unsupported PCI Express version
pci3 at ppb2 bus 5
pci3: i/o space, memory space enabled, rd/line, wr/inv ok
ppb3 at pci0 dev 28 function 4: vendor 0x8086 product 0x3b4a (rev. 0x06)
ppb3: unsupported PCI Express version
pci4 at ppb3 bus 13
pci4: i/o space, memory space enabled, rd/line, wr/inv ok
sdhc0 at pci4 dev 0 function 0: vendor 0x1180 product 0xe822 (rev. 0x01)
sdhc0: interrupting at ioapic0 pin 16
sdmmc0 at sdhc0
vendor 0x1180 product 0xe230 (miscellaneous system, revision 0x01) at pci4 dev 0 function 1 not configured
fwohci0 at pci4 dev 0 function 3: vendor 0x1180 product 0xe832 (rev. 0x01)
fwohci0: interrupting at ioapic0 pin 19
fwohci0: OHCI version 1.10 (ROM=0)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 [snip]
fwohci0: Phy 1394a available S400, 1 ports.
fwohci0: Link S400, max_rec 2048 bytes.
ieee1394if0 at fwohci0: IEEE1394 bus
fwip0 at ieee1394if0: IP over IEEE1394
fwohci0: Initiate bus reset
ehci1 at pci0 dev 29 function 0: vendor 0x8086 product 0x3b34 (rev. 0x06)
ehci1: interrupting at ioapic0 pin 19
ehci1: EHCI version 1.0
usb1 at ehci1: USB revision 2.0
ppb4 at pci0 dev 30 function 0: vendor 0x8086 product 0x2448 (rev. 0xa6)
pci5 at ppb4 bus 14
pci5: i/o space, memory space enabled
pcib0 at pci0 dev 31 function 0: vendor 0x8086 product 0x3b07 (rev. 0x06)
ahcisata0 at pci0 dev 31 function 2: vendor 0x8086 product 0x3b2f
ahcisata0: interrupting at ioapic0 pin 16
ahcisata0: AHCI revision 0x10300, 6 ports, 32 command slots, features 0xff22e060
atabus0 at ahcisata0 channel 0
atabus1 at ahcisata0 channel 1
atabus2 at ahcisata0 channel 4
atabus3 at ahcisata0 channel 5
ichsmb0 at pci0 dev 31 function 3: vendor 0x8086 product 0x3b30 (rev. 0x06)
ichsmb0: interrupting at ioapic0 pin 23
iic0 at ichsmb0: I2C bus
vendor 0x8086 product 0x3b32 (miscellaneous DASP, revision 0x06) at pci0 dev 31 function 6 not configured
isa0 at pcib0
fwohci0: BUS reset
fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode
ieee1394if0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me)
ieee1394if0: bus manager 0
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
acpiacad0: AC adapter offline.
uhub0 at usb0: vendor 0x8086 EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
uhub1 at usb1: vendor 0x8086 EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub1: 3 ports with 3 removable, self powered
ahcisata0 port 0: device present, speed: 3.0Gb/s
ahcisata0 port 1: device present, speed: 1.5Gb/s
wd0 at atabus0 drive 0: <FUJITSU MJA2320BH G2>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 298 GB, 620181 cyl, 16 head, 63 sec, 512 bytes/sect x 625142448 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) (using DMA)
atapibus0 at atabus1: 1 targets
cd0 at atapibus0 drive 0: <HL-DT-ST DVDRAM GU10N, M12A3EN5447, MX05> cdrom removable
cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
cd0(ahcisata0:1:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA)
uhub2 at uhub0 port 1: vendor 0x8087 product 0x0020, class 9/0, rev 2.00/0.00, addr 2
uhub2: single transaction translator
uhub3 at uhub1 port 1: vendor 0x8087 product 0x0020, class 9/0, rev 2.00/0.00, addr 2
uhub3: single transaction translator
uhub2: 6 ports with 6 removable, self powered
uhub3: 8 ports with 8 removable, self powered
uvideo0 at uhub2 port 6 configuration 1 interface 0: Chicony Electronics Co., Ltd. Integrated Camera, rev 2.00/23.45, addr 3
video0 at uvideo0: Chicony Electronics Co., Ltd. Integrated Camera, rev 2.00/23.45, addr 3
pad0: outputs: 44100Hz, 16-bit, stereo
audio2 at pad0: half duplex, playback, capture
boot device: wd0
root on wd0a dumps on wd0b
root file system type: ffs
wsdisplay0: screen 1 added (80x25, vt100 emulation)
wsdisplay0: screen 2 added (80x25, vt100 emulation)
wsdisplay0: screen 3 added (80x25, vt100 emulation)
wsdisplay0: screen 4 added (80x25, vt100 emulation)
acpiacad0: AC adapter online.

--
Brad Harder
Method Logic Digital Consulting
http://methodlogic.net
http://twitter.com/bcharder


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de

Iain Hibbert

unread,
May 23, 2010, 4:58:55 AM5/23/10
to
On Sun, 23 May 2010, b...@methodlogic.net wrote:

> Is anybody else running this chip w/ Speedstep working correctly? I've
> got "options ENHANCED_SPEEDSTEP" enabled in my kernel -- is
> there something else I need?

I don't know about that chip, but I have it enabled and running here on
i386 and there is nothing in the dmesg about it as there are only
aprint_debug() in est.c (try boot -x to enable those)

also, you can see "sysctl machdep.est" output, eg

machdep.est.frequency.target = 1000
machdep.est.frequency.current = 1000
machdep.est.frequency.available = 2000 1833 1667 1500 1333 1167 1000

and finally you can use sysutils/estd from pkgsrc to manage the active
frequency adaptations depending on system load..

iain

(an est(4) manpage would be nice)

Cem Kayali / E Ticaret ve Bilisim Teknolojileri

unread,
May 23, 2010, 8:06:58 AM5/23/10
to

This little script may help you:
http://mail-index.netbsd.org/current-users/2009/05/07/msg009329.html

I still use it actively.

Regards,
Cem


b...@methodlogic.net wrote:
> Hi.
>
> I'm running -current (NetBSD kamloops 5.99.29 NetBSD
> 5.99.29 (kamloops) #55: Sat May 22 13:54:04 PDT 2010
> root@kamloops:/usr/obj/sys/arch/amd64/compile/kamloops amd64) on a
> Thinkpad t410 (core i7). I've got no indication that the Intel Speedstep
> CPU frequency scaling is supported, but the Intel datasheets say the
> CPU supports it (http://ark.intel.com/Product.aspx?id=43560).
>
> Is anybody else running this chip w/ Speedstep working correctly? I've
> got "options ENHANCED_SPEEDSTEP" enabled in my kernel -- is
> there something else I need?

--

b...@methodlogic.net

unread,
May 23, 2010, 2:15:45 PM5/23/10
to
On Sun, May 23, 2010 at 09:58:55AM +0100, Iain Hibbert wrote:
> On Sun, 23 May 2010, b...@methodlogic.net wrote:
>
> > Is anybody else running this chip w/ Speedstep working correctly? I've
> > got "options ENHANCED_SPEEDSTEP" enabled in my kernel -- is
> > there something else I need?
>
> I don't know about that chip, but I have it enabled and running here on
> i386 and there is nothing in the dmesg about it as there are only
> aprint_debug() in est.c (try boot -x to enable those)
>
> also, you can see "sysctl machdep.est" output, eg
>
> machdep.est.frequency.target = 1000
> machdep.est.frequency.current = 1000
> machdep.est.frequency.available = 2000 1833 1667 1500 1333 1167 1000
>
> and finally you can use sysutils/estd from pkgsrc to manage the active
> frequency adaptations depending on system load..

Yup, and none of that works -- I've got a Pentium M with speedstep
successfully running, so I'm aware of the interface, etc. Was wondering
if something changed in the meantime that I missed... I'll leave this
thread out there in the hope that someone can shed some light, or set
me on the right path...

at sh prompt:
===========================================================
kamloops# sysctl machdep.est
sysctl: second level name 'est' in 'machdep.est' is invalid
kamloops#


> iain
>
> (an est(4) manpage would be nice)
>
>
>

--

b...@methodlogic.net

unread,
May 23, 2010, 2:19:06 PM5/23/10
to
On Sun, May 23, 2010 at 03:06:58PM +0300, Cem Kayali / E Ticaret ve Bilisim Teknolojileri wrote:
>
> This little script may help you:
> http://mail-index.netbsd.org/current-users/2009/05/07/msg009329.html

Thanks, but I really do have no interface to est...


kamloops# sysctl machdep.est
sysctl: second level name 'est' in 'machdep.est' is invalid

kamloops# sysctl -a | grep freq
machdep.tsc_freq = 2660218080
kamloops#


> I still use it actively.
>
> Regards,
> Cem
>
>
> b...@methodlogic.net wrote:

>> Hi.
>>
>> I'm running -current (NetBSD kamloops 5.99.29 NetBSD
>> 5.99.29 (kamloops) #55: Sat May 22 13:54:04 PDT 2010
>> root@kamloops:/usr/obj/sys/arch/amd64/compile/kamloops amd64) on a
>> Thinkpad t410 (core i7). I've got no indication that the Intel Speedstep
>> CPU frequency scaling is supported, but the Intel datasheets say the
>> CPU supports it (http://ark.intel.com/Product.aspx?id=43560).
>>
>> Is anybody else running this chip w/ Speedstep working correctly? I've
>> got "options ENHANCED_SPEEDSTEP" enabled in my kernel -- is
>> there something else I need?

--

Iain Hibbert

unread,
May 23, 2010, 12:48:07 PM5/23/10
to
On Sun, 23 May 2010, b...@methodlogic.net wrote:

> Yup, and none of that works -- I've got a Pentium M with speedstep
> successfully running, so I'm aware of the interface, etc. Was wondering
> if something changed in the meantime that I missed... I'll leave this
> thread out there in the hope that someone can shed some light, or set
> me on the right path...

reading the code (at arch/x86/x86/est.c) seems to indicate that "boot -x"
should cause _some_ kind of message to be emitted if the est_init()
function is called. You could also build a kernel with "options EST_DEBUG"
which will print more..

Then, the code that calls est_init() (in arch/x86/x86/identcpu.c) shows

#ifdef ENHANCED_SPEEDSTEP
if (cpu_feature[1] & CPUID2_EST) {
if (rdmsr(MSR_MISC_ENABLE) & (1 << 16))
est_init(cpu_vendor);
}
#endif /* ENHANCED_SPEEDSTEP */

and on my machine, "cpuctl identify 0" shows

cpu0: features2 0xc1a9<SSE3,MONITOR,VMX,EST,TM2,xTPR,PDCM>

I don't know what MSR_MISC_ENABLE means, perhaps just that the CPU is
enabled..?

iain

b...@methodlogic.net

unread,
May 23, 2010, 2:55:19 PM5/23/10
to
On Sun, May 23, 2010 at 05:48:07PM +0100, Iain Hibbert wrote:
> On Sun, 23 May 2010, b...@methodlogic.net wrote:
>
> > Yup, and none of that works -- I've got a Pentium M with speedstep
> > successfully running, so I'm aware of the interface, etc. Was wondering
> > if something changed in the meantime that I missed... I'll leave this
> > thread out there in the hope that someone can shed some light, or set
> > me on the right path...
>
> reading the code (at arch/x86/x86/est.c) seems to indicate that "boot -x"
> should cause _some_ kind of message to be emitted if the est_init()
> function is called. You could also build a kernel with "options EST_DEBUG"
> which will print more..
>
> Then, the code that calls est_init() (in arch/x86/x86/identcpu.c) shows
>
> #ifdef ENHANCED_SPEEDSTEP
> if (cpu_feature[1] & CPUID2_EST) {
> if (rdmsr(MSR_MISC_ENABLE) & (1 << 16))
> est_init(cpu_vendor);
> }
> #endif /* ENHANCED_SPEEDSTEP */
>
> and on my machine, "cpuctl identify 0" shows
>
> cpu0: features2 0xc1a9<SSE3,MONITOR,VMX,EST,TM2,xTPR,PDCM>
>
> I don't know what MSR_MISC_ENABLE means, perhaps just that the CPU is
> enabled..?

Thanks Iain -- rebuilding a kernel w/ EST_DEBUG right now... my cpuctl
is as follows (I'm pasting whole thing, since this appears to be a
"problem" CPU:

kamloops# cpuctl identify 0
cpu0: Intel Mobile Pentium II (Dixon) (686-class), 2660.22 MHz, id 0x20652
cpu0: features 0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
cpu0: features 0xbfebfbff<PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR>
cpu0: features 0xbfebfbff<SSE,SSE2,SS,HTT,TM,SBF>
cpu0: features2 0x298e3ff<SSE3,B01,DTES64,MONITOR,DS-CPL,VMX,SMX,EST,TM2>
cpu0: features2 0x298e3ff<SSSE3,CX16,xTPR,PDCM,SSE41,SSE42,POPCNT,B25>
cpu0: features3 0x28100800<SYSCALL/SYSRET,XD,EM64T>
cpu0: features4 0x1<LAHF>
cpu0: "Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz"
cpu0: I-cache 32KB 64B/line 4-way, D-cache 32KB 64B/line 8-way
cpu0: L2 cache 256KB 64B/line 8-way
cpu0: ITLB 128 4KB entries 4-way
cpu0: DTLB 64 4KB entries 4-way
cpu0: L3 cache 4MB 64B/line 16-way
cpu0: Initial APIC ID 0
cpu0: Cluster/Package ID 0
cpu0: Core ID 0
cpu0: SMT ID 0
cpu0: family 06 model 05 extfamily 00 extmodel 02

> iain

b...@methodlogic.net

unread,
May 23, 2010, 3:15:09 PM5/23/10
to


Hrmm.... from dmesg:

est_init_main: crlo == 0 || crhi == crlo

Christos Zoulas

unread,
May 23, 2010, 5:59:09 PM5/23/10
to
In article <1274633287.811153...@galant.ukfsn.org>,

Iain Hibbert <plu...@rya-online.net> wrote:
>On Sun, 23 May 2010, b...@methodlogic.net wrote:
>
>> Yup, and none of that works -- I've got a Pentium M with speedstep
>> successfully running, so I'm aware of the interface, etc. Was wondering
>> if something changed in the meantime that I missed... I'll leave this
>> thread out there in the hope that someone can shed some light, or set
>> me on the right path...
>
>reading the code (at arch/x86/x86/est.c) seems to indicate that "boot -x"
>should cause _some_ kind of message to be emitted if the est_init()
>function is called. You could also build a kernel with "options EST_DEBUG"
>which will print more..
>
>Then, the code that calls est_init() (in arch/x86/x86/identcpu.c) shows
>
>#ifdef ENHANCED_SPEEDSTEP
> if (cpu_feature[1] & CPUID2_EST) {
> if (rdmsr(MSR_MISC_ENABLE) & (1 << 16))
> est_init(cpu_vendor);
> }
>#endif /* ENHANCED_SPEEDSTEP */
>
>and on my machine, "cpuctl identify 0" shows
>
> cpu0: features2 0xc1a9<SSE3,MONITOR,VMX,EST,TM2,xTPR,PDCM>
>
>I don't know what MSR_MISC_ENABLE means, perhaps just that the CPU is
>enabled..?

That's not the problem. The EST code really needs to go because
it is ~impossible to figure out the proper thing to do from the MSR's.
It is easier do do with ACPI. I am adding some more printfs and if
you boot with -x you'll see what's going on (we don't support new CPU's).

christos

Joerg Sonnenberger

unread,
May 23, 2010, 6:06:23 PM5/23/10
to
On Sun, May 23, 2010 at 09:59:09PM +0000, Christos Zoulas wrote:
> That's not the problem. The EST code really needs to go because
> it is ~impossible to figure out the proper thing to do from the MSR's.

It can't go. There are a lot of slightly older systems where the ACPI
implementation is basically useless. Just because Intel decided to f**k
up and move it back to hidden magic (didn't they learn from Speedstep?)
doesn't mean the old interface doesn't work for those CPUs it applies
to.

Joerg

b...@methodlogic.net

unread,
May 23, 2010, 8:12:45 PM5/23/10
to
On Mon, May 24, 2010 at 12:06:23AM +0200, Joerg Sonnenberger wrote:
> On Sun, May 23, 2010 at 09:59:09PM +0000, Christos Zoulas wrote:
> > That's not the problem. The EST code really needs to go because
> > it is ~impossible to figure out the proper thing to do from the MSR's.
>
> It can't go. There are a lot of slightly older systems where the ACPI
> implementation is basically useless. Just because Intel decided to f**k
> up and move it back to hidden magic (didn't they learn from Speedstep?)
> doesn't mean the old interface doesn't work for those CPUs it applies
> to.

Can anybody describe where "we" are at for supporting speedstep on CPUs
like the i7, then? Will it require an entire new framework to support? Can
somebody describe where the "problem" exists between this hardware and
the current NetBSD support for Speedstep on it? I'm interested both for
the practical matter of getting this CPU supported, and it's something
I just don't know anything about, so a "teachable moment" :)

-bch

--
Brad Harder
Method Logic Digital Consulting
http://methodlogic.net
http://twitter.com/bcharder

b...@methodlogic.net

unread,
May 23, 2010, 10:39:24 PM5/23/10
to
On Mon, May 24, 2010 at 12:12:45AM +0000, b...@methodlogic.net wrote:
> On Mon, May 24, 2010 at 12:06:23AM +0200, Joerg Sonnenberger wrote:
> > On Sun, May 23, 2010 at 09:59:09PM +0000, Christos Zoulas wrote:
> > > That's not the problem. The EST code really needs to go because
> > > it is ~impossible to figure out the proper thing to do from the MSR's.
> >
> > It can't go. There are a lot of slightly older systems where the ACPI
> > implementation is basically useless. Just because Intel decided to f**k
> > up and move it back to hidden magic (didn't they learn from Speedstep?)
> > doesn't mean the old interface doesn't work for those CPUs it applies
> > to.
>
> Can anybody describe where "we" are at for supporting speedstep on CPUs
> like the i7, then? Will it require an entire new framework to support? Can
> somebody describe where the "problem" exists between this hardware and
> the current NetBSD support for Speedstep on it? I'm interested both for
> the practical matter of getting this CPU supported, and it's something
> I just don't know anything about, so a "teachable moment" :)

Gah... sorry for all the "quotes". :P

-bch

--
Brad Harder
Method Logic Digital Consulting
http://methodlogic.net
http://twitter.com/bcharder

b...@methodlogic.net

unread,
May 23, 2010, 11:35:36 PM5/23/10
to
On Sun, May 23, 2010 at 09:59:09PM +0000, Christos Zoulas wrote:
> In article <1274633287.811153...@galant.ukfsn.org>,
> Iain Hibbert <plu...@rya-online.net> wrote:
> >On Sun, 23 May 2010, b...@methodlogic.net wrote:
> >
> >> Yup, and none of that works -- I've got a Pentium M with speedstep
> >> successfully running, so I'm aware of the interface, etc. Was wondering
> >> if something changed in the meantime that I missed... I'll leave this
> >> thread out there in the hope that someone can shed some light, or set
> >> me on the right path...
> >
> >reading the code (at arch/x86/x86/est.c) seems to indicate that "boot -x"
> >should cause _some_ kind of message to be emitted if the est_init()
> >function is called. You could also build a kernel with "options EST_DEBUG"
> >which will print more..
> >
> >Then, the code that calls est_init() (in arch/x86/x86/identcpu.c) shows
> >
> >#ifdef ENHANCED_SPEEDSTEP
> > if (cpu_feature[1] & CPUID2_EST) {
> > if (rdmsr(MSR_MISC_ENABLE) & (1 << 16))
> > est_init(cpu_vendor);
> > }
> >#endif /* ENHANCED_SPEEDSTEP */
> >
> >and on my machine, "cpuctl identify 0" shows
> >
> > cpu0: features2 0xc1a9<SSE3,MONITOR,VMX,EST,TM2,xTPR,PDCM>
> >
> >I don't know what MSR_MISC_ENABLE means, perhaps just that the CPU is
> >enabled..?
>
> That's not the problem. The EST code really needs to go because
> it is ~impossible to figure out the proper thing to do from the MSR's.
> It is easier do do with ACPI. I am adding some more printfs and if
> you boot with -x you'll see what's going on (we don't support new CPU's).

from dmesg with latest kernel code:

est_init_main: strange msr value 0x9
est_init_main: crhi=0, crlo=0, crcur=0

-bch

Michael van Elst

unread,
May 24, 2010, 6:03:38 AM5/24/10
to
b...@methodlogic.net writes:

>Can anybody describe where "we" are at for supporting speedstep on CPUs
>like the i7, then?

Simple answer: nowhere. Support requires talking to ACPI, and so far
we don't do that.

--
--
Michael van Elst
Internet: mle...@serpens.de
"A potential Snark may lurk in every tree."

Joerg Sonnenberger

unread,
May 24, 2010, 8:03:52 AM5/24/10
to
On Mon, May 24, 2010 at 12:12:45AM +0000, b...@methodlogic.net wrote:
> Can anybody describe where "we" are at for supporting speedstep on CPUs
> like the i7, then? Will it require an entire new framework to support? Can
> somebody describe where the "problem" exists between this hardware and
> the current NetBSD support for Speedstep on it? I'm interested both for
> the practical matter of getting this CPU supported, and it's something
> I just don't know anything about, so a "teachable moment" :)

Basically, frequency changes in Intel-land done in one of three ways:

(1) The original Speed Step. The frequency changes are done by magic
calls into the BIOS and (AFAIK) a function of the chipset.

(2) EST until ~Core 2. Frequency and voltage are tabularised (older
CPUs) or derived algorithmically from certain MSR (machine status
registers). Change of the performance settings is done via MSR under
application control.

(3) EST since late Core2. The MSRs are mostly discontinued and/or
provide junk data. The kernel is supposed to use the ACPI Processor
object and its method for this purpose. Doesn't work for all older model
as it was often left out.

At the moment, (2) works best for the CPUs it can work on. (1) might or
might not work. (3) is not supported.

Christos Zoulas

unread,
May 24, 2010, 8:55:41 AM5/24/10
to
On May 24, 3:35am, b...@methodlogic.net (b...@methodlogic.net) wrote:
-- Subject: Re: enhanced speed step on AMD64

| from dmesg with latest kernel code:
|
| est_init_main: strange msr value 0x9
| est_init_main: crhi=0, crlo=0, crcur=0

My guess is that we just need to look at the linux code and see what it
does.

christos

Dennis den Brok

unread,
May 24, 2010, 1:33:00 PM5/24/10
to
Joerg Sonnenberger <jo...@britannica.bec.de> schrieb:

> (2) EST until ~Core 2. Frequency and voltage are tabularised (older
> CPUs) or derived algorithmically from certain MSR (machine status
> registers). Change of the performance settings is done via MSR under
> application control.

While on topic, would anyone mind taking a look at PR 43342? The
included patch adds support for some further CPU models to MSR-based
detection of this kind of CPU data, in accordance with Intel's
datasheets, and prevents some CPU models from being classified
wrongly (for instance my E8400 as a Pentium II).
This is most probably cosmetic only, but the current state appears
confusing.

(Can the ACPI information be relied upon on new machines? An acpidump
on my fairly new motherboard does not even seem to contain the
necessary fields.)

Thanks,

Dennis den Brok

Jukka Ruohonen

unread,
May 24, 2010, 1:35:47 PM5/24/10
to
On Mon, May 24, 2010 at 05:33:00PM +0000, Dennis den Brok wrote:
> (Can the ACPI information be relied upon on new machines? An acpidump
> on my fairly new motherboard does not even seem to contain the
> necessary fields.)

Yes.

As was noted, ACPI is not here something that is optional.

- Jukka.

P.S. acpidump(8) is broken.

Reply all
Reply to author
Forward
0 new messages