Cpufreq 2.4.22-pre6 & Pentium M

Cpufreq 2.4.22-pre6 & Pentium M

[Eduardo Gonzalez-Solares]

Hi,

I downloaded the cpufreq patch from
http://www.codemonkey.org.uk/cpufreq/
against kernel 2.4.22-pre6. After compiling the kernel with Enhanced
Speedstep Support for the centrino I get next error when doing insmod:

Using
/lib/modules/2.4.22-pre6/kernel/arch/i386/kernel/speedstep-centrino.o/l
ib/modules/2.4.22-pre6/kernel/arch/i386/kernel/speedstep-centrino.o:
init_module: No such device 

Hint: insmod errors can be caused by
incorrect module parameters, including invalid IO or IRQ parameters.    
 You may find more information in syslog or the output from dmesg

Nothing in dmesg. It seems the problem is in:

       if (!cpu_has(cpu, X86_FEATURE_EST))
               return -ENODEV;

in the centrino_init function. If I remove those lines the
module loads, the processor is found:

speedstep-centrino: found "Intel(R) Pentium(R) M processor 1300MHz": max
frequency: 1300000kHz

and I can control the cpu speed.

Previous patches against kernel 2.4.21 worked ok.

Cheers,

	Eddie.

P.S. I am using a Dell D800 laptop with 1.3 MHz centrino in case that
matters.

Re: Cpufreq 2.4.22-pre6 & Pentium M

[Jeremy Fitzhardinge]

On Fri, 2003-07-18 at 14:09, Eduardo Gonzalez-Solares wrote:
> Nothing in dmesg. It seems the problem is in:
> 
>        if (!cpu_has(cpu, X86_FEATURE_EST))
>                return -ENODEV;

I'm not sure who maintains the 2.4 port, but the problem is that the
core code which sets up the CPU feature bits doesn't know about the
extended feature word, so it doesn't read the X86_FEATURE_EST bit from
the CPU.

The previous versions of this patch used this functional but ugly code:
        int dummy, ecx;
        
        cpuid(1,&dummy,&dummy,&ecx,&dummy);
        if (!(ecx & (1<<7)))
        	return -ENODEV;

Either the new ports of speedstep-centrino.c need to keep using this
code, or the X86_FEATURE_EST bit needs to be put into cpu_data.

    J

Re: Cpufreq 2.4.22-pre6 & Pentium M

[Dominik Brodowski]

On Fri, Jul 18, 2003 at 02:39:57PM -0700, Jeremy Fitzhardinge wrote:
> On Fri, 2003-07-18 at 14:09, Eduardo Gonzalez-Solares wrote:
> > Nothing in dmesg. It seems the problem is in:
> > 
> >        if (!cpu_has(cpu, X86_FEATURE_EST))
> >                return -ENODEV;
> 
> I'm not sure who maintains the 2.4 port

/me is not maintaining it, but I'm the culprit for this bug.

>, but the problem is that the
> core code which sets up the CPU feature bits doesn't know about the
> extended feature word, so it doesn't read the X86_FEATURE_EST bit from
> the CPU.
> 
> The previous versions of this patch used this functional but ugly code:
>         int dummy, ecx;
>         
>         cpuid(1,&dummy,&dummy,&ecx,&dummy);
>         if (!(ecx & (1<<7)))
>         	return -ENODEV;
> 
> Either the new ports of speedstep-centrino.c need to keep using this
> code, or the X86_FEATURE_EST bit needs to be put into cpu_data.

Will send davej an updated version [for 2.4.22-pre7] early next week.

       Dominik