Re: est not happy about E7300?

On Wednesday 26 November 2008 04:44 pm, Garrett Cooper wrote:
> On Wed, Nov 26, 2008 at 1:42 PM, Garrett Cooper <yanefbsd_at_gmail.com> 
wrote:
> > On Wed, Nov 26, 2008 at 8:52 AM, Stefan Bethke <stb_at_lassitu.de> 
wrote:
> >> Am 26.11.2008 um 10:45 schrieb swell.k_at_gmail.com:
> >>> Stefan Bethke <stb_at_lassitu.de> writes:
> >>>> Got myself a new Shuttle K45 (965 chipset) with an E7300 cpu
> >>>> and seeing this with a kernel from yesterday:
> >>>>
> >>>> FreeBSD 8.0-CURRENT #0: Wed Nov 26 06:58:02 UTC 2008
> >>>>   root_at_lokschuppen.lassitu.de:/usr/obj/usr/src/sys/EISENBOOT
> >>>> Timecounter "i8254" frequency 1193182 Hz quality 0
> >>>> CPU: Intel(R) Core(TM)2 Duo CPU     E7300  _at_ 2.66GHz
> >>>> (2669.76-MHz K8- class CPU)
> >>>>  Origin = "GenuineIntel"  Id = 0x10676  Stepping = 6
> >>>>  Features
> >>>> =
> >>>> 0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PG
> >>>>E,MCA,C
> >>>> MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
> >>>>> Features2
> >>>> =0x8e39d<SSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,S
> >>>>SE4.1> AMD Features=0x20100800<SYSCALL,NX,LM>
> >>>>  AMD Features2=0x1<LAHF>
> >>>>  Cores per package: 2
> >>>> usable memory = 3478437888 (3317 MB)
> >>>> avail memory  = 3363401728 (3207 MB)
> >>>> ...
> >>>> cpu0: <ACPI CPU> on acpi0
> >>>> est0: <Enhanced SpeedStep Frequency Control> on cpu0
> >>>> est: CPU supports Enhanced Speedstep, but is not recognized.
> >>>> est: cpu_vendor GenuineIntel, msr 61a0a2006000a20
> >>>> device_attach: est0 attach returned 6
> >>>> p4tcc0: <CPU Frequency Thermal Control> on cpu0
> >>>> cpu1: <ACPI CPU> on acpi0
> >>>> est1: <Enhanced SpeedStep Frequency Control> on cpu1
> >>>> est: CPU supports Enhanced Speedstep, but is not recognized.
> >>>> est: cpu_vendor GenuineIntel, msr 61a0a2006000a20
> >>>> device_attach: est1 attach returned 6
> >>>> p4tcc1: <CPU Frequency Thermal Control> on cpu1
> >>>>
> >>>> What can I provide to make est happy?
> >>>
> >>> Perhaps,
> >>> hw.est.msr_info=1 # build list of cpu frequencies
> >>> in /boot/loader.conf?
> >>
> >> Does not appear to help, this is with boot -v:
> >> cpu0: <ACPI CPU> on acpi0
> >> cpu0: switching to generic Cx mode
> >> est0: <Enhanced SpeedStep Frequency Control> on cpu0
> >> est0: Guessed bus clock (high) of 266 MHz
> >> est0: Guessed bus clock (low) of 444 MHz
> >> est: CPU supports Enhanced Speedstep, but is not recognized.
> >> est: cpu_vendor GenuineIntel, msr 61a0a2006000a20
> >> device_attach: est0 attach returned 6
> >> p4tcc0: <CPU Frequency Thermal Control> on cpu0
> >> cpu1: <ACPI CPU> on acpi0
> >> est1: <Enhanced SpeedStep Frequency Control> on cpu1
> >> est1: Guessed bus clock (high) of 266 MHz
> >> est1: Guessed bus clock (low) of 444 MHz
> >> est: CPU supports Enhanced Speedstep, but is not recognized.
> >> est: cpu_vendor GenuineIntel, msr 61a0a2006000a20
> >> device_attach: est1 attach returned 6
> >> p4tcc1: <CPU Frequency Thermal Control> on cpu1
> >>
> >>
> >> Stefan
> >
> > Works fine for me, but I'm running a Core 2 Duo E6700 and my
> > sources are 5 days old.
> >
> > [gcooper_at_optimus ~]$ dmesg | grep Core
> > CPU: Intel(R) Core(TM)2 CPU          6700  _at_ 2.66GHz (2672.75-MHz
> > K8-class CPU) Cores per package: 2
> > CPU: Intel(R) Core(TM)2 CPU          6700  _at_ 2.66GHz (2672.74-MHz
> > K8-class CPU) Cores per package: 2
> > [gcooper_at_optimus ~]$ uname -a
> > FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT
> > #7: Mon Nov 24 21:59:24 PST 2008
> > gcooper_at_optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS 
> > amd64
> >
> > est0: <Enhanced SpeedStep Frequency Control> on cpu0
> > p4tcc0: <CPU Frequency Thermal Control> on cpu0
> > cpu1: <ACPI CPU> on acpi0
> > est1: <Enhanced SpeedStep Frequency Control> on cpu1
> > p4tcc1: <CPU Frequency Thermal Control> on cpu1
> >
> > -Garrett
>
> I'd resync, rebuild and see if the issue still exists. Someone just
> modified the est / ACPI portions on CURRENT as of 2 hours ago:
>
> http://svn.freebsd.org/changeset/base/185341

That was me.  This commit should never change functionality of the 
driver at all.  Probably the CPU is not in the table of supported 
CPUs.

Jung-uk Kim