On Sun, Sep 29, 2002 at 03:56:48PM -0400, Gerald Britton wrote:
> On Sun, Sep 29, 2002 at 12:10:18PM +0200, Dominik Brodowski wrote:
> > I think I found the problem: it should be GFP_ATOMIC and not GFP_KERNEL in
> > the allocation of struct cpufreq_driver. Will be fixed in the next release.
>
> Nope. That should be fine, it's in a process context and not holding any
> locks, so GFP_KERNEL should be fine. I found the bug though:
>
> -driver->policy = (struct cpufreq_policy *) (driver + sizeof(struct cpufreq_driver));
> +driver->policy = (struct cpufreq_policy *) (driver + 1);
>
> Remember your pointer arithmetic.
yes, you're right. I've just merged your patch into CVS, and I'll send a
patch to Linus really soon.
<snip>
> [rounding]
> There probably isn't a lot that can be done about these unfortunately, but
> they won't necessarily converge to a stable value so things may eventually
> start to fail.
Yes, that's a problem; but as cpufreq doesn't change speed dynamically yet
(and thus the number of transitions is somewhat limited) it shouldn't cause
too much trouble _yet_. But I'll try to think of a better solution _soon_.
Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Sep 30 2002 - 22:00:43 EST