remove cpu hotplug bustification in cpufreq.

remove cpu hotplug bustification in cpufreq.

[Dave Jones]

This stuff makes my head hurt. Someone who is motivated
enough to fix up hotplug-cpu can fix this up later.
In the meantime, this patch should cure the lockdep
warnings that seem to trigger very easily.

Signed-off-by: Dave Jones <davej@redhat.com>

--- linux-2.6.17.noarch/drivers/cpufreq/cpufreq_ondemand.c~	2006-07-22 15:35:04.000000000 -0400
+++ linux-2.6.17.noarch/drivers/cpufreq/cpufreq_ondemand.c	2006-07-22 15:35:16.000000000 -0400
@@ -408,7 +408,6 @@ static int cpufreq_governor_dbs(struct c
 		break;
 
 	case CPUFREQ_GOV_LIMITS:
-		lock_cpu_hotplug();
 		mutex_lock(&dbs_mutex);
 		if (policy->max < this_dbs_info->cur_policy->cur)
 			__cpufreq_driver_target(this_dbs_info->cur_policy,
@@ -419,7 +418,6 @@ static int cpufreq_governor_dbs(struct c
 			                        policy->min,
 			                        CPUFREQ_RELATION_L);
 		mutex_unlock(&dbs_mutex);
-		unlock_cpu_hotplug();
 		break;
 	}
 	return 0;
--- linux-2.6.17.noarch/drivers/cpufreq/cpufreq_stats.c~	2006-07-22 15:35:40.000000000 -0400
+++ linux-2.6.17.noarch/drivers/cpufreq/cpufreq_stats.c	2006-07-22 15:35:54.000000000 -0400
@@ -350,12 +350,10 @@ __init cpufreq_stats_init(void)
 	}
 
 	register_hotcpu_notifier(&cpufreq_stat_cpu_notifier);
-	lock_cpu_hotplug();
 	for_each_online_cpu(cpu) {
 		cpufreq_stat_cpu_callback(&cpufreq_stat_cpu_notifier, CPU_ONLINE,
 			(void *)(long)cpu);
 	}
-	unlock_cpu_hotplug();
 	return 0;
 }
 static void
@@ -368,12 +366,10 @@ __exit cpufreq_stats_exit(void)
 	cpufreq_unregister_notifier(&notifier_trans_block,
 			CPUFREQ_TRANSITION_NOTIFIER);
 	unregister_hotcpu_notifier(&cpufreq_stat_cpu_notifier);
-	lock_cpu_hotplug();
 	for_each_online_cpu(cpu) {
 		cpufreq_stat_cpu_callback(&cpufreq_stat_cpu_notifier, CPU_DEAD,
 			(void *)(long)cpu);
 	}
-	unlock_cpu_hotplug();
 }
 
 MODULE_AUTHOR ("Zou Nan hai <nanhai.zou@intel.com>");
--- linux-2.6.17.noarch/drivers/cpufreq/cpufreq.c~	2006-07-22 15:36:05.000000000 -0400
+++ linux-2.6.17.noarch/drivers/cpufreq/cpufreq.c	2006-07-22 15:36:20.000000000 -0400
@@ -423,8 +423,6 @@ static ssize_t store_scaling_governor (s
 	if (cpufreq_parse_governor(str_governor, &new_policy.policy, &new_policy.governor))
 		return -EINVAL;
 
-	lock_cpu_hotplug();
-
 	/* Do not use cpufreq_set_policy here or the user_policy.max
 	   will be wrongly overridden */
 	mutex_lock(&policy->lock);
@@ -434,8 +432,6 @@ static ssize_t store_scaling_governor (s
 	policy->user_policy.governor = policy->governor;
 	mutex_unlock(&policy->lock);
 
-	unlock_cpu_hotplug();
-
 	return ret ? ret : count;
 }
 
@@ -1203,14 +1199,11 @@ int __cpufreq_driver_target(struct cpufr
 {
 	int retval = -EINVAL;
 
-	lock_cpu_hotplug();
 	dprintk("target for CPU %u: %u kHz, relation %u\n", policy->cpu,
 		target_freq, relation);
 	if (cpu_online(policy->cpu) && cpufreq_driver->target)
 		retval = cpufreq_driver->target(policy, target_freq, relation);
 
-	unlock_cpu_hotplug();
-
 	return retval;
 }
 EXPORT_SYMBOL_GPL(__cpufreq_driver_target);
--- linux-2.6.17.noarch/drivers/cpufreq/cpufreq_conservative.c~	2006-07-22 15:36:46.000000000 -0400
+++ linux-2.6.17.noarch/drivers/cpufreq/cpufreq_conservative.c	2006-07-22 15:36:57.000000000 -0400
@@ -423,14 +423,12 @@ static void dbs_check_cpu(int cpu)
 static void do_dbs_timer(void *data)
 { 
 	int i;
-	lock_cpu_hotplug();
 	mutex_lock(&dbs_mutex);
 	for_each_online_cpu(i)
 		dbs_check_cpu(i);
 	schedule_delayed_work(&dbs_work, 
 			usecs_to_jiffies(dbs_tuners_ins.sampling_rate));
 	mutex_unlock(&dbs_mutex);
-	unlock_cpu_hotplug();
 } 
 
 static inline void dbs_timer_init(void)
@@ -525,7 +523,6 @@ static int cpufreq_governor_dbs(struct c
 		break;
 
 	case CPUFREQ_GOV_LIMITS:
-		lock_cpu_hotplug();
 		mutex_lock(&dbs_mutex);
 		if (policy->max < this_dbs_info->cur_policy->cur)
 			__cpufreq_driver_target(
@@ -536,7 +533,6 @@ static int cpufreq_governor_dbs(struct c
 					this_dbs_info->cur_policy,
 				       	policy->min, CPUFREQ_RELATION_L);
 		mutex_unlock(&dbs_mutex);
-		unlock_cpu_hotplug();
 		break;
 	}
 	return 0;

-- 
http://www.codemonkey.org.uk

Re: remove cpu hotplug bustification in cpufreq.

[Linus Torvalds]

On Sat, 22 Jul 2006, Dave Jones wrote:
>
> This stuff makes my head hurt. Someone who is motivated
> enough to fix up hotplug-cpu can fix this up later.
> In the meantime, this patch should cure the lockdep
> warnings that seem to trigger very easily.

It doesn't seem to fix all problems. On CPU unplug, I still get deadlocks 
through some workqueue:

 [<c03af64a>] __mutex_lock_slowpath+0x4d/0x7b
 [<c03af687>] .text.lock.mutex+0xf/0x14
 [<c0137591>] __lock_cpu_hotplug+0x36/0x56
 [<c01375ca>] lock_cpu_hotplug+0xa/0xc
 [<c012f7c2>] flush_workqueue+0x2d/0x61
 [<c012f83b>] flush_scheduled_work+0xd/0xf
 ...

and the nasty part is that this can apparently hit _any_ process that 
wants to flush workqueues (in one particular case, it was through 
tty_release() -> release_dev() in drivers/char/tty.c).

The whole CPU hotplug locking seems to be broken.

		Linus

Re: remove cpu hotplug bustification in cpufreq.

[Andrew Morton]

On Sat, 22 Jul 2006 17:10:36 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:

> 
> 
> On Sat, 22 Jul 2006, Dave Jones wrote:
> >
> > This stuff makes my head hurt. Someone who is motivated
> > enough to fix up hotplug-cpu can fix this up later.
> > In the meantime, this patch should cure the lockdep
> > warnings that seem to trigger very easily.
> 
> It doesn't seem to fix all problems. On CPU unplug, I still get deadlocks 
> through some workqueue:
> 
>  [<c03af64a>] __mutex_lock_slowpath+0x4d/0x7b
>  [<c03af687>] .text.lock.mutex+0xf/0x14
>  [<c0137591>] __lock_cpu_hotplug+0x36/0x56
>  [<c01375ca>] lock_cpu_hotplug+0xa/0xc
>  [<c012f7c2>] flush_workqueue+0x2d/0x61
>  [<c012f83b>] flush_scheduled_work+0xd/0xf
>  ...
> 
> and the nasty part is that this can apparently hit _any_ process that 
> wants to flush workqueues (in one particular case, it was through 
> tty_release() -> release_dev() in drivers/char/tty.c).

If one was sufficiently morbidly curious, one would ask for the rest of the
trace, to identify the deadlock.  But it's just not interesting.

Let's just delete the whole thing.

> The whole CPU hotplug locking seems to be broken.

It was just wrong in conception.  We should not and probably cannot fix it.
Let's just delete it all, then implement version 2.

Which is: subsystems are locally responsible for locking their per-cpu
resources.  No global lock.  Subsystems have two options:

a) If the resource can be accessed while running atomically, lock it
   with preempt_disable().  Because preempt_disable() holds off hotunplug.

b) If the kernel wants to sleep while requiring that the per-cpu
   resource remain stable, lock it down with mutex_lock() in the normal
   operating code and also lock it down with mutex_lock() in the
   subsystem's cpu hotplug notifier callback.

The precise handling of b) needs some thought and will depend upon how the
subsystem tells itself about the availability of each CPU's data.  A simple
implementation would be:

