linux-next: cpufreq tree build failure

linux-next: cpufreq tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

Hi Dave,

Today's linux-next build (x86_64 allmodconfig) failed like this:

arch/x86/kernel/cpu/cpufreq/powernow-k8.c: In function 'powernow_k8_cpu_init_acpi':
arch/x86/kernel/cpu/cpufreq/powernow-k8.c:836: error: 'space_id' undeclared (first use in this function)

Immediate cause is commit 77a33c31a78c6cd11395c8b554152be684110e94
("[CPUFREQ] checkpatch cleanups for powernow-k8") which clearly wasn't
build tested.

I have dropped the cpufreq tree for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: cpufreq tree build failure

[Dave Jones]

On Tue, Jan 20, 2009 at 01:50:59PM +1100, Stephen Rothwell wrote:
 > Hi Dave,
 > 
 > Today's linux-next build (x86_64 allmodconfig) failed like this:
 > 
 > arch/x86/kernel/cpu/cpufreq/powernow-k8.c: In function 'powernow_k8_cpu_init_acpi':
 > arch/x86/kernel/cpu/cpufreq/powernow-k8.c:836: error: 'space_id' undeclared (first use in this function)
 > 
 > Immediate cause is commit 77a33c31a78c6cd11395c8b554152be684110e94
 > ("[CPUFREQ] checkpatch cleanups for powernow-k8") which clearly wasn't
 > build tested.

wtf, I dropped a hunk somehow.

 > I have dropped the cpufreq tree for today.
 
I regenerated the tree with the missing line.
Thanks for catching this.

	Dave

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

Re: linux-next: cpufreq tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 257 bytes --]

Hi Dave,

On Tue, 20 Jan 2009 00:30:22 -0500 Dave Jones <davej@redhat.com> wrote:
>
> I regenerated the tree with the missing line.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: cpufreq tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

Hi Dave,

Today's linux-next build (powerpc allyesconfig) failed like this:

drivers/cpufreq/cpufreq_conservative.o: In function `minimum_sampling_rate':
(.opd+0x30): multiple definition of `minimum_sampling_rate'
drivers/cpufreq/cpufreq_ondemand.o:(.opd+0x18): first defined here
drivers/cpufreq/cpufreq_conservative.o: In function `minimum_sampling_rate':
drivers/cpufreq/cpufreq_conservative.c:64: multiple definition of `.minimum_sampling_rate'
drivers/cpufreq/cpufreq_ondemand.o:drivers/cpufreq/cpufreq_ondemand.c:62: first defined here

