On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> On Tue, Jan 14, 2014 at 02:26:27PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > drivers/cpufreq/speedstep-lib.c: In function 'speedstep_get_freqs':
> > drivers/cpufreq/speedstep-lib.c:467:2: error: implicit declaration of function 'preempt_check_resched' [-Werror=implicit-function-declaration]
> > preempt_check_resched();
> > ^
> >
> > Caused by commit 62b94a08da1b ("sched/preempt: Take away
> > preempt_enable_no_resched() from modules") interacting with commit
> > 24e1937b2386 ("speedstep-smi: enable interrupts when waiting") from the
> > pm tree.
Try adding #include <linux/preempt.h> to speedstep-lib.c. Does it help?
> I think that pm commit is a very good example of why the sched/preempt
> patch is a very good idea.
>
> Also that Changelog fails to explain why enabling interrupts helps. What
> interrupt is required for progress, and how does it make the progress
> happen.
There is no explanation. It's hardware issue and I have no documentation
for the hardware.
The general problem is that if there are bus-master transfers running (or
possibly for other hardware reasons), the CPU refuses to change frequency.
You can wait a little bit and retry and maybe you succeed changing the
frequency next time.
If you enable interrupts, wait, disable interrupts and retry, you may
succeed. If you keep interrupts disabled and retry, you never succeed, no
matter how long do you wait. I found it experimentally, I don't know
reason for that.
Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