mainline_code()
{
	mutex_lock(lock);
	fiddle_with(data[some_cpu_id]);
	mutex_unlock(lock);
}

static int foo_cpu_callback(struct notifier_block *nfb, unsigned long action,
				void *hcpu)
{
	unsigned int cpu = (unsigned long)hcpu;

	switch (action) {
	case CPU_DOWN_PREPARE:
		mutex_lock(lock);
		break;
	case CPU_DOWN_FAILED:
		mutex_unlock(lock);
		break;
	case CPU_DOWN_DEAD:
		mutex_unlock(lock);
		break;
	}
	return NOTIFY_OK;
}

Leaving the lock held in this manner isn't nice IMO, but it should work OK.

Note that there is what appears to be a bug in cpu_down().  This:

	if (cpu_online(cpu))
		goto out_thread;

should do a CPU_DOWN_FAILED callout.  Or, better, it should go
BUG(), because this shouldn't happen.

Re: remove cpu hotplug bustification in cpufreq.

[Linus Torvalds]

On Sat, 22 Jul 2006, Andrew Morton wrote:
> 
> It was just wrong in conception.  We should not and probably cannot fix it.
> Let's just delete it all, then implement version 2.

Well, I just got Ashok's trial patches which turns the thing into a rwsem 
as I outlined earlier.

I'll try them out. If they don't work, we should just delete the lock and 
go totally back to square 1.

		Linus

Re: remove cpu hotplug bustification in cpufreq.

[Arjan van de Ven]

On Sat, 2006-07-22 at 18:15 -0700, Linus Torvalds wrote:
> 
> On Sat, 22 Jul 2006, Andrew Morton wrote:
> > 
> > It was just wrong in conception.  We should not and probably cannot fix it.
> > Let's just delete it all, then implement version 2.
> 
> Well, I just got Ashok's trial patches which turns the thing into a rwsem 
> as I outlined earlier.

with rwsems being 100% fair... how is that going to make a difference?
Other than just making the deadlock harder to trigger because the writer
needs to come in just at the right time...

Re: remove cpu hotplug bustification in cpufreq.

[Andrew Morton]

On Sat, 22 Jul 2006 18:15:32 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:

> 
> 
> On Sat, 22 Jul 2006, Andrew Morton wrote:
> > 
> > It was just wrong in conception.  We should not and probably cannot fix it.
> > Let's just delete it all, then implement version 2.
> 
> Well, I just got Ashok's trial patches which turns the thing into a rwsem 
> as I outlined earlier.

Mark my words ;)

> I'll try them out. If they don't work, we should just delete the lock and 
> go totally back to square 1.

rwsem conversion has the potential to merely hide the problem.  Ingo, does
lockdep detect recursive down_read()?

Re: remove cpu hotplug bustification in cpufreq.

[Arjan van de Ven]

Hi,

> > Well, I just got Ashok's trial patches which turns the thing into a rwsem 
> > as I outlined earlier.
> 
> Mark my words ;)
> 
> > I'll try them out. If they don't work, we should just delete the lock and 
> > go totally back to square 1.
> 
> rwsem conversion has the potential to merely hide the problem.  Ingo, does
> lockdep detect recursive down_read()?

lockdep detects and warns about those.

I think we're about equally skeptical about this; I'm extremely hesitant
about any place in the kernel that uses rwsems for anything other than a
performance tweak. I've ended up with a mental model of rwsems that
basically comes down to "you need to be able to replace it with a mutex
without breaking correctness". Now of course that model is somewhat of
an oversimplification, but not by that much...

Greetings,
   Arjan van de Ven

Re: remove cpu hotplug bustification in cpufreq.

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> > I'll try them out. If they don't work, we should just delete the 
> > lock and go totally back to square 1.
> 
> rwsem conversion has the potential to merely hide the problem.  Ingo, 
> does lockdep detect recursive down_read()?

yeah, it does - there are a couple of testcases for it too, in the 
testsuite.

	Ingo

Re: remove cpu hotplug bustification in cpufreq.

[Linus Torvalds]

On Sun, 23 Jul 2006, Arjan van de Ven wrote:
> 
> with rwsems being 100% fair... how is that going to make a difference?
> Other than just making the deadlock harder to trigger because the writer
> needs to come in just at the right time...

Fair enough, I forgot about that particular braindamage. It would be _soo_ 
nice to have a proper rwsem like we used to.

Ok, here's a final try.

Its actually simpler than either of the previous ones, and it just does 
two different locks: a "cpu_add_remove_lock" which is entirely internal to 
kernel/cpu.c, and is held over the entirety of a cpu_add()/cpu_down() 
sequence, so that we will only ever add one CPU at a time.

The other lock is the "cpu_bitmask_lock", and the only thing that protects 
is the actual changing of the present bitmask. It's always nested inside 
of the "cpu_add_remove_lock" (if that is taken at all, of course).

The latter one is the one that "lock_cpu_hotplug()" actually takes, so 
anybody who does "lock_cpu_hotplug()" will only protect against the bitmap 
itself changing, not against the bigger issue of "cpu hotplug events are 
happening".

