[PATCH 2.6.12-rc5] policy->lock in cpufreq_add_dev

Hello,
I think that it's not necessary to take the policy->lock in cpufreq_add_dev.
Am I missing something? What is the lock supposed to protect from?

Michal

diff -Nurp -X linux/Documentation/dontdiff linux/drivers/cpufreq/cpufreq.c linux.mich/drivers/cpufreq/cpufreq.c
--- linux/drivers/cpufreq/cpufreq.c	2005-05-31 12:59:41.000000000 +0200
+++ linux.mich/drivers/cpufreq/cpufreq.c	2005-06-01 18:42:50.000000000 +0200
 <at>  <at>  -605,7 +605,7  <at>  <at>  static int cpufreq_add_dev (struct sys_d
 	policy->cpu = cpu;
 	policy->cpus = cpumask_of_cpu(cpu);

-	init_MUTEX_LOCKED(&policy->lock);
+	init_MUTEX(&policy->lock);
 	init_completion(&policy->kobj_unregister);
 	INIT_WORK(&policy->update, handle_update, (void *)(long)cpu);

 <at>  <at>  -646,8 +646,7  <at>  <at>  static int cpufreq_add_dev (struct sys_d
 	spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
 	policy->governor = NULL; /* to assure that the starting sequence is
 				  * run in cpufreq_set_policy */
-	up(&policy->lock);
-	
+
 	/* set default policy */
 	
 	ret = cpufreq_set_policy(&new_policy);

powernow-k8 and stuck change-pending bit

I'm having a problem with powernow-k8 intermittent failures and would
appreciate some help.

system:

  * Athlon 64 2800+, stepping 10
  * Chaintech K8M800 socket 754 (no Cool'n'Quiet support)
  * linux-2.6.12-rc5 (+ powernow-k8 1.40.2 patch)

symptoms:

    After working fine for a while (several minutes to several hours),
cpufreq seems to get into a bad state where:

     * change pending bit set / stuck kernel messages appear

     * cat of /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
hangs for a few seconds and finally returns "<unknown>".  However a cat
of /proc/cpuinfo works and seems to show the correct cpu MHz.

     * reloading powernow-k8 module fails, with "change pending bit stuck"

     * the problem can sometimes be provoked by stopping and starting
       powernowd

Attached is some kernel output with "cpufreq.debug=3".  The debug output
doesn't seem to provide much information at the point of failure.

--John

speedstep_smi module loads randomly.

this is not a real issue since its working.. but i wanted to know why it does 
like this:

root <at> sajkisen:/home/sajko> modprobe speedstep_smi
FATAL: Error inserting speedstep_smi 
(/lib/modules/2.6.11-sr5/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-smi.ko): 
No such device
root <at> sajkisen:/home/sajko> modprobe speedstep_smi
FATAL: Error inserting speedstep_smi 
(/lib/modules/2.6.11-sr5/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-smi.ko): 
No such device
root <at> sajkisen:/home/sajko> modprobe speedstep_smi
FATAL: Error inserting speedstep_smi 
(/lib/modules/2.6.11-sr5/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-smi.ko): 
No such device
root <at> sajkisen:/home/sajko> modprobe speedstep_smi
FATAL: Error inserting speedstep_smi 
(/lib/modules/2.6.11-sr5/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-smi.ko): 
No such device
root <at> sajkisen:/home/sajko> modprobe speedstep_smi
root <at> sajkisen:/home/sajko> 

fyi i havent done anything in another terminal or anything while ive tried to 
load it... ive just spammed 4-5 times the up arrow and pressed enter :P

its wierd since it also takes from 1st attempt to 5 attempts to make it insert 
the module. just thought someone seen it before and know what to do to fix it 
(since when im doing it in modules.conf it returns the same error thus not 
loading the module when i boot my laptop :P)

RE: DBS enabling on EM64T machine with cpufreqd

If you're having trouble with cpufreqd on SMP systems, try CPUSpeed. It 
works perfectly.

     http://carlthompson.net/software/cpuspeed

Carl Thompson

----- Message from venkatesh.pallipadi <at> intel.com ---------
    Date: Thu, 26 May 2005 06:15:07 -0700
    From: "Pallipadi, Venkatesh" <venkatesh.pallipadi <at> intel.com>
Reply-To: "Pallipadi, Venkatesh" <venkatesh.pallipadi <at> intel.com>
Subject: RE: DBS enabling on EM64T machine with cpufreqd
      To: "Lin, Zihui" <zihui.lin <at> intel.com>, cpufreq <at> lists.linux.org.uk

>
> For Nocona I would suggest using the in kernel ondemand governor. More
> details here
> http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/xeon/reference/1959
> 10.htm
>
> And newer versions of the userspace governors should be able to handle
> SMP processsors. Earlier versions didn't. Not sure which version of
> cpufreqd you are using.
>
> Thanks,
> Venki
>
>> -----Original Message-----
>> From: cpufreq-bounces <at> lists.linux.org.uk

Re: [PATCH 2.6.12-rc5] policy->lock in cpufreq_add_dev

On Wed, Jun 01, 2005 at 06:57:12PM +0200, Michal Schmidt wrote:
> Hello,
> I think that it's not necessary to take the policy->lock in cpufreq_add_dev.
> Am I missing something? What is the lock supposed to protect from?

Well, indeed it is not necessary to take the policy->lock, although it
doesn't do any harm AFAICS. I added it to make sure that _all_ accesses to
the data is protected by the lock, how serialized they may ever be..

Thanks,
	Dominik

PS: Always add Signed-off-by lines to your patches, please, as per
Documentation/SubmittingPatches

Re: speedstep_smi module loads randomly.

Hi,

On Sun, Jun 05, 2005 at 12:50:32AM +0200, Fredrik Eriksson wrote:
> this is not a real issue since its working.. but i wanted to know why it does 
> like this:

Could you enable CPUFREQ_DEBUG in the kernel config, please, and add
"cpufreq.debug=2" to the kernel command line, and send me the dmesg output
of (failed) attempts to load speedstep_smi? I'm curious as to _where_ it
fails to load. And, of course, I'm not able to reproduce it locally...

Thanks,
	Dominik

Re: [PATCH 2.6.12-rc5] policy->lock in cpufreq_add_dev

Dominik Brodowski wrote:
> Well, indeed it is not necessary to take the policy->lock, although it
> doesn't do any harm AFAICS. I added it to make sure that _all_ accesses to
> the data is protected by the lock, how serialized they may ever be..

I thought so. I understand it doesn't do any harm in standard kernel. It 
is perfectly valid to take the policy->lock there and the function is 
not performance critical at all, so we can afford that.
There's only an issue in combination with Ingo's realtime-preempt patch,
where every usage of init_MUTEX_LOCKED becomes suspicious. It often 
indicates that the code uses a mutex where it should use a completion 
instead. However, this is not the case with cpufreq, where policy->lock 
really acts as a mutex. So I looked into it and wasn't able to find the 
reason for the lock being taken in cpufreq_add_dev.

> Thanks,
> 	Dominik
> 
> PS: Always add Signed-off-by lines to your patches, please, as per
> Documentation/SubmittingPatches

Sorry, I forgot about that. Here it is again, with the sign-off.
I know it's not a bugfix, because the code works perfectly it the normal 
kernel (only realtime-preempt cares). It's just a minor cleanup. It 
would be nice if you applied it, but no problem if you don't:

It's unnecessary to take policy->lock in cpufreq_add_dev as the access 
to the policy object is guaranteed to be serialized there.

Signed-off-by: Michal Schmidt <xschmi00 <at> stud.feec.vutbr.cz>

Temporary freezes in AMD Sempron 2800+

Hi!

I have a laptop with an AMD Sempron 2800+ (Acer Aspire 3002NLC). The
machine seems to get unresponsive every time the frequency changes
(the music stops for a second, say)...I tested this by using the
ondemand kernel governor. I use linux-2.6.12-rc4-ck1 with the inotify
patch. (With two more modules, fuse and cdfs, but I guess that
wouldn't matter much). Watching the current frequency file in /sys
shows that this sudden freeze occurs whenever the value changes.

Thanx,
Ramkumar.

--

-- 
The day Microsoft makes something that doesn't suck
is probably the day they start making vacuum cleaners.
                                               -Ernst Jan Plugge

Re: Temporary freezes in AMD Sempron 2800+

Hi,

On Monday 06 of June 2005 18:30, Ramkumar R wrote:
> I set the governor to userspace and tried echoing one of the speeds in
> scaling_available_frequencies to scaling_setspeed...it still hung for
> a second or two...just to ensure that, i did run `powernowd
> -vvvd`...everytime the speed changed to one of the valid frequencies,
> it hung...and one more observation, i've heard that amd supports quite
> a few frequencies...but scaling_available_frequencies just shows up
> 1600000 and 800000.
>
> and yes, i don't ACPI_CONTAINER in my kernel...
>
> Ramkumar.
>
> On 6/6/05, Michał Pytasz <mpytasz <at> pai.net.pl> wrote:
> > Hi,
> >
> > Dnia poniedziałek, 6 czerwca 2005 16:49, Ramkumar R napisał:
> > > Hi!
> > >
> > > I have a laptop with an AMD Sempron 2800+ (Acer Aspire 3002NLC). The
> > > machine seems to get unresponsive every time the frequency changes
> > > (the music stops for a second, say)...I tested this by using the
> > > ondemand kernel governor. I use linux-2.6.12-rc4-ck1 with the inotify
> > > patch. (With two more modules, fuse and cdfs, but I guess that
> > > wouldn't matter much). Watching the current frequency file in /sys
> > > shows that this sudden freeze occurs whenever the value changes.
> > >
> > > Thanx,

Re: Temporary freezes in AMD Sempron 2800+

On 6/6/05, Michał Pytasz <mpytasz <at> posejdon.wpk.p.lodz.pl> wrote:
> On Monday 06 of June 2005 19:21, Ramkumar R wrote:
> > no....i don't have (and don't want to install :) ) windows...do u mean
> > stuff like bit errors when u mean memory problems ? i just got this
> > laptop (about a month back)...and i had run memtest successfully when
> > i bought it...
> 
> Well, I've seen such a problem with athlon64 and faulty hynix module (probably
> You can find it in list archive). After I had it replaced everything became
> stable, memtest did pass with faulty module, too. Problem occured when cpu
> was going from low to high frequency.

mine hangs temporarily for *any* change in frequency though....

> That's why I asked about Windoze, I did not mean using it for work, but it may
> give a hint if it is a hardware problem. I don't think it could be a driver
> problem since I have similar machine with same CPU (Mobile Sempron 2800+, via
> k8n800) and it runs stable (with linux gentoo). I think it could be one of
> two problems:
> 1. Software: missconfigured kernel or misslinked libraries in the system (but
> in this case it should not hang hard and I guess there would be no
> correlation with frequency scaling)

i don't get that misslinked libraries part....please excuse my
ignorance but since the problem occurs even with the kernel level
ondemand governor, is this likely to be a problem...

> 2. Hardware problem.

just thinking that if it had been an hardware error, isn't it more