* remove cpu hotplug bustification in cpufreq.
@ 2006-07-22 19:40 Dave Jones
2006-07-23 0:10 ` Linus Torvalds
0 siblings, 1 reply; 22+ messages in thread
From: Dave Jones @ 2006-07-22 19:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Linux Kernel
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(¬ifier_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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: remove cpu hotplug bustification in cpufreq. 2006-07-22 19:40 remove cpu hotplug bustification in cpufreq Dave Jones @ 2006-07-23 0:10 ` Linus Torvalds 2006-07-23 1:06 ` Andrew Morton 0 siblings, 1 reply; 22+ messages in thread From: Linus Torvalds @ 2006-07-23 0:10 UTC (permalink / raw) To: Dave Jones; +Cc: Andrew Morton, Linux Kernel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-23 0:10 ` Linus Torvalds @ 2006-07-23 1:06 ` Andrew Morton 2006-07-23 1:15 ` Linus Torvalds 0 siblings, 1 reply; 22+ messages in thread From: Andrew Morton @ 2006-07-23 1:06 UTC (permalink / raw) To: Linus Torvalds; +Cc: davej, linux-kernel, Ashok Raj 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-23 1:06 ` Andrew Morton @ 2006-07-23 1:15 ` Linus Torvalds 2006-07-23 4:09 ` Arjan van de Ven 2006-07-23 5:34 ` Andrew Morton 0 siblings, 2 replies; 22+ messages in thread From: Linus Torvalds @ 2006-07-23 1:15 UTC (permalink / raw) To: Andrew Morton; +Cc: davej, linux-kernel, Ashok Raj 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-23 1:15 ` Linus Torvalds @ 2006-07-23 4:09 ` Arjan van de Ven 2006-07-23 17:20 ` Linus Torvalds 2006-07-23 5:34 ` Andrew Morton 1 sibling, 1 reply; 22+ messages in thread From: Arjan van de Ven @ 2006-07-23 4:09 UTC (permalink / raw) To: Linus Torvalds; +Cc: Ashok Raj, linux-kernel, davej, Andrew Morton 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... ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-23 4:09 ` Arjan van de Ven @ 2006-07-23 17:20 ` Linus Torvalds 2006-07-23 18:12 ` Linus Torvalds 0 siblings, 1 reply; 22+ messages in thread From: Linus Torvalds @ 2006-07-23 17:20 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Ashok Raj, linux-kernel, davej, Andrew Morton 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; } ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-23 17:20 ` Linus Torvalds @ 2006-07-23 18:12 ` Linus Torvalds 2006-07-23 18:34 ` Patrick McFarland 2006-07-24 10:52 ` Arjan van de Ven 0 siblings, 2 replies; 22+ messages in thread From: Linus Torvalds @ 2006-07-23 18:12 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Ashok Raj, linux-kernel, davej, Andrew Morton 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-23 18:12 ` Linus Torvalds @ 2006-07-23 18:34 ` Patrick McFarland 2006-07-24 10:52 ` Arjan van de Ven 1 sibling, 0 replies; 22+ messages in thread From: Patrick McFarland @ 2006-07-23 18:34 UTC (permalink / raw) To: Linus Torvalds Cc: Arjan van de Ven, Ashok Raj, linux-kernel, davej, Andrew Morton 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-23 18:12 ` Linus Torvalds 2006-07-23 18:34 ` Patrick McFarland @ 2006-07-24 10:52 ` Arjan van de Ven 1 sibling, 0 replies; 22+ messages in thread From: Arjan van de Ven @ 2006-07-24 10:52 UTC (permalink / raw) To: Linus Torvalds; +Cc: Ashok Raj, linux-kernel, davej, Andrew Morton 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.... ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-23 1:15 ` Linus Torvalds 2006-07-23 4:09 ` Arjan van de Ven @ 2006-07-23 5:34 ` Andrew Morton 2006-07-23 8:29 ` Arjan van de Ven 2006-07-23 16:24 ` Ingo Molnar 1 sibling, 2 replies; 22+ messages in thread From: Andrew Morton @ 2006-07-23 5:34 UTC (permalink / raw) To: Linus Torvalds; +Cc: davej, linux-kernel, ashok.raj, Ingo Molnar 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()? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-23 5:34 ` Andrew Morton @ 2006-07-23 8:29 ` Arjan van de Ven 2006-07-23 16:24 ` Ingo Molnar 1 sibling, 0 replies; 22+ messages in thread From: Arjan van de Ven @ 2006-07-23 8:29 UTC (permalink / raw) To: Andrew Morton; +Cc: Ingo Molnar, ashok.raj, linux-kernel, davej, Linus Torvalds 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-23 5:34 ` Andrew Morton 2006-07-23 8:29 ` Arjan van de Ven @ 2006-07-23 16:24 ` Ingo Molnar 1 sibling, 0 replies; 22+ messages in thread From: Ingo Molnar @ 2006-07-23 16:24 UTC (permalink / raw) To: Andrew Morton; +Cc: Linus Torvalds, davej, linux-kernel, ashok.raj * 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq.
@ 2006-07-25 0:21 Chuck Ebbert
2006-07-25 0:59 ` Linus Torvalds
0 siblings, 1 reply; 22+ messages in thread
From: Chuck Ebbert @ 2006-07-25 0:21 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Linus Torvalds, Ashok Raj, linux-kernel, Dave Jones, Andrew Morton
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
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: remove cpu hotplug bustification in cpufreq. 2006-07-25 0:21 Chuck Ebbert @ 2006-07-25 0:59 ` Linus Torvalds 2006-07-25 15:06 ` Erik Mouw 2006-07-25 18:54 ` Ingo Molnar 0 siblings, 2 replies; 22+ messages in thread From: Linus Torvalds @ 2006-07-25 0:59 UTC (permalink / raw) To: Chuck Ebbert Cc: Arjan van de Ven, Ashok Raj, linux-kernel, Dave Jones, Andrew Morton 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-25 0:59 ` Linus Torvalds @ 2006-07-25 15:06 ` Erik Mouw 2006-07-25 18:54 ` Ingo Molnar 1 sibling, 0 replies; 22+ messages in thread From: Erik Mouw @ 2006-07-25 15:06 UTC (permalink / raw) To: Linus Torvalds Cc: Chuck Ebbert, Arjan van de Ven, Ashok Raj, linux-kernel, Dave Jones, Andrew Morton 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-25 0:59 ` Linus Torvalds 2006-07-25 15:06 ` Erik Mouw @ 2006-07-25 18:54 ` Ingo Molnar 2006-07-25 19:30 ` Arjan van de Ven 2006-07-25 20:46 ` Dave Jones 1 sibling, 2 replies; 22+ messages in thread From: Ingo Molnar @ 2006-07-25 18:54 UTC (permalink / raw) To: Linus Torvalds Cc: Chuck Ebbert, Arjan van de Ven, Ashok Raj, linux-kernel, Dave Jones, Andrew Morton * 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-25 18:54 ` Ingo Molnar @ 2006-07-25 19:30 ` Arjan van de Ven 2006-07-25 20:57 ` Linus Torvalds 2006-07-25 20:46 ` Dave Jones 1 sibling, 1 reply; 22+ messages in thread From: Arjan van de Ven @ 2006-07-25 19:30 UTC (permalink / raw) To: Ingo Molnar Cc: Linus Torvalds, Chuck Ebbert, Ashok Raj, linux-kernel, Dave Jones, Andrew Morton 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-25 19:30 ` Arjan van de Ven @ 2006-07-25 20:57 ` Linus Torvalds 0 siblings, 0 replies; 22+ messages in thread From: Linus Torvalds @ 2006-07-25 20:57 UTC (permalink / raw) To: Arjan van de Ven Cc: Ingo Molnar, Chuck Ebbert, Ashok Raj, linux-kernel, Dave Jones, Andrew Morton 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-25 18:54 ` Ingo Molnar 2006-07-25 19:30 ` Arjan van de Ven @ 2006-07-25 20:46 ` Dave Jones 2006-07-25 20:59 ` Linus Torvalds 2006-07-26 17:12 ` Russell King 1 sibling, 2 replies; 22+ messages in thread From: Dave Jones @ 2006-07-25 20:46 UTC (permalink / raw) To: Ingo Molnar Cc: Linus Torvalds, Chuck Ebbert, Arjan van de Ven, Ashok Raj, linux-kernel, Andrew Morton 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-25 20:46 ` Dave Jones @ 2006-07-25 20:59 ` Linus Torvalds 2006-07-26 17:12 ` Russell King 1 sibling, 0 replies; 22+ messages in thread From: Linus Torvalds @ 2006-07-25 20:59 UTC (permalink / raw) To: Dave Jones Cc: Ingo Molnar, Chuck Ebbert, Arjan van de Ven, Ashok Raj, linux-kernel, Andrew Morton 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-25 20:46 ` Dave Jones 2006-07-25 20:59 ` Linus Torvalds @ 2006-07-26 17:12 ` Russell King 2006-07-26 17:53 ` Dave Jones 1 sibling, 1 reply; 22+ messages in thread From: Russell King @ 2006-07-26 17:12 UTC (permalink / raw) To: Dave Jones, Ingo Molnar, Linus Torvalds, Chuck Ebbert, Arjan van de Ven, Ashok Raj, linux-kernel, Andrew Morton 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: remove cpu hotplug bustification in cpufreq. 2006-07-26 17:12 ` Russell King @ 2006-07-26 17:53 ` Dave Jones 0 siblings, 0 replies; 22+ messages in thread From: Dave Jones @ 2006-07-26 17:53 UTC (permalink / raw) To: Ingo Molnar, Linus Torvalds, Chuck Ebbert, Arjan van de Ven, Ashok Raj, linux-kernel, Andrew Morton 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2006-07-26 17:55 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-07-22 19:40 remove cpu hotplug bustification in cpufreq Dave Jones 2006-07-23 0:10 ` Linus Torvalds 2006-07-23 1:06 ` Andrew Morton 2006-07-23 1:15 ` Linus Torvalds 2006-07-23 4:09 ` Arjan van de Ven 2006-07-23 17:20 ` Linus Torvalds 2006-07-23 18:12 ` Linus Torvalds 2006-07-23 18:34 ` Patrick McFarland 2006-07-24 10:52 ` Arjan van de Ven 2006-07-23 5:34 ` Andrew Morton 2006-07-23 8:29 ` Arjan van de Ven 2006-07-23 16:24 ` Ingo Molnar 2006-07-25 0:21 Chuck Ebbert 2006-07-25 0:59 ` Linus Torvalds 2006-07-25 15:06 ` Erik Mouw 2006-07-25 18:54 ` Ingo Molnar 2006-07-25 19:30 ` Arjan van de Ven 2006-07-25 20:57 ` Linus Torvalds 2006-07-25 20:46 ` Dave Jones 2006-07-25 20:59 ` Linus Torvalds 2006-07-26 17:12 ` Russell King 2006-07-26 17:53 ` Dave Jones
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).