Does this work? Hey, it works for me once. It's pretty simple, and had 
better not have any recursion issues. It guarantees that actual cpu 
hotplug events are single-threaded wrt each other, and it does not allow 
any recursive taking of "lock_cpu_hotplug()", but since cpu_add() and 
cpu_down() no longer hold that particular lock when they to the call-outs 
for the cpu events, it should hopefully not be needed any more either.

Not very well tested, but it did suspend and resume twice for me.

Does anybody see any problems with this?

		Linus
---
 include/linux/cpu.h |    6 ------
 kernel/cpu.c        |   54 ++++++++++++---------------------------------------
 2 files changed, 13 insertions(+), 47 deletions(-)

diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 44a11f1..8fb344a 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -48,7 +48,6 @@ static inline void unregister_cpu_notifi
 {
 }
 #endif
-extern int current_in_cpu_hotplug(void);
 
 int cpu_up(unsigned int cpu);
 
@@ -61,10 +60,6 @@ static inline int register_cpu_notifier(
 static inline void unregister_cpu_notifier(struct notifier_block *nb)
 {
 }
-static inline int current_in_cpu_hotplug(void)
-{
-	return 0;
-}
 
 #endif /* CONFIG_SMP */
 extern struct sysdev_class cpu_sysdev_class;
@@ -73,7 +68,6 @@ #ifdef CONFIG_HOTPLUG_CPU
 /* Stop CPUs going up and down. */
 extern void lock_cpu_hotplug(void);
 extern void unlock_cpu_hotplug(void);
-extern int lock_cpu_hotplug_interruptible(void);
 #define hotcpu_notifier(fn, pri) {				\
 	static struct notifier_block fn##_nb =			\
 		{ .notifier_call = fn, .priority = pri };	\
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 70fbf2e..4157055 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -16,7 +16,8 @@ #include <linux/stop_machine.h>
 #include <linux/mutex.h>
 
 /* This protects CPUs going up and down... */
-static DEFINE_MUTEX(cpucontrol);
+static DEFINE_MUTEX(cpu_add_remove_lock);
+static DEFINE_MUTEX(cpu_bitmask_lock);
 
 static __cpuinitdata BLOCKING_NOTIFIER_HEAD(cpu_chain);
 
@@ -24,48 +25,18 @@ #ifdef CONFIG_HOTPLUG_CPU
 static struct task_struct *lock_cpu_hotplug_owner;
 static int lock_cpu_hotplug_depth;
 
-static int __lock_cpu_hotplug(int interruptible)
-{
-	int ret = 0;
-
-	if (lock_cpu_hotplug_owner != current) {
-		if (interruptible)
-			ret = mutex_lock_interruptible(&cpucontrol);
-		else
-			mutex_lock(&cpucontrol);
-	}
-
-	/*
-	 * Set only if we succeed in locking
-	 */
-	if (!ret) {
-		lock_cpu_hotplug_depth++;
-		lock_cpu_hotplug_owner = current;
-	}
-
-	return ret;
-}
-
 void lock_cpu_hotplug(void)
 {
-	__lock_cpu_hotplug(0);
+	mutex_lock(&cpu_bitmask_lock);
 }
 EXPORT_SYMBOL_GPL(lock_cpu_hotplug);
 
 void unlock_cpu_hotplug(void)
 {
-	if (--lock_cpu_hotplug_depth == 0) {
-		lock_cpu_hotplug_owner = NULL;
-		mutex_unlock(&cpucontrol);
-	}
+	mutex_unlock(&cpu_bitmask_lock);
 }
 EXPORT_SYMBOL_GPL(unlock_cpu_hotplug);
 
-int lock_cpu_hotplug_interruptible(void)
-{
-	return __lock_cpu_hotplug(1);
-}
-EXPORT_SYMBOL_GPL(lock_cpu_hotplug_interruptible);
 #endif	/* CONFIG_HOTPLUG_CPU */
 
 /* Need to know about CPUs going up/down? */
@@ -122,9 +93,7 @@ int cpu_down(unsigned int cpu)
 	struct task_struct *p;
 	cpumask_t old_allowed, tmp;
 
-	if ((err = lock_cpu_hotplug_interruptible()) != 0)
-		return err;
-
+	mutex_lock(&cpu_add_remove_lock);
 	if (num_online_cpus() == 1) {
 		err = -EBUSY;
 		goto out;
@@ -150,7 +119,10 @@ int cpu_down(unsigned int cpu)
 	cpu_clear(cpu, tmp);
 	set_cpus_allowed(current, tmp);
 
+	mutex_lock(&cpu_bitmask_lock);
 	p = __stop_machine_run(take_cpu_down, NULL, cpu);
+	mutex_unlock(&cpu_bitmask_lock);
+
 	if (IS_ERR(p)) {
 		/* CPU didn't die: tell everyone.  Can't complain. */
 		if (blocking_notifier_call_chain(&cpu_chain, CPU_DOWN_FAILED,
@@ -187,7 +159,7 @@ out_thread:
 out_allowed:
 	set_cpus_allowed(current, old_allowed);
 out:
-	unlock_cpu_hotplug();
+	mutex_unlock(&cpu_add_remove_lock);
 	return err;
 }
 #endif /*CONFIG_HOTPLUG_CPU*/
@@ -197,9 +169,7 @@ int __devinit cpu_up(unsigned int cpu)
 	int ret;
 	void *hcpu = (void *)(long)cpu;
 
-	if ((ret = lock_cpu_hotplug_interruptible()) != 0)
-		return ret;
-
+	mutex_lock(&cpu_add_remove_lock);
 	if (cpu_online(cpu) || !cpu_present(cpu)) {
 		ret = -EINVAL;
 		goto out;
@@ -214,7 +184,9 @@ int __devinit cpu_up(unsigned int cpu)
 	}
 
 	/* Arch-specific enabling code. */
+	mutex_lock(&cpu_bitmask_lock);
 	ret = __cpu_up(cpu);
+	mutex_unlock(&cpu_bitmask_lock);
 	if (ret != 0)
 		goto out_notify;
 	BUG_ON(!cpu_online(cpu));
@@ -227,6 +199,6 @@ out_notify:
 		blocking_notifier_call_chain(&cpu_chain,
 				CPU_UP_CANCELED, hcpu);
 out:
-	unlock_cpu_hotplug();
+	mutex_unlock(&cpu_add_remove_lock);
 	return ret;
 }

Re: remove cpu hotplug bustification in cpufreq.

[Linus Torvalds]

On Sun, 23 Jul 2006, Linus Torvalds wrote:
> 
> Does this work? Hey, it works for me once. It's pretty simple, and had 
> better not have any recursion issues.

GAAH!!

What kind of _crap_ is this cpufreq thing?

Lookie here:

	S06cpuspeed   D DD94A324  2180 10241  10215                     (NOTLB)
	Call Trace:
	 [<c03c411d>] __mutex_lock_slowpath+0x4d/0x7b
	 [<c03c415a>] .text.lock.mutex+0xf/0x14
	 [<c0137651>] lock_cpu_hotplug+0xd/0xf
	 [<c012f9df>] __create_workqueue+0x52/0x11f
	 [<df0cd336>] cpufreq_governor_dbs+0x9e/0x2c5 [cpufreq_ondemand]
	 [<c0305d2a>] __cpufreq_governor+0x57/0xd8
	 [<c0305ee8>] __cpufreq_set_policy+0x13d/0x1a9
	 [<c03060e4>] store_scaling_governor+0x12d/0x155
	 [<c03057a5>] store+0x34/0x45
	 [<c0199a6c>] sysfs_write_file+0x99/0xbf
	 [<c0164ac3>] vfs_write+0xab/0x157
	 [<c01650fc>] sys_write+0x3b/0x60
	 [<c0102d41>] sysenter_past_esp+0x56/0x79

where it takes the cpu_hotplug lock in "store_scaling_governor()", and 
then calls __cpufreq_set_policy(), and then that ondemand thing WILL TAKE 
IT AGAIN!

What a piece of crap. Why, why, why?

[ Linus bangs his head against the wall until tears of blood course down 
  his face ]

I will here-by re-introduce the recursion thing for lock_cpu_hotplug, but 
I will make it say some very rude things about idiots who create code like 
this. 

cpufreq (or at least ondemand) must DIE! And the people who wrote that 
crap should have red-hot pokers jammed into some very uncomfortable 
places.

		Linus

Re: remove cpu hotplug bustification in cpufreq.

[Patrick McFarland]

On Sunday 23 July 2006 14:12, Linus Torvalds wrote:
> On Sun, 23 Jul 2006, Linus Torvalds wrote:
> [ Linus bangs his head against the wall until tears of blood course down
>   his face ]

I know how you feel.

> cpufreq (or at least ondemand) must DIE! And the people who wrote that
> crap should have red-hot pokers jammed into some very uncomfortable
> places.

You know what else must die? powernowd... which does exactly what the 
conservative governor does, but takes about a meg of memory to do it, and it 
doesn't even provide stuff like changing behavior based on ac/battery state 
or lm_sensors feedback.

-- 
Patrick McFarland || www.AdTerrasPerAspera.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
Inc, 1989

Re: remove cpu hotplug bustification in cpufreq.

[Arjan van de Ven]

On Sun, 2006-07-23 at 11:12 -0700, Linus Torvalds wrote:
> 
> On Sun, 23 Jul 2006, Linus Torvalds wrote:
> > 
> > Does this work? Hey, it works for me once. It's pretty simple, and had 
> > better not have any recursion issues.
> 
> GAAH!!
> 
> What kind of _crap_ is this cpufreq thing?


this is why lockdep got highly upset with it, and why Davej proposed to
remove the locking entirely for now until it can be put back in a
correct way....

Re: remove cpu hotplug bustification in cpufreq.

[Dave Jones]

On Wed, Jul 26, 2006 at 06:12:57PM +0100, Russell King wrote:

 > > Things used to be fairly simple until hotplug cpu came along :-/
 > > Each day, I'm getting more of the opinion that my patch just ripping
 > > out this garbage is the right solution.
 > 
 > Not sure if I'm reading your sentiment correctly, but...

You didn't.
The garbage I referred to was 'cpu hotplug locking'.

		Dave

-- 
http://www.codemonkey.org.uk

Re: remove cpu hotplug bustification in cpufreq.

[Russell King]

On Tue, Jul 25, 2006 at 04:46:24PM -0400, Dave Jones wrote:
> On Tue, Jul 25, 2006 at 08:54:49PM +0200, Ingo Molnar wrote:
>  > 
>  > * Linus Torvalds <torvalds@osdl.org> wrote:
>  > 
>  > > The current -git tree will complain about some of the more obvious 
>  > > problems. If you see a "Lukewarm IQ" message, it's a sign of somebody 
>  > > re-taking a cpu lock that is already held.
>  > testing on my latest-rawhide laptop (kernel-2.6.17-1.2445.fc6 and later 
>  > rpms have this change) seems to have pushed the problem over to another 
>  > lock:
>  > 
>  >   S06cpuspeed/1580 is trying to acquire lock:
>  >    (&policy->lock){--..}, at: [<c06075f9>] mutex_lock+0x21/0x24
>  > 
>  >   but task is already holding lock:
>  >    (cpu_bitmask_lock){--..}, at: [<c06075f9>] mutex_lock+0x21/0x24
>  > 
>  >   which lock already depends on the new lock.
>  > 
>  > and we also get the:
>  > 
>  >   Lukewarm IQ detected in hotplug locking
>  > 
>  > message :-| Find the full bootlog below. And i dont understand the 
>  > cpufreq code well enough to fix this. In fact, does anyone understand 
>  > it? :-/
> 
> Things used to be fairly simple until hotplug cpu came along :-/
> Each day, I'm getting more of the opinion that my patch just ripping
> out this garbage is the right solution.

Not sure if I'm reading your sentiment correctly, but...

It came from the ARM tree, where it had one specific problem to solve -
how to change the CPU core frequency in a safe way.

"Safe way" means informing drivers that they need to quiesce their DMA,
_carefully_ reprogramming the SDRAM timings so we don't lose system
memory, etc.  Locking was (iirc) semaphore based because we used notifier
lists and the like which could sleep (and drivers did and continue to
sleep in the callbacks).

It then got battered into working for x86, which brought a new realm of
locking issues.

Maybe the right answer back in years gone by was to be hard-nosed about
it and said "hands off, this is ARM only, invent your own".

Therefore, if you are intending throwing out cpufreq, I'd like to replace
it with the ARM-only version instead - we _require_ this infrastructure
for the correct operation of some ARM platforms.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: remove cpu hotplug bustification in cpufreq.

[Linus Torvalds]

On Tue, 25 Jul 2006, Dave Jones wrote:
> 
> Things used to be fairly simple until hotplug cpu came along :-/
> Each day, I'm getting more of the opinion that my patch just ripping
> out this garbage is the right solution.

I think your patch is fine, but the cpu_hotplug_lock() should probably be 
taken by the callers much higher up in the stack, and then we could just 
have the rule that by the time any real cpufreq code is actually entered, 
we should hold the lock already.

		Linus

Re: remove cpu hotplug bustification in cpufreq.

[Linus Torvalds]

On Tue, 25 Jul 2006, Arjan van de Ven wrote:
>
> so cpufreq_set_policy() takes policy->lock, and then calls into the
> userspace governer code
> (__cpufreq_set_policy->cpufreq_governor->cpufreq_governor_userspace)
> which calls __cpufreq_driver_target... which does lock_cpu_hotplug().

Yeah. I think the target should _not_ take the lock_cpu_hotplug(), since 
the call chain (much much earlier) should have done it. 

Ie we should probably do it at the "cpufreq_set_policy()" level.

>      Arjan -- who's just cleaned Linus' wall to prepare it for more head
> banging

It's not actually "my wall". I'll happily share it with anybody else.

Please. Take my wall.

		Linus

Re: remove cpu hotplug bustification in cpufreq.

[Dave Jones]

On Tue, Jul 25, 2006 at 08:54:49PM +0200, Ingo Molnar wrote:
 > 
 > * Linus Torvalds <torvalds@osdl.org> wrote:
 > 
 > > The current -git tree will complain about some of the more obvious 
 > > problems. If you see a "Lukewarm IQ" message, it's a sign of somebody 
 > > re-taking a cpu lock that is already held.
 > testing on my latest-rawhide laptop (kernel-2.6.17-1.2445.fc6 and later 
 > rpms have this change) seems to have pushed the problem over to another 
 > lock:
 > 
 >   S06cpuspeed/1580 is trying to acquire lock:
 >    (&policy->lock){--..}, at: [<c06075f9>] mutex_lock+0x21/0x24
 > 
 >   but task is already holding lock:
 >    (cpu_bitmask_lock){--..}, at: [<c06075f9>] mutex_lock+0x21/0x24
 > 
 >   which lock already depends on the new lock.
 > 
 > and we also get the:
 > 
 >   Lukewarm IQ detected in hotplug locking
 > 
 > message :-| Find the full bootlog below. And i dont understand the 
 > cpufreq code well enough to fix this. In fact, does anyone understand 
 > it? :-/

Things used to be fairly simple until hotplug cpu came along :-/
Each day, I'm getting more of the opinion that my patch just ripping
out this garbage is the right solution.

		Dave

-- 
http://www.codemonkey.org.uk

Re: remove cpu hotplug bustification in cpufreq.

[Arjan van de Ven]

On Tue, 2006-07-25 at 20:54 +0200, Ingo Molnar wrote:
> * Linus Torvalds <torvalds@osdl.org> wrote:
> 
> > The current -git tree will complain about some of the more obvious 
> > problems. If you see a "Lukewarm IQ" message, it's a sign of somebody 
> > re-taking a cpu lock that is already held.
> 
> testing on my latest-rawhide laptop (kernel-2.6.17-1.2445.fc6 and later 
> rpms have this change) seems to have pushed the problem over to another 
> lock:
> 
>   S06cpuspeed/1580 is trying to acquire lock:
>    (&policy->lock){--..}, at: [<c06075f9>] mutex_lock+0x21/0x24
> 
>   but task is already holding lock:
>    (cpu_bitmask_lock){--..}, at: [<c06075f9>] mutex_lock+0x21/0x24
> 
>   which lock already depends on the new lock.


so cpufreq_set_policy() takes policy->lock, and then calls into the
userspace governer code
(__cpufreq_set_policy->cpufreq_governor->cpufreq_governor_userspace)
which calls __cpufreq_driver_target... which does lock_cpu_hotplug().


now on the other side:
store_scaling_governor() has the following code:

        lock_cpu_hotplug();

        /* Do not use cpufreq_set_policy here or the user_policy.max
           will be wrongly overridden */
        mutex_lock(&policy->lock);

so that's the entirely opposite lock order, and a classic AB-BA
deadlock.

Greetings,
     Arjan -- who's just cleaned Linus' wall to prepare it for more head
banging

Re: remove cpu hotplug bustification in cpufreq.

[Ingo Molnar]

* Linus Torvalds <torvalds@osdl.org> wrote:

> The current -git tree will complain about some of the more obvious 
> problems. If you see a "Lukewarm IQ" message, it's a sign of somebody 
> re-taking a cpu lock that is already held.

testing on my latest-rawhide laptop (kernel-2.6.17-1.2445.fc6 and later 
rpms have this change) seems to have pushed the problem over to another 
lock:

  S06cpuspeed/1580 is trying to acquire lock:
   (&policy->lock){--..}, at: [<c06075f9>] mutex_lock+0x21/0x24

  but task is already holding lock:
   (cpu_bitmask_lock){--..}, at: [<c06075f9>] mutex_lock+0x21/0x24

  which lock already depends on the new lock.

and we also get the:

  Lukewarm IQ detected in hotplug locking

message :-| Find the full bootlog below. And i dont understand the 
cpufreq code well enough to fix this. In fact, does anyone understand 
it? :-/

	Ingo

------------>
Linux version 2.6.17-1.2445.fc6 (brewbuilder@hs20-bc2-2.build.redhat.com) (gcc version 4.1.1 20060718 (Red Hat 4.1.1-9)) #1 SMP Mon Jul 24 22:43:31 EDT 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000ce000 - 00000000000d0000 (reserved)
 BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003dee0000 (usable)
 BIOS-e820: 000000003dee0000 - 000000003deec000 (ACPI data)
 BIOS-e820: 000000003deec000 - 000000003df00000 (ACPI NVS)
 BIOS-e820: 000000003df00000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved)
 BIOS-e820: 00000000fffffc00 - 0000000100000000 (reserved)
94MB HIGHMEM available.
895MB LOWMEM available.
Using x86 segment limits to approximate NX protection
On node 0 totalpages: 253664
  DMA zone: 4096 pages, LIFO batch:0
  Normal zone: 225279 pages, LIFO batch:31
  HighMem zone: 24289 pages, LIFO batch:3
DMI present.
Using APIC driver default
ACPI: RSDP (v000 HP                                    ) @ 0x000f6560
ACPI: RSDT (v001 HP     3084     0x06040000  LTP 0x00000000) @ 0x3dee66d9
ACPI: FADT (v001 HP     3084     0x06040000 PTL  0x00000050) @ 0x3deebed2
ACPI: BOOT (v001 HP     3084     0x06040000  LTP 0x00000001) @ 0x3deebfd8
ACPI: SSDT (v001 HP     3084     0x00000001 INTL 0x20030224) @ 0x3dee6b10
ACPI: SSDT (v001 HP     3084     0x00002000 INTL 0x20030224) @ 0x3dee670d
ACPI: DSDT (v001 HP     3084     0x06040000 MSFT 0x0100000e) @ 0x00000000
ACPI: PM-Timer IO Port: 0x1008
Allocating PCI resources starting at 50000000 (gap: 40000000:bf800000)
Detected 1596.087 MHz processor.
Built 1 zonelists.  Total pages: 253664
Kernel command line: ro root=/dev/VolGroup00/LogVol00 quiet selinux=0 3
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffd000 (017d3000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c0802000 soft=c07e2000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Console: colour VGA+ 80x25
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:    8
... MAX_LOCK_DEPTH:          30
... MAX_LOCKDEP_KEYS:        2048
... CLASSHASH_SIZE:           1024
... MAX_LOCKDEP_ENTRIES:     8192
... MAX_LOCKDEP_CHAINS:      8192
... CHAINHASH_SIZE:          4096
 memory used by lock dependency info: 696 kB
 per task-struct memory footprint: 1200 bytes
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 997324k/1014656k available (2092k kernel code, 16724k reserved, 1113k data, 240k init, 97156k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3194.92 BogoMIPS (lpj=6389854)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: afe9f9bf 00000000 00000000 00000000 00000180 00000000 00000000
CPU: After vendor identify, caps: afe9f9bf 00000000 00000000 00000000 00000180 00000000 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: After all inits, caps: afe9f1bf 00000000 00000000 00000040 00000180 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 16k freed
ACPI: Core revision 20060707
ACPI: setting ELCR to 0200 (from 0c20)
CPU0: Intel(R) Pentium(R) M processor 1.60GHz stepping 06
SMP motherboard not detected.
Local APIC not detected. Using dummy APIC emulation.
Brought up 1 CPUs
sizeof(vma)=84 bytes
sizeof(page)=32 bytes
sizeof(inode)=568 bytes
sizeof(dentry)=160 bytes
sizeof(ext3inode)=804 bytes
sizeof(buffer_head)=52 bytes
sizeof(skbuff)=172 bytes
checking if image is initramfs... it is
Freeing initrd memory: 1970k freed
PM: Adding info for No Bus:platform
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfd9a2, last bus=2
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
PM: Adding info for acpi:acpi
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PM: Adding info for No Bus:pci0000:00
Boot video device is 0000:00:02.0
PCI quirk: region 1000-107f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 1180-11bf claimed by ICH4 GPIO
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
PCI: Bus #03 (-#06) is hidden behind transparent bridge #02 (-#02) (try 'pci=assign-busses')
Please report the result to linux-kernel to fix this permanently
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
PM: Adding info for pci:0000:00:00.0
PM: Adding info for pci:0000:00:00.1
PM: Adding info for pci:0000:00:00.3
PM: Adding info for pci:0000:00:02.0
PM: Adding info for pci:0000:00:02.1
PM: Adding info for pci:0000:00:1d.0
PM: Adding info for pci:0000:00:1d.1
PM: Adding info for pci:0000:00:1d.2
PM: Adding info for pci:0000:00:1d.7
PM: Adding info for pci:0000:00:1e.0
PM: Adding info for pci:0000:00:1f.0
PM: Adding info for pci:0000:00:1f.1
PM: Adding info for pci:0000:00:1f.3
PM: Adding info for pci:0000:00:1f.5
PM: Adding info for pci:0000:00:1f.6
PM: Adding info for pci:0000:02:00.0
PM: Adding info for pci:0000:02:05.0
PM: Adding info for pci:0000:02:07.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs *10)
ACPI: PCI Interrupt Link [LNKB] (IRQs *5)
ACPI: PCI Interrupt Link [LNKC] (IRQs 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs *11)
ACPI: PCI Interrupt Link [LNKG] (IRQs 11) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs *11)
ACPI: Embedded Controller [H_EC] (gpe 29) interrupt mode.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
PM: Adding info for No Bus:pnp0
PM: Adding info for pnp:00:00
PM: Adding info for pnp:00:01
PM: Adding info for pnp:00:02
PM: Adding info for pnp:00:03
PM: Adding info for pnp:00:04
PM: Adding info for pnp:00:05
PM: Adding info for pnp:00:06
pnp: PnP ACPI: found 7 devices
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
PCI: Bus 3, cardbus bridge: 0000:02:05.0
  IO window: 00003400-000034ff
  IO window: 00003800-000038ff
  PREFETCH window: 50000000-51ffffff
  MEM window: 54000000-55ffffff
PCI: Bridge: 0000:00:1e.0
  IO window: 3000-3fff
  MEM window: e0200000-e02fffff
  PREFETCH window: 50000000-51ffffff
PCI: Setting latency timer of device 0000:00:1e.0 to 64
ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:02:05.0[A] -> Link [LNKE] -> GSI 11 (level, low) -> IRQ 11
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 9, 2097152 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
PM: Adding info for platform:pcspkr
Simple Boot Flag at 0x36 set to 0x1
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
apm: overridden by ACPI.
audit: initializing netlink socket (disabled)
audit(1153861090.720:1): initialized
highmem bounce pool size: 64 pages
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
PM: Adding info for platform:vesafb.0
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Thermal Zone [THRM] (63 C)
PM: Adding info for No Bus:pnp1
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected an Intel 855 Chipset.
agpgart: Detected 32636K stolen memory.
agpgart: AGP aperture is 128M @ 0xe8000000
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
PM: Adding info for platform:serial8250
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:00:1f.6[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5
ACPI: PCI interrupt for device 0000:00:1f.6 disabled
PM: Adding info for No Bus:isa
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
ICH4: chipset revision 3
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x1810-0x1817, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x1818-0x181f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: HITACHI_DK23FA-40, ATA DISK drive
PM: Adding info for No Bus:ide0
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
PM: Adding info for ide:0.0
Probing IDE interface ide1...
hdc: HL-DT-STCD-RW/DVD DRIVE GCC-4243N, ATAPI CD/DVD-ROM drive
PM: Adding info for No Bus:ide1
ide1 at 0x170-0x177,0x376 on irq 15
PM: Adding info for ide:1.0
hda: max request size: 128KiB
hda: 78140160 sectors (40007 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2
ide-floppy driver 0.99.newide
Yenta: CardBus bridge found at 0000:02:05.0 [103c:3084]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:02:05.0, mfunc 0x01111112, devctl 0x64
Yenta: ISA IRQ mask 0x04d8, PCI irq 11
Socket status: 30000010
Yenta: Raising subordinate bus# of parent bus (#02) from #02 to #06
pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff
cs: IO port probe 0x3000-0x3fff: clean.
pcmcia: parent PCI bridge Memory window: 0xe0200000 - 0xe02fffff
pcmcia: parent PCI bridge Memory window: 0x50000000 - 0x51ffffff
usbcore: registered new driver libusual
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PSM1] at 0x60,0x64 irq 1,12
PM: Adding info for platform:i8042
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
PM: Adding info for serio:serio0
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
PM: Adding info for serio:serio1
Using IPI No-Shortcut mode
ACPI: (supports S0 S3 S4 S5)
Freeing unused kernel memory: 240k freed
Write protecting the kernel read-only data: 395k
Time: tsc clocksource has been installed.
Time: acpi_pm clocksource has been installed.
input: AT Translated Set 2 keyboard as /class/input/input0
device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com
pccard: PCMCIA card inserted into slot 0
cs: memory probe 0xe0200000-0xe02fffff: excluding 0xe0200000-0xe020ffff
pcmcia: registering new device pcmcia0.0
PM: Adding info for pcmcia:0.0
Synaptics Touchpad, model: 1, fw: 5.9, id: 0x236eb3, caps: 0x904713/0x10008
input: SynPS/2 Synaptics TouchPad as /class/input/input1
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: dm-0: orphan cleanup on readonly fs
ext3_orphan_cleanup: deleting unreferenced inode 5763820
ext3_orphan_cleanup: deleting unreferenced inode 5765620
ext3_orphan_cleanup: deleting unreferenced inode 5762038
EXT3-fs: dm-0: 3 orphan inodes deleted
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
orinoco 0.15 (David Gibson <hermes@gibson.dropbear.id.au>, Pavel Roskin <proski@gnu.org>, et al)
orinoco_cs 0.15 (David Gibson <hermes@gibson.dropbear.id.au>, Pavel Roskin <proski@gnu.org>, et al)
eth0: Hardware identity 0001:0001:0004:0002
eth0: Station identity  001f:0001:0008:000a
eth0: Firmware determined as Lucent/Agere 8.10
eth0: Ad-hoc demo mode supported
eth0: IEEE standard IBSS ad-hoc mode supported
eth0: WEP supported, 104-bit key
eth0: MAC address 00:02:A5:2D:84:BE
eth0: Station name "HERMES I"
eth0: ready
eth0: orinoco_cs at 0.0, irq 3, io 0x3100-0x313f
hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, DMA
Uniform CD-ROM driver Revision: 3.20
ieee1394: Initialized config rom entry `ip1394'
ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 11
ACPI: PCI Interrupt 0000:02:07.0[A] -> Link [LNKF] -> GSI 11 (level, low) -> IRQ 11
PM: Adding info for ieee1394:fw-host0
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[11]  MMIO=[e0204000-e02047ff]  Max Packet=[2048]  IR/IT contexts=[4/8]
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
8139cp 0000:02:00.0: This (id 10ec:8139 rev 10) is not an 8139C+ compatible chip
8139cp 0000:02:00.0: Try the "8139too" driver instead.
ACPI: PCI Interrupt 0000:00:1f.3[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5
PM: Adding info for No Bus:i2c-0
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:1d.7[D] -> Link [LNKH] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 11, io mem 0xe0100000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
PM: Adding info for usb:usb1
PM: Adding info for No Bus:usbdev1.1_ep00
usb usb1: configuration #1 chosen from 1 choice
PM: Adding info for usb:1-0:1.0
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
USB Universal Host Controller Interface driver v3.0
8139too Fast Ethernet driver 0.9.27
PM: Adding info for No Bus:usbdev1.1_ep81
PM: Adding info for No Bus:usbdev1.1
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 10, io base 0x00001820
PM: Adding info for usb:usb2
PM: Adding info for No Bus:usbdev2.1_ep00
usb usb2: configuration #1 chosen from 1 choice
PM: Adding info for usb:2-0:1.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
input: PC Speaker as /class/input/input2
PM: Adding info for No Bus:usbdev2.1_ep81
PM: Adding info for No Bus:usbdev2.1
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 11, io base 0x00001840
PM: Adding info for usb:usb3
PM: Adding info for No Bus:usbdev3.1_ep00
usb usb3: configuration #1 chosen from 1 choice
PM: Adding info for usb:3-0:1.0
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
PM: Adding info for No Bus:usbdev3.1_ep81
PM: Adding info for No Bus:usbdev3.1
ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 11, io base 0x00001860
PM: Adding info for usb:usb4
PM: Adding info for No Bus:usbdev4.1_ep00
usb usb4: configuration #1 chosen from 1 choice
PM: Adding info for usb:4-0:1.0
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
PM: Adding info for No Bus:usbdev4.1_ep81
PM: Adding info for No Bus:usbdev4.1
ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ 10
eth1: RealTek RTL8139 at 0xf89a4800, 00:c0:9f:63:51:51, IRQ 10
eth1:  Identified 8139 chip type 'RTL-8100B/8139D'
usb 2-2: new low speed USB device using uhci_hcd and address 2
ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5
PCI: Setting latency timer of device 0000:00:1f.5 to 64
cs: IO port probe 0x100-0x3af: clean.
cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7
cs: IO port probe 0x820-0x8ff: clean.
cs: IO port probe 0xc00-0xcf7: clean.
cs: IO port probe 0xa00-0xaff: clean.
Intel 82802 RNG detected
PM: Adding info for usb:2-2
PM: Adding info for No Bus:usbdev2.2_ep00
usb 2-2: configuration #1 chosen from 1 choice
PM: Adding info for usb:2-2:1.0
input: HID 0461:4d03 as /class/input/input3
input: USB HID v1.00 Mouse [HID 0461:4d03] on usb-0000:00:1d.0-2
PM: Adding info for No Bus:usbdev2.2_ep81
PM: Adding info for No Bus:usbdev2.2
intel8x0_measure_ac97_clock: measured 53458 usecs
intel8x0: clocking to 48000
PM: Adding info for ac97:0-0:unknown codec
PCI: Enabling device 0000:00:1f.6 (0000 -> 0001)
ACPI: PCI Interrupt 0000:00:1f.6[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5
PCI: Setting latency timer of device 0000:00:1f.6 to 64
PM: Adding info for ieee1394:00c09f00002e3893
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00c09f00002e3893]
PM: Adding info for ieee1394:00c09f00002e3893-0
MC'97 0 converters and GPIO not ready (0x1)
PM: Adding info for ac97:1-0:unknown codec
floppy0: no floppy controllers found
lp: driver loaded but no devices found
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID0]
ACPI: Power Button (CM) [PWRB]
ibm_acpi: ec object not found
ACPI: Video Device [GFX0] (multi-head: yes  rom: yes  post: no)
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
device-mapper: multipath: version 1.0.4 loaded
loop: loaded (max 8 devices)
EXT3 FS on dm-0, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Adding 2031608k swap on /dev/VolGroup00/LogVol01.  Priority:-1 extents:1 across:2031608k

=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
S06cpuspeed/1580 is trying to acquire lock:
 (&policy->lock){--..}, at: [<c06075f9>] mutex_lock+0x21/0x24

but task is already holding lock:
 (cpu_bitmask_lock){--..}, at: [<c06075f9>] mutex_lock+0x21/0x24

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (cpu_bitmask_lock){--..}:
       [<c043bf43>] lock_acquire+0x4b/0x6c
       [<c060748a>] __mutex_lock_slowpath+0xbc/0x20a
       [<c06075f9>] mutex_lock+0x21/0x24
       [<c043f25a>] lock_cpu_hotplug+0x64/0x6f
       [<c05a22f8>] __cpufreq_driver_target+0x15/0x6d
       [<c05a3258>] cpufreq_governor_userspace+0x199/0x1cc
       [<c05a1d9f>] __cpufreq_governor+0x57/0xd8
       [<c05a1fb7>] __cpufreq_set_policy+0x197/0x1a9
       [<c05a1ff6>] cpufreq_set_policy+0x2d/0x6f
       [<c05a29d1>] cpufreq_add_dev+0x31a/0x496
       [<c054bf9c>] sysdev_driver_register+0x5c/0x9b
       [<c05a1c98>] cpufreq_register_driver+0x9e/0x14e
       [<c07ab22b>] centrino_init+0x9b/0xa2
       [<c0400454>] init+0x180/0x2fe
       [<c0402005>] kernel_thread_helper+0x5/0xb

-> #1 (userspace_mutex){--..}:
       [<c043bf43>] lock_acquire+0x4b/0x6c
       [<c060748a>] __mutex_lock_slowpath+0xbc/0x20a
       [<c06075f9>] mutex_lock+0x21/0x24
       [<c05a3112>] cpufreq_governor_userspace+0x53/0x1cc
       [<c05a1d9f>] __cpufreq_governor+0x57/0xd8
       [<c05a1f5d>] __cpufreq_set_policy+0x13d/0x1a9
       [<c05a1ff6>] cpufreq_set_policy+0x2d/0x6f
       [<c05a29d1>] cpufreq_add_dev+0x31a/0x496
       [<c054bf9c>] sysdev_driver_register+0x5c/0x9b
       [<c05a1c98>] cpufreq_register_driver+0x9e/0x14e
       [<c07ab22b>] centrino_init+0x9b/0xa2
       [<c0400454>] init+0x180/0x2fe
       [<c0402005>] kernel_thread_helper+0x5/0xb

-> #0 (&policy->lock){--..}:
       [<c043bf43>] lock_acquire+0x4b/0x6c
       [<c060748a>] __mutex_lock_slowpath+0xbc/0x20a
       [<c06075f9>] mutex_lock+0x21/0x24
       [<c05a2158>] store_scaling_governor+0x120/0x15b
       [<c05a17f0>] store+0x37/0x48
       [<c04a8cd4>] sysfs_write_file+0xab/0xd1
       [<c0471f33>] vfs_write+0xab/0x157
       [<c0472578>] sys_write+0x3b/0x60
       [<c0403faf>] syscall_call+0x7/0xb

other info that might help us debug this:

1 lock held by S06cpuspeed/1580:
 #0:  (cpu_bitmask_lock){--..}, at: [<c06075f9>] mutex_lock+0x21/0x24

stack backtrace:
 [<c04051ea>] show_trace_log_lvl+0x54/0xfd
 [<c04057a6>] show_trace+0xd/0x10
 [<c04058bf>] dump_stack+0x19/0x1b
 [<c043b030>] print_circular_bug_tail+0x59/0x64
 [<c043b843>] __lock_acquire+0x808/0x997
 [<c043bf43>] lock_acquire+0x4b/0x6c
 [<c060748a>] __mutex_lock_slowpath+0xbc/0x20a
 [<c06075f9>] mutex_lock+0x21/0x24
 [<c05a2158>] store_scaling_governor+0x120/0x15b
 [<c05a17f0>] store+0x37/0x48
 [<c04a8cd4>] sysfs_write_file+0xab/0xd1
 [<c0471f33>] vfs_write+0xab/0x157
 [<c0472578>] sys_write+0x3b/0x60
 [<c0403faf>] syscall_call+0x7/0xb
Lukewarm IQ detected in hotplug locking
BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug() (Not tainted)
 [<c04051ea>] show_trace_log_lvl+0x54/0xfd
 [<c04057a6>] show_trace+0xd/0x10
 [<c04058bf>] dump_stack+0x19/0x1b
 [<c043f23f>] lock_cpu_hotplug+0x49/0x6f
 [<c043384f>] __create_workqueue+0x52/0x116
 [<f8af2337>] cpufreq_governor_dbs+0x9f/0x2d7 [cpufreq_ondemand]
 [<c05a1d9f>] __cpufreq_governor+0x57/0xd8
 [<c05a1f5d>] __cpufreq_set_policy+0x13d/0x1a9
 [<c05a2165>] store_scaling_governor+0x12d/0x15b
 [<c05a17f0>] store+0x37/0x48
 [<c04a8cd4>] sysfs_write_file+0xab/0xd1
 [<c0471f33>] vfs_write+0xab/0x157
 [<c0472578>] sys_write+0x3b/0x60
 [<c0403faf>] syscall_call+0x7/0xb
Lukewarm IQ detected in hotplug locking
BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug() (Not tainted)
 [<c04051ea>] show_trace_log_lvl+0x54/0xfd
 [<c04057a6>] show_trace+0xd/0x10
 [<c04058bf>] dump_stack+0x19/0x1b
 [<c043f23f>] lock_cpu_hotplug+0x49/0x6f
 [<f8af250d>] cpufreq_governor_dbs+0x275/0x2d7 [cpufreq_ondemand]
 [<c05a1d9f>] __cpufreq_governor+0x57/0xd8
 [<c05a1fb7>] __cpufreq_set_policy+0x197/0x1a9
 [<c05a2165>] store_scaling_governor+0x12d/0x15b
 [<c05a17f0>] store+0x37/0x48
 [<c04a8cd4>] sysfs_write_file+0xab/0xd1
 [<c0471f33>] vfs_write+0xab/0x157
 [<c0472578>] sys_write+0x3b/0x60
 [<c0403faf>] syscall_call+0x7/0xb
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (7927 buckets, 63416 max) - 228 bytes per conntrack
eth1: New link status: Connected (0001)
audit(1153853928.095:2): audit_pid=1809 old=0 by auid=4294967295
DLM (built Jul 24 2006 22:44:14) installed
Bluetooth: Core ver 2.10
PM: Adding info for platform:bluetooth
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.8
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.8
Bluetooth: HIDP (Human Interface Emulation) ver 1.1
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
PM: Removing info for ac97:1-0:unknown codec
ACPI: PCI interrupt for device 0000:00:1f.6 disabled
eth1: no IPv6 routers present

Re: remove cpu hotplug bustification in cpufreq.

[Erik Mouw]

On Mon, Jul 24, 2006 at 05:59:23PM -0700, Linus Torvalds wrote:
> On Mon, 24 Jul 2006, Chuck Ebbert wrote:
> > 
> > I thought just the 'ondemand' governor was a problem?
> 
> The ondemand governor seems to be singled out not because it has unique 
> problems, but because it seems to be used by Fedora Core for some strange 
> reason.
> 
> I would judge that any bugs in cpufreq_ondemand.c are likely equally 
> evident in cpufreq_conservative.c, for example. I think the two have the 
> same background, and seem to have the same broken locking.

The "conservative" governor switches less often, so the locking
condition just happens less often.

After some strange lockups with 2.6.18-rc* I switched from "ondemand"
to "conservative" and now my laptop survives the night. Sheer luck, I
guess. I'd rather switch to "powersave" or "performance".


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: remove cpu hotplug bustification in cpufreq.

[Linus Torvalds]

On Mon, 24 Jul 2006, Chuck Ebbert wrote:
> 
> I thought just the 'ondemand' governor was a problem?

The ondemand governor seems to be singled out not because it has unique 
problems, but because it seems to be used by Fedora Core for some strange 
reason.

I would judge that any bugs in cpufreq_ondemand.c are likely equally 
evident in cpufreq_conservative.c, for example. I think the two have the 
same background, and seem to have the same broken locking.

> That thing has been broken since day 1 AFAICT.  There are lots of
> reports of problems with it on the list.

See above. I seriously doubt this is ondemand-specific. The whole cpufreq 
locking seems to be very screwed up.

The current -git tree will complain about some of the more obvious 
problems. If you see a "Lukewarm IQ" message, it's a sign of somebody 
re-taking a cpu lock that is already held.

			Linus

Re: remove cpu hotplug bustification in cpufreq.

[Chuck Ebbert]

In-Reply-To: <1153738326.3043.13.camel@laptopd505.fenrus.org>

On Mon, 24 Jul 2006 12:52:05 +0200, Arjan van de Ven wrote:
> 
> > What kind of _crap_ is this cpufreq thing?
> 
> this is why lockdep got highly upset with it, and why Davej proposed to
> remove the locking entirely for now until it can be put back in a
> correct way....

I thought just the 'ondemand' governor was a problem?

That thing has been broken since day 1 AFAICT.  There are lots of
reports of problems with it on the list.

-- 
Chuck