Caused by commit f935195b8a341d7ffdf600dd98a657f2f09b7908 ("[CPUFREQ]
ondemand/conservative: sanitize sampling_rate restrictions").

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: cpufreq tree build failure

[Thomas Renninger]

On Thursday 05 February 2009 08:54:20 Stephen Rothwell wrote:
> Hi Dave,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> drivers/cpufreq/cpufreq_conservative.o: In function `minimum_sampling_rate':
> (.opd+0x30): multiple definition of `minimum_sampling_rate'
> drivers/cpufreq/cpufreq_ondemand.o:(.opd+0x18): first defined here
> drivers/cpufreq/cpufreq_conservative.o: In function `minimum_sampling_rate':
> drivers/cpufreq/cpufreq_conservative.c:64: multiple definition of 
`.minimum_sampling_rate'
> drivers/cpufreq/cpufreq_ondemand.o:drivers/cpufreq/cpufreq_ondemand.c:62: 
first defined here
> 
> Caused by commit f935195b8a341d7ffdf600dd98a657f2f09b7908 ("[CPUFREQ]
> ondemand/conservative: sanitize sampling_rate restrictions").
> 
> I have reverted that commit for today.
Argh, I test compiled the conservative as module and ondemand permanent,
thus this bug did not show up.

The minimum_sampling_rate function must be declared static in both:
drivers/cpufreq/cpufreq_ondemand.c
and
drivers/cpufreq/cpufreq_conservative.c

This could be done by just adding this in the patch itself
(no newline needed).
Could Dave also drop the patch, declare the two functions static and
re-add it and you pick it up automatically with the next merge or
do I have to send an on top fix (or can you, Dave, just do this
little change)?

Sorry and thanks,

    Thomas

Re: linux-next: cpufreq tree build failure

[Thomas Renninger]

On Thursday 05 February 2009 08:54:20 Stephen Rothwell wrote:
> Hi Dave,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> drivers/cpufreq/cpufreq_conservative.o: In function `minimum_sampling_rate':
> (.opd+0x30): multiple definition of `minimum_sampling_rate'
> drivers/cpufreq/cpufreq_ondemand.o:(.opd+0x18): first defined here
> drivers/cpufreq/cpufreq_conservative.o: In function `minimum_sampling_rate':
> drivers/cpufreq/cpufreq_conservative.c:64: multiple definition of 
`.minimum_sampling_rate'
> drivers/cpufreq/cpufreq_ondemand.o:drivers/cpufreq/cpufreq_ondemand.c:62: 
first defined here
> 
> Caused by commit f935195b8a341d7ffdf600dd98a657f2f09b7908 ("[CPUFREQ]
> ondemand/conservative: sanitize sampling_rate restrictions").
> 
> I have reverted that commit for today.

Dave, I have found another minor issue and will send you three patches.
Two cleanups and the third fixing this one as on top patch.

Decide yourself what way is best to add things (revert and re-add or
just add the three I post).
The problem of the on top approach could be that if this is merged
to linux next you could have a non-building condition if you compile in
conservative + ondemand when bisecting.

    Thomas

Re: linux-next: cpufreq tree build failure

[Dave Jones]

On Thu, Feb 05, 2009 at 10:47:56AM +0100, Thomas Renninger wrote:
 > On Thursday 05 February 2009 08:54:20 Stephen Rothwell wrote:
 > > Hi Dave,
 > > 
 > > Today's linux-next build (powerpc allyesconfig) failed like this:
 > > 
 > > drivers/cpufreq/cpufreq_conservative.o: In function `minimum_sampling_rate':
 > > (.opd+0x30): multiple definition of `minimum_sampling_rate'
 > > drivers/cpufreq/cpufreq_ondemand.o:(.opd+0x18): first defined here
 > > drivers/cpufreq/cpufreq_conservative.o: In function `minimum_sampling_rate':
 > > drivers/cpufreq/cpufreq_conservative.c:64: multiple definition of 
 > `.minimum_sampling_rate'
 > > drivers/cpufreq/cpufreq_ondemand.o:drivers/cpufreq/cpufreq_ondemand.c:62: 
 > first defined here
 > > 
 > > Caused by commit f935195b8a341d7ffdf600dd98a657f2f09b7908 ("[CPUFREQ]
 > > ondemand/conservative: sanitize sampling_rate restrictions").
 > > 
 > > I have reverted that commit for today.
 > 
 > Dave, I have found another minor issue and will send you three patches.
 > Two cleanups and the third fixing this one as on top patch.
 > 
 > Decide yourself what way is best to add things (revert and re-add or
 > just add the three I post).
 > The problem of the on top approach could be that if this is merged
 > to linux next you could have a non-building condition if you compile in

I added the 'static's directly to the patches, and regenerated the tree
on kernel.org
For other stuff, unless it's a build-fix, send an incremental diff ?

	Dave

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

Re: linux-next: cpufreq tree build failure

[Thomas Renninger]

On Thursday 05 February 2009 06:45:36 pm Dave Jones wrote:
> On Thu, Feb 05, 2009 at 10:47:56AM +0100, Thomas Renninger wrote:
>  > On Thursday 05 February 2009 08:54:20 Stephen Rothwell wrote:
>  > > Hi Dave,
>  > >
>  > > Today's linux-next build (powerpc allyesconfig) failed like this:
>  > >
>  > > drivers/cpufreq/cpufreq_conservative.o: In function
>  > > `minimum_sampling_rate': (.opd+0x30): multiple definition of
>  > > `minimum_sampling_rate'
>  > > drivers/cpufreq/cpufreq_ondemand.o:(.opd+0x18): first defined here
>  > > drivers/cpufreq/cpufreq_conservative.o: In function
>  > > `minimum_sampling_rate': drivers/cpufreq/cpufreq_conservative.c:64:
>  > > multiple definition of
>  >
>  > `.minimum_sampling_rate'
>  >
>  > > drivers/cpufreq/cpufreq_ondemand.o:drivers/cpufreq/cpufreq_ondemand.c:
>  > >62:
>  >
>  > first defined here
>  >
>  > > Caused by commit f935195b8a341d7ffdf600dd98a657f2f09b7908 ("[CPUFREQ]
>  > > ondemand/conservative: sanitize sampling_rate restrictions").
>  > >
>  > > I have reverted that commit for today.
>  >
>  > Dave, I have found another minor issue and will send you three patches.
>  > Two cleanups and the third fixing this one as on top patch.
>  >
>  > Decide yourself what way is best to add things (revert and re-add or
>  > just add the three I post).
>  > The problem of the on top approach could be that if this is merged
>  > to linux next you could have a non-building condition if you compile in
>
> I added the 'static's directly to the patches, and regenerated the tree
> on kernel.org
> For other stuff, unless it's a build-fix, send an incremental diff ?
Yes, will do so.
But if possible, I'd like to wait for Ingo's
printk_once function popping up in linux-next.
How frequently are linux-next patches pulled back into the cpufreq tree?
Anyway, I am going to look at your tree in a week or two and send
something then. It's only about a cleaned up message in broken BIOS case,
that should not hurt in linux-next for a while.

Thank you both,

    Thomas

Re: linux-next: cpufreq tree build failure

[Dave Jones]

On Thu, Feb 05, 2009 at 09:57:44PM +0100, Thomas Renninger wrote:

 > > I added the 'static's directly to the patches, and regenerated the tree
 > > on kernel.org
 > > For other stuff, unless it's a build-fix, send an incremental diff ?
 > Yes, will do so.
 > But if possible, I'd like to wait for Ingo's
 > printk_once function popping up in linux-next.
 > How frequently are linux-next patches pulled back into the cpufreq tree?

There's no regular schedule. It typically happens if a) they get merged into
Linus tree, and b) I rebase the cpufreq tree (which I try to avoid where possible,
I try to only do it to get around a build failure, or if there's massive
conflicts with something else that got merged).

 > Anyway, I am going to look at your tree in a week or two and send
 > something then. It's only about a cleaned up message in broken BIOS case,
 > that should not hurt in linux-next for a while.

Sounds good to me.

Thanks,

	Dave

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

linux-next: cpufreq tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

Hi Dave,

Today's linux-next build (x86_64 allmodconfig) failed like this:

ERROR: "recalibrate_cpu_khz" [arch/x86/kernel/cpu/cpufreq/p4-clockmod.ko] undefined!

Caused by commit f20b61aa18b99d91c2a08f8863409bb8002d87fb ("[CPUFREQ] p4-clockmod reports wrong frequency").

I have dropped the cpufreq tree for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: cpufreq tree build failure

[Dave Jones]

On Tue, Feb 24, 2009 at 05:21:12PM +1100, Stephen Rothwell wrote:
 > Hi Dave,
 > 
 > Today's linux-next build (x86_64 allmodconfig) failed like this:
 > 
 > ERROR: "recalibrate_cpu_khz" [arch/x86/kernel/cpu/cpufreq/p4-clockmod.ko] undefined!
 > 
 > Caused by commit f20b61aa18b99d91c2a08f8863409bb8002d87fb ("[CPUFREQ] p4-clockmod reports wrong frequency").
 > 
 > I have dropped the cpufreq tree for today.
 
Odd. I fixed that up, as I noticed it when I first merged the diff.

Can you check that your tree has this bit..

diff --git a/arch/x86/include/asm/timer.h b/arch/x86/include/asm/timer.h
index 2bb6a83..4f5c247 100644
--- a/arch/x86/include/asm/timer.h
+++ b/arch/x86/include/asm/timer.h
@@ -11,8 +11,8 @@ unsigned long native_calibrate_tsc(void);
 
 #ifdef CONFIG_X86_32
 extern int timer_ack;
+#endif
 extern int recalibrate_cpu_khz(void);
-#endif /* CONFIG_X86_32 */

It's possible you cloned it just before I rebased it with that fix.

	Dave

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

Re: linux-next: cpufreq tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]

Hi Dave,

On Tue, 24 Feb 2009 11:51:03 -0500 Dave Jones <davej@redhat.com> wrote:
>
> On Tue, Feb 24, 2009 at 05:21:12PM +1100, Stephen Rothwell wrote:
>  > 
>  > Today's linux-next build (x86_64 allmodconfig) failed like this:
>  > 
>  > ERROR: "recalibrate_cpu_khz" [arch/x86/kernel/cpu/cpufreq/p4-clockmod.ko] undefined!
>  > 
>  > Caused by commit f20b61aa18b99d91c2a08f8863409bb8002d87fb ("[CPUFREQ] p4-clockmod reports wrong frequency").
>  > 
>  > I have dropped the cpufreq tree for today.
>  
> Odd. I fixed that up, as I noticed it when I first merged the diff.
> 
> Can you check that your tree has this bit..
> 
> diff --git a/arch/x86/include/asm/timer.h b/arch/x86/include/asm/timer.h
> index 2bb6a83..4f5c247 100644
> --- a/arch/x86/include/asm/timer.h
> +++ b/arch/x86/include/asm/timer.h
> @@ -11,8 +11,8 @@ unsigned long native_calibrate_tsc(void);
>  
>  #ifdef CONFIG_X86_32
>  extern int timer_ack;
> +#endif
>  extern int recalibrate_cpu_khz(void);
> -#endif /* CONFIG_X86_32 */

It does have that bit.  It failed to build again today.

> It's possible you cloned it just before I rebased it with that fix.

There were no updates when I fetched you tree today.

Note that the error points to a modular build problem.  Maybe as
(Matthias-Christian Ott pointed out) this should not even be being built
for x86_64?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: cpufreq tree build failure

[Dave Jones]

On Wed, Feb 25, 2009 at 02:29:55PM +1100, Stephen Rothwell wrote:
 > Hi Dave,
 > 
 > On Tue, 24 Feb 2009 11:51:03 -0500 Dave Jones <davej@redhat.com> wrote:
 > >
 > > On Tue, Feb 24, 2009 at 05:21:12PM +1100, Stephen Rothwell wrote:
 > >  > 
 > >  > Today's linux-next build (x86_64 allmodconfig) failed like this:
 > >  > 
 > >  > ERROR: "recalibrate_cpu_khz" [arch/x86/kernel/cpu/cpufreq/p4-clockmod.ko] undefined!
 > >  > 
 > >  > Caused by commit f20b61aa18b99d91c2a08f8863409bb8002d87fb ("[CPUFREQ] p4-clockmod reports wrong frequency").
 > >  > 
 > >  > I have dropped the cpufreq tree for today.
 > >  
 > > Odd. I fixed that up, as I noticed it when I first merged the diff.
 > > 
 > > Can you check that your tree has this bit..
 > > 
 > > diff --git a/arch/x86/include/asm/timer.h b/arch/x86/include/asm/timer.h
 > > index 2bb6a83..4f5c247 100644
 > > --- a/arch/x86/include/asm/timer.h
 > > +++ b/arch/x86/include/asm/timer.h
 > > @@ -11,8 +11,8 @@ unsigned long native_calibrate_tsc(void);
 > >  
 > >  #ifdef CONFIG_X86_32
 > >  extern int timer_ack;
 > > +#endif
 > >  extern int recalibrate_cpu_khz(void);
 > > -#endif /* CONFIG_X86_32 */
 > 
 > It does have that bit.  It failed to build again today.

oh hell, the function itself is guarded by an ifdef too.
for speed, my checking scripts only do the equivalent of building p4-clockmod.o,
so I missed this.

 > > It's possible you cloned it just before I rebased it with that fix.
 > There were no updates when I fetched you tree today.
 > 
 > Note that the error points to a modular build problem.  Maybe as
 > (Matthias-Christian Ott pointed out) this should not even be being built
 > for x86_64?

There were a bunch of 64bit Xeons made that lacked P-states.
Though using p4-clockmod as a replacement isn't a good idea, but we should
still allow it for thermal protection.
Also some of the Atoms are 64bit capable, but also lack P-states.

I'll nix the ifdefs and regenerate the tree.

thanks

	Dave

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

Re: linux-next: cpufreq tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

Hi Dave,

On Tue, 24 Feb 2009 22:45:04 -0500 Dave Jones <davej@redhat.com> wrote:
>
> There were a bunch of 64bit Xeons made that lacked P-states.
> Though using p4-clockmod as a replacement isn't a good idea, but we should
> still allow it for thermal protection.
> Also some of the Atoms are 64bit capable, but also lack P-states.
> 
> I'll nix the ifdefs and regenerate the tree.

OK, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

linux-next: cpufreq tree build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

Hi Dave,

Today's linux-next build (x86_64 allmodconfig) failed like this:

ERROR: "cpufreq_global_kobject" [drivers/cpufreq/cpufreq_ondemand.ko] undefined!

Caused by commit 35b104d88338e5eddb36c670fea4752f6c10c82f ("[CPUFREQ]
ondemand - Use global sysfs dir for tuning settings").  Presumably
cpufreq_global_kobject needs an EXPORT_SYMBOL.

I have used the cpufreq tree from next-20090731 for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: cpufreq tree build failure

[Thomas Renninger]

On Monday 03 August 2009 04:28:19 am Stephen Rothwell wrote:
> Hi Dave,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> ERROR: "cpufreq_global_kobject" [drivers/cpufreq/cpufreq_ondemand.ko]
> undefined!
>
> Caused by commit 35b104d88338e5eddb36c670fea4752f6c10c82f ("[CPUFREQ]
> ondemand - Use global sysfs dir for tuning settings").  Presumably
> cpufreq_global_kobject needs an EXPORT_SYMBOL.

Yep, that's it. Below is a fix.

Thanks a lot,

     Thomas

---------
CPUFREQ: fix build if ondemand is compiled as module

struct kobject *cpufreq_global_kobject must be exported

CC: Stephen Rothwell <sfr@canb.auug.org.au>
CC: Dave Jones <davej@redhat.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 9bb2c4a..9d9251f 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -778,6 +778,7 @@ define_one_global_ro(scaling_driver);
 define_one_global_rw(scaling_governor);
 
 struct kobject *cpufreq_global_kobject;
+EXPORT_SYMBOL(cpufreq_global_kobject);
 
 #define to_policy(k) container_of(k, struct cpufreq_policy, kobj)
 #define to_attr(a) container_of(a, struct freq_attr, attr)

Re: linux-next: cpufreq tree build failure

[Dave Jones]

On Tue, Aug 04, 2009 at 01:22:14AM +0200, Thomas Renninger wrote:
 > On Monday 03 August 2009 04:28:19 am Stephen Rothwell wrote:
 > > Hi Dave,
 > >
 > > Today's linux-next build (x86_64 allmodconfig) failed like this:
 > >
 > > ERROR: "cpufreq_global_kobject" [drivers/cpufreq/cpufreq_ondemand.ko]
 > > undefined!
 > >
 > > Caused by commit 35b104d88338e5eddb36c670fea4752f6c10c82f ("[CPUFREQ]
 > > ondemand - Use global sysfs dir for tuning settings").  Presumably
 > > cpufreq_global_kobject needs an EXPORT_SYMBOL.
 > 
 > Yep, that's it. Below is a fix.
 > 
 > Thanks a lot,

I'll roll this in with the previous patch, so as not to introduce
a bisect-regression, and rebase the tree. Will push something out
soon.

thanks.

	Dave