linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: cpufreq tree build failure
@ 2009-08-03  2:28 Stephen Rothwell
  2009-08-03 23:22 ` Thomas Renninger
  0 siblings, 1 reply; 17+ messages in thread
From: Stephen Rothwell @ 2009-08-03  2:28 UTC (permalink / raw)
  To: Dave Jones; +Cc: linux-next, linux-kernel, Thomas Renninger

[-- 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 --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: cpufreq tree build failure
  2009-08-03  2:28 linux-next: cpufreq tree build failure Stephen Rothwell
@ 2009-08-03 23:22 ` Thomas Renninger
  2009-08-03 23:44   ` Dave Jones
  0 siblings, 1 reply; 17+ messages in thread
From: Thomas Renninger @ 2009-08-03 23:22 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Dave Jones, linux-next, linux-kernel

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)

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: linux-next: cpufreq tree build failure
  2009-08-03 23:22 ` Thomas Renninger
@ 2009-08-03 23:44   ` Dave Jones
  0 siblings, 0 replies; 17+ messages in thread
From: Dave Jones @ 2009-08-03 23:44 UTC (permalink / raw)
  To: Thomas Renninger; +Cc: Stephen Rothwell, linux-next, linux-kernel

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: cpufreq tree build failure
  2009-02-25  3:45     ` Dave Jones
@ 2009-02-25  4:23       ` Stephen Rothwell
  0 siblings, 0 replies; 17+ messages in thread
From: Stephen Rothwell @ 2009-02-25  4:23 UTC (permalink / raw)
  To: Dave Jones; +Cc: linux-next, Matthias-Christian Ott, Dominik Brodowski

[-- 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 --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: cpufreq tree build failure
  2009-02-25  3:29   ` Stephen Rothwell
@ 2009-02-25  3:45     ` Dave Jones
  2009-02-25  4:23       ` Stephen Rothwell
  0 siblings, 1 reply; 17+ messages in thread
From: Dave Jones @ 2009-02-25  3:45 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, Matthias-Christian Ott, Dominik Brodowski

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: cpufreq tree build failure
  2009-02-24 16:51 ` Dave Jones
@ 2009-02-25  3:29   ` Stephen Rothwell
  2009-02-25  3:45     ` Dave Jones
  0 siblings, 1 reply; 17+ messages in thread
From: Stephen Rothwell @ 2009-02-25  3:29 UTC (permalink / raw)
  To: Dave Jones; +Cc: linux-next, Matthias-Christian Ott, Dominik Brodowski

[-- 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 --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: cpufreq tree build failure
  2009-02-24  6:21 Stephen Rothwell
@ 2009-02-24 16:51 ` Dave Jones
  2009-02-25  3:29   ` Stephen Rothwell
  0 siblings, 1 reply; 17+ messages in thread
From: Dave Jones @ 2009-02-24 16:51 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, Matthias-Christian Ott, Dominik Brodowski

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

^ permalink raw reply related	[flat|nested] 17+ messages in thread

* linux-next: cpufreq tree build failure
@ 2009-02-24  6:21 Stephen Rothwell
  2009-02-24 16:51 ` Dave Jones
  0 siblings, 1 reply; 17+ messages in thread
From: Stephen Rothwell @ 2009-02-24  6:21 UTC (permalink / raw)
  To: Dave Jones; +Cc: linux-next, Matthias-Christian Ott, Dominik Brodowski

[-- 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 --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: cpufreq tree build failure
  2009-02-05 20:57     ` Thomas Renninger
@ 2009-02-05 21:34       ` Dave Jones
  0 siblings, 0 replies; 17+ messages in thread
From: Dave Jones @ 2009-02-05 21:34 UTC (permalink / raw)
  To: Thomas Renninger; +Cc: Stephen Rothwell, linux-next

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: cpufreq tree build failure
  2009-02-05 17:45   ` Dave Jones
@ 2009-02-05 20:57     ` Thomas Renninger
  2009-02-05 21:34       ` Dave Jones
  0 siblings, 1 reply; 17+ messages in thread
From: Thomas Renninger @ 2009-02-05 20:57 UTC (permalink / raw)
  To: Dave Jones; +Cc: Stephen Rothwell, linux-next

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: cpufreq tree build failure
  2009-02-05  9:47 ` Thomas Renninger
@ 2009-02-05 17:45   ` Dave Jones
  2009-02-05 20:57     ` Thomas Renninger
  0 siblings, 1 reply; 17+ messages in thread
From: Dave Jones @ 2009-02-05 17:45 UTC (permalink / raw)
  To: Thomas Renninger; +Cc: Stephen Rothwell, linux-next

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: cpufreq tree build failure
  2009-02-05  7:54 Stephen Rothwell
  2009-02-05  9:33 ` Thomas Renninger
@ 2009-02-05  9:47 ` Thomas Renninger
  2009-02-05 17:45   ` Dave Jones
  1 sibling, 1 reply; 17+ messages in thread
From: Thomas Renninger @ 2009-02-05  9:47 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Dave Jones, linux-next

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: cpufreq tree build failure
  2009-02-05  7:54 Stephen Rothwell
@ 2009-02-05  9:33 ` Thomas Renninger
  2009-02-05  9:47 ` Thomas Renninger
  1 sibling, 0 replies; 17+ messages in thread
From: Thomas Renninger @ 2009-02-05  9:33 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Dave Jones, linux-next

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* linux-next: cpufreq tree build failure
@ 2009-02-05  7:54 Stephen Rothwell
  2009-02-05  9:33 ` Thomas Renninger
  2009-02-05  9:47 ` Thomas Renninger
  0 siblings, 2 replies; 17+ messages in thread
From: Stephen Rothwell @ 2009-02-05  7:54 UTC (permalink / raw)
  To: Dave Jones; +Cc: linux-next, Thomas Renninger

[-- 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 --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: cpufreq tree build failure
  2009-01-20  5:30 ` Dave Jones
@ 2009-01-20  6:23   ` Stephen Rothwell
  0 siblings, 0 replies; 17+ messages in thread
From: Stephen Rothwell @ 2009-01-20  6:23 UTC (permalink / raw)
  To: Dave Jones; +Cc: linux-next

[-- 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 --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: linux-next: cpufreq tree build failure
  2009-01-20  2:50 Stephen Rothwell
@ 2009-01-20  5:30 ` Dave Jones
  2009-01-20  6:23   ` Stephen Rothwell
  0 siblings, 1 reply; 17+ messages in thread
From: Dave Jones @ 2009-01-20  5:30 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* linux-next: cpufreq tree build failure
@ 2009-01-20  2:50 Stephen Rothwell
  2009-01-20  5:30 ` Dave Jones
  0 siblings, 1 reply; 17+ messages in thread
From: Stephen Rothwell @ 2009-01-20  2:50 UTC (permalink / raw)
  To: Dave Jones; +Cc: linux-next

[-- 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 --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2009-08-03 23:44 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-03  2:28 linux-next: cpufreq tree build failure Stephen Rothwell
2009-08-03 23:22 ` Thomas Renninger
2009-08-03 23:44   ` Dave Jones
  -- strict thread matches above, loose matches on Subject: below --
2009-02-24  6:21 Stephen Rothwell
2009-02-24 16:51 ` Dave Jones
2009-02-25  3:29   ` Stephen Rothwell
2009-02-25  3:45     ` Dave Jones
2009-02-25  4:23       ` Stephen Rothwell
2009-02-05  7:54 Stephen Rothwell
2009-02-05  9:33 ` Thomas Renninger
2009-02-05  9:47 ` Thomas Renninger
2009-02-05 17:45   ` Dave Jones
2009-02-05 20:57     ` Thomas Renninger
2009-02-05 21:34       ` Dave Jones
2009-01-20  2:50 Stephen Rothwell
2009-01-20  5:30 ` Dave Jones
2009-01-20  6:23   ` Stephen Rothwell

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).