On Tue, 2005-11-01 at 11:14 -0800, Ashok Raj wrote:
> On Tue, Nov 01, 2005 at 08:07:19PM +0100, Rafael J. Wysocki wrote:
> > Hi,
> >
> > > of taking cpucontrol lock in __cpufreq_driver_target().
> >
> > Yes, that's it.
> >
> > > The reason is we now enter the same code path from the cpu_up() and cpu_down()
> > > generated cpu notifier callbacks and ends up trying to lock when the
> > > call path already has the cpucontrol lock.
> > >
> > > Its happening because we do set_cpus_allowed() in powernowk8_target().
> >
> > Unfortunately, powernowk8_target() calls schedule() right after
> > set_cpus_allowed(), so it throws "scheduling while atomic" on every call,
> > because of the preempt_disable()/_enable() around it.
> >
> > Greetings,
> > Rafael
> >
>
> Thanks Rafael,
>
> could you try this patch instead? I hate to keep these state variables
> and thats why i went with the preempt approach, too bad it seems it wont
> work for more than just the case you mentioned.
>
> seems ugly, but i dont find a better looking cure...
It can't possibly be uglier than disabling preemption to work around a
locking bug.
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]