linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next build failure
@ 2014-01-03 15:58 Mark Salter
  2014-01-03 22:56 ` Andrew Morton
  0 siblings, 1 reply; 96+ messages in thread
From: Mark Salter @ 2014-01-03 15:58 UTC (permalink / raw)
  To: linux-next; +Cc: Andrew Morton, jmarchan

The c6x arch (no MMU) is failing to build in linux-next with:

  kernel/built-in.o:(.fardata+0x3fc): undefined reference to `overcommit_ratio_handler'
  kernel/built-in.o:(.fardata+0x420): undefined reference to `overcommit_kbytes_handler'
  make[1]: *** [vmlinux] Error 1

Looks like this patch adds those functions to mm/mmap.c which
is only used when CONFIG_MMU is defined.

  commit 31bdaf7c8e8a784fd8f889371bdacb24670734c7
  Author: Jerome Marchand <jmarchan@redhat.com>
  Date:   Tue Dec 17 10:45:06 2013 +1100

      mm: add overcommit_kbytes sysctl variable
    

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

* Re: linux-next build failure
  2014-01-03 15:58 linux-next build failure Mark Salter
@ 2014-01-03 22:56 ` Andrew Morton
  2014-01-06 15:21   ` Mark Salter
  0 siblings, 1 reply; 96+ messages in thread
From: Andrew Morton @ 2014-01-03 22:56 UTC (permalink / raw)
  To: Mark Salter; +Cc: linux-next, jmarchan

On Fri, 03 Jan 2014 10:58:49 -0500 Mark Salter <msalter@redhat.com> wrote:

> The c6x arch (no MMU) is failing to build in linux-next with:
> 
>   kernel/built-in.o:(.fardata+0x3fc): undefined reference to `overcommit_ratio_handler'
>   kernel/built-in.o:(.fardata+0x420): undefined reference to `overcommit_kbytes_handler'
>   make[1]: *** [vmlinux] Error 1
> 
> Looks like this patch adds those functions to mm/mmap.c which
> is only used when CONFIG_MMU is defined.
> 
>   commit 31bdaf7c8e8a784fd8f889371bdacb24670734c7
>   Author: Jerome Marchand <jmarchan@redhat.com>
>   Date:   Tue Dec 17 10:45:06 2013 +1100
> 
>       mm: add overcommit_kbytes sysctl variable

Please check whether that linux-next includes
http://ozlabs.org/~akpm/mmotm/broken-out/mm-add-overcommit_kbytes-sysctl-variable-fix-2.patch

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

* Re: linux-next build failure
  2014-01-03 22:56 ` Andrew Morton
@ 2014-01-06 15:21   ` Mark Salter
  0 siblings, 0 replies; 96+ messages in thread
From: Mark Salter @ 2014-01-06 15:21 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, jmarchan

On Fri, 2014-01-03 at 14:56 -0800, Andrew Morton wrote:
> On Fri, 03 Jan 2014 10:58:49 -0500 Mark Salter <msalter@redhat.com> wrote:
> 
> > The c6x arch (no MMU) is failing to build in linux-next with:
> > 
> >   kernel/built-in.o:(.fardata+0x3fc): undefined reference to `overcommit_ratio_handler'
> >   kernel/built-in.o:(.fardata+0x420): undefined reference to `overcommit_kbytes_handler'
> >   make[1]: *** [vmlinux] Error 1
> > 
> > Looks like this patch adds those functions to mm/mmap.c which
> > is only used when CONFIG_MMU is defined.
> > 
> >   commit 31bdaf7c8e8a784fd8f889371bdacb24670734c7
> >   Author: Jerome Marchand <jmarchan@redhat.com>
> >   Date:   Tue Dec 17 10:45:06 2013 +1100
> > 
> >       mm: add overcommit_kbytes sysctl variable
> 
> Please check whether that linux-next includes
> http://ozlabs.org/~akpm/mmotm/broken-out/mm-add-overcommit_kbytes-sysctl-variable-fix-2.patch

It doesn't, but today's does, so the problem went away. Looks
like that patch got delayed a bit because of the holidays.

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

* Re: linux-next build failure
  2014-05-12 13:18 Mark Salter
  2014-05-12 15:47 ` Mark Salter
@ 2014-05-12 17:05 ` Al Viro
  1 sibling, 0 replies; 96+ messages in thread
From: Al Viro @ 2014-05-12 17:05 UTC (permalink / raw)
  To: Mark Salter; +Cc: linux-next

On Mon, May 12, 2014 at 09:18:42AM -0400, Mark Salter wrote:
> I'm seeing a build failure in linux-net for c6x (!CONFIG_MMU):
> 
>   fs/binfmt_elf_fdpic.c: In function ‘elf_fdpic_dump_segments’:
>   fs/binfmt_elf_fdpic.c:1490:17: warning: unused variable ‘addr’ [-Wunused-variable]
>      unsigned long addr;
>                  ^
> This was introduced by this patch:
> 
>   Author: Al Viro <viro@zeniv.linux.org.uk>
>   Date:   Sat Oct 5 18:58:47 2013 -0400
> 
>       convert the rest of binfmt_elf_fdpic to dump_emit()

... in the mainline since 3.13.  What has changed in -next?

We could put ifndef CONFIG_MMU around that declaration, I guess...

PS: Pity that we can't really use -std=gnu99 - use of compound literals
in initializers is too widespread ;-/  The last time I tried to do something
about that, I gave up when I got to __pgprot() users; in principle, we
could switch pgprot_t to a bitwise type and let sparse take care of the
typechecking, but it was too much work to pull off.  Might be worth
trying again someday...

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

* Re: linux-next build failure
  2014-05-12 13:18 Mark Salter
@ 2014-05-12 15:47 ` Mark Salter
  2014-05-12 17:05 ` Al Viro
  1 sibling, 0 replies; 96+ messages in thread
From: Mark Salter @ 2014-05-12 15:47 UTC (permalink / raw)
  To: Alexander Viro; +Cc: linux-next

On Mon, 2014-05-12 at 09:18 -0400, Mark Salter wrote:
> I'm seeing a build failure in linux-net for c6x (!CONFIG_MMU):
> 
>   fs/binfmt_elf_fdpic.c: In function ‘elf_fdpic_dump_segments’:
>   fs/binfmt_elf_fdpic.c:1490:17: warning: unused variable ‘addr’ [-Wunused-variable]
>      unsigned long addr;
>                  ^
> This was introduced by this patch:
> 
>   Author: Al Viro <viro@zeniv.linux.org.uk>
>   Date:   Sat Oct 5 18:58:47 2013 -0400
> 
>       convert the rest of binfmt_elf_fdpic to dump_emit()
> 
> 

Of course, this is just a warning and not an error. My build failed and
the above was at the bottom of the log, but that was only because of the
-j flag. The actual failure was elsewhere.

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

* linux-next build failure
@ 2014-05-12 13:18 Mark Salter
  2014-05-12 15:47 ` Mark Salter
  2014-05-12 17:05 ` Al Viro
  0 siblings, 2 replies; 96+ messages in thread
From: Mark Salter @ 2014-05-12 13:18 UTC (permalink / raw)
  To: Alexander Viro; +Cc: linux-next

I'm seeing a build failure in linux-net for c6x (!CONFIG_MMU):

  fs/binfmt_elf_fdpic.c: In function ‘elf_fdpic_dump_segments’:
  fs/binfmt_elf_fdpic.c:1490:17: warning: unused variable ‘addr’ [-Wunused-variable]
     unsigned long addr;
                 ^
This was introduced by this patch:

  Author: Al Viro <viro@zeniv.linux.org.uk>
  Date:   Sat Oct 5 18:58:47 2013 -0400

      convert the rest of binfmt_elf_fdpic to dump_emit()

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

* linux-next build failure
@ 2013-11-08 16:51 Mark Salter
  0 siblings, 0 replies; 96+ messages in thread
From: Mark Salter @ 2013-11-08 16:51 UTC (permalink / raw)
  To: linux-next; +Cc: linux-kernel, Andrew Morton

I'm seeing a build failure for a no-MMU system:

   mm/built-in.o: In function `__vm_enough_memory':
  (.text+0x1ce70): undefined reference to `vm_commit_limit'
  fs/built-in.o: In function `meminfo_proc_show':
  meminfo.c:(.text+0x6852c): undefined reference to `vm_commit_limit'


This patch added vm_commit_limit() to mm/mmap.c, but no-mmu systems
use mm/nommu.c instead.

commit 50e05119f980037b474043434cb713bf6f859734
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Thu Nov 7 12:01:09 2013 +1100

    mm-factor-commit-limit-calculation-fix
    
    uninline vm_commit_limit()

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

* Re: linux-next build failure
  2013-10-30 20:50   ` Andrew Morton
@ 2013-10-30 23:17     ` Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2013-10-30 23:17 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Mark Salter, linux-next, linux-kernel, ccross

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

Hi Andrew,

On Wed, 30 Oct 2013 13:50:42 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 31 Oct 2013 07:37:00 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > [Jut add Andrew to the cc list]
> > 
> > On Wed, 30 Oct 2013 11:27:45 -0400 Mark Salter <msalter@redhat.com> wrote:
> > >
> > > This patch causes a build failure for no-MMU builds:
> > > 
> > >   commit 41df2957cb010edfa2f9d394d3617da6beeeb660
> > >   Author: Colin Cross <ccross@android.com>
> > >   Date:   Wed Oct 30 11:45:39 2013 +1100
> > > 
> > >       mm: add a field to store names for private anonymous memory
> > >     
> > > The problem is:
> > > 
> > >   kernel/built-in.o: In function `sys_prctl':
> > >   (.text+0x19854): undefined reference to `madvise_set_anon_name'
> > > 
> > > madvise doesn't make sense without an MMU.
> > > 
> > > --Mark
> 
> OK, thanks.  I'll drop
> 
> mm-rearrange-madvise-code-to-allow-for-reuse.patch
> mm-add-a-field-to-store-names-for-private-anonymous-memory.patch
> mm-add-a-field-to-store-names-for-private-anonymous-memory-fix.patch
> mm-add-a-field-to-store-names-for-private-anonymous-memory-fix-fix-2.patch
> 
> for now.  They have other question marks - let's revisit everything
> after 3.13-rc1.

I have removed them from my copy of the mmotm tree ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

* Re: linux-next build failure
  2013-10-30 20:37 ` Stephen Rothwell
@ 2013-10-30 20:50   ` Andrew Morton
  2013-10-30 23:17     ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Andrew Morton @ 2013-10-30 20:50 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Mark Salter, linux-next, linux-kernel, ccross

On Thu, 31 Oct 2013 07:37:00 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> [Jut add Andrew to the cc list]
> 
> On Wed, 30 Oct 2013 11:27:45 -0400 Mark Salter <msalter@redhat.com> wrote:
> >
> > This patch causes a build failure for no-MMU builds:
> > 
> >   commit 41df2957cb010edfa2f9d394d3617da6beeeb660
> >   Author: Colin Cross <ccross@android.com>
> >   Date:   Wed Oct 30 11:45:39 2013 +1100
> > 
> >       mm: add a field to store names for private anonymous memory
> >     
> > The problem is:
> > 
> >   kernel/built-in.o: In function `sys_prctl':
> >   (.text+0x19854): undefined reference to `madvise_set_anon_name'
> > 
> > madvise doesn't make sense without an MMU.
> > 
> > --Mark

OK, thanks.  I'll drop

mm-rearrange-madvise-code-to-allow-for-reuse.patch
mm-add-a-field-to-store-names-for-private-anonymous-memory.patch
mm-add-a-field-to-store-names-for-private-anonymous-memory-fix.patch
mm-add-a-field-to-store-names-for-private-anonymous-memory-fix-fix-2.patch

for now.  They have other question marks - let's revisit everything
after 3.13-rc1.

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

* Re: linux-next build failure
  2013-10-30 15:27 Mark Salter
@ 2013-10-30 20:37 ` Stephen Rothwell
  2013-10-30 20:50   ` Andrew Morton
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2013-10-30 20:37 UTC (permalink / raw)
  To: Mark Salter; +Cc: linux-next, linux-kernel, ccross, Andrew Morton

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

[Jut add Andrew to the cc list]

On Wed, 30 Oct 2013 11:27:45 -0400 Mark Salter <msalter@redhat.com> wrote:
>
> This patch causes a build failure for no-MMU builds:
> 
>   commit 41df2957cb010edfa2f9d394d3617da6beeeb660
>   Author: Colin Cross <ccross@android.com>
>   Date:   Wed Oct 30 11:45:39 2013 +1100
> 
>       mm: add a field to store names for private anonymous memory
>     
> The problem is:
> 
>   kernel/built-in.o: In function `sys_prctl':
>   (.text+0x19854): undefined reference to `madvise_set_anon_name'
> 
> madvise doesn't make sense without an MMU.
> 
> --Mark

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

* linux-next build failure
@ 2013-10-30 15:27 Mark Salter
  2013-10-30 20:37 ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Mark Salter @ 2013-10-30 15:27 UTC (permalink / raw)
  To: linux-next; +Cc: linux-kernel, ccross

This patch causes a build failure for no-MMU builds:

  commit 41df2957cb010edfa2f9d394d3617da6beeeb660
  Author: Colin Cross <ccross@android.com>
  Date:   Wed Oct 30 11:45:39 2013 +1100

      mm: add a field to store names for private anonymous memory
    
The problem is:

  kernel/built-in.o: In function `sys_prctl':
  (.text+0x19854): undefined reference to `madvise_set_anon_name'

madvise doesn't make sense without an MMU.

--Mark

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

* Re: linux-next: build failure
  2011-12-23  6:08   ` Stephen Rothwell
@ 2011-12-30 19:43     ` Carles Pey
  0 siblings, 0 replies; 96+ messages in thread
From: Carles Pey @ 2011-12-30 19:43 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, Rusty Russell

2011/12/23 Stephen Rothwell <sfr@canb.auug.org.au>:
> [Just letting Rusty know]
>
> On Fri, 23 Dec 2011 00:55:00 +0100 Carles Pey <carles.pey@gmail.com> wrote:
>>
>> Hi all,
>>
>> It failed while building today's linux-next commit 4765f871e50f0 on i686:
>>
>> drivers/block/paride/bpck6.c:24: error: expected ‘=’, ‘,’, ‘;’, ‘asm’
>> or ‘__attribute__’ before ‘verbose’
>> drivers/block/paride/bpck6.c: In function ‘bpck6_connect’:
>> drivers/block/paride/bpck6.c:94: error: ‘verbose’ undeclared (first
>> use in this function)
>> drivers/block/paride/bpck6.c:94: error: (Each undeclared identifier is
>> reported only once
>> drivers/block/paride/bpck6.c:94: error: for each function it appears in.)
>> drivers/block/paride/bpck6.c: In function ‘bpck6_disconnect’:
>> drivers/block/paride/bpck6.c:118: error: ‘verbose’ undeclared (first
>> use in this function)
>> drivers/block/paride/bpck6.c: In function ‘bpck6_test_port’:
>> drivers/block/paride/bpck6.c:128: error: ‘verbose’ undeclared (first
>> use in this function)
>> drivers/block/paride/bpck6.c: In function ‘bpck6_probe_unit’:
>> drivers/block/paride/bpck6.c:162: error: ‘verbose’ undeclared (first
>> use in this function)
>> drivers/block/paride/bpck6.c: In function ‘bpck6_init’:
>> drivers/block/paride/bpck6.c:253: error: ‘verbose’ undeclared (first
>> use in this function)
>> drivers/block/paride/bpck6.c: In function ‘__check_verbose’:
>> drivers/block/paride/bpck6.c:266: error: ‘verbose’ undeclared (first
>> use in this function)
>> drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
>> declaration of ‘type name’
>> drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
>> declaration of ‘type name’
>> drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
>> declaration of ‘type name’
>> drivers/block/paride/bpck6.c:266: error: size of array ‘type name’ is negative
>> drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
>> declaration of ‘type name’
>> drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
>> declaration of ‘type name’
>> drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
>> declaration of ‘type name’
>> drivers/block/paride/bpck6.c: At top level:
>> drivers/block/paride/bpck6.c:266: error: ‘verbose’ undeclared here
>> (not in a function)
>> drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
>> declaration of ‘type name’
>> make[2]: *** [drivers/block/paride/bpck6.o] Error 1
>> make[1]: *** [drivers/block/paride] Error 2
>> make: *** [drivers] Error 2
>>
>> Apparently due to the change in commit a367680f90a94
>>
>> Carles
>
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/

I moved the declaration after the includes:

diff --git a/drivers/block/paride/bpck6.c b/drivers/block/paride/bpck6.c
index 16dcfa9..54cc34e 100644
--- a/drivers/block/paride/bpck6.c
+++ b/drivers/block/paride/bpck6.c
@@ -21,7 +21,6 @@


 /* PARAMETERS */
-static bool verbose; /* set this to 1 to see debugging messages and whatnot */

 #define BACKPACK_VERSION "2.0.2"

@@ -37,6 +36,7 @@ static bool verbose; /* set this to 1 to see
debugging messages and whatnot */
 #include "paride.h"


+static bool verbose; /* set this to 1 to see debugging messages and whatnot */

 #define PPCSTRUCT(pi) ((Interface *)(pi->private))


Carles

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

* Re: linux-next: build failure
  2011-12-22 23:55 ` linux-next: " Carles Pey
@ 2011-12-23  6:08   ` Stephen Rothwell
  2011-12-30 19:43     ` Carles Pey
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2011-12-23  6:08 UTC (permalink / raw)
  To: Carles Pey; +Cc: linux-next, Rusty Russell

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

[Just letting Rusty know]

On Fri, 23 Dec 2011 00:55:00 +0100 Carles Pey <carles.pey@gmail.com> wrote:
>
> Hi all,
> 
> It failed while building today's linux-next commit 4765f871e50f0 on i686:
> 
> drivers/block/paride/bpck6.c:24: error: expected ‘=’, ‘,’, ‘;’, ‘asm’
> or ‘__attribute__’ before ‘verbose’
> drivers/block/paride/bpck6.c: In function ‘bpck6_connect’:
> drivers/block/paride/bpck6.c:94: error: ‘verbose’ undeclared (first
> use in this function)
> drivers/block/paride/bpck6.c:94: error: (Each undeclared identifier is
> reported only once
> drivers/block/paride/bpck6.c:94: error: for each function it appears in.)
> drivers/block/paride/bpck6.c: In function ‘bpck6_disconnect’:
> drivers/block/paride/bpck6.c:118: error: ‘verbose’ undeclared (first
> use in this function)
> drivers/block/paride/bpck6.c: In function ‘bpck6_test_port’:
> drivers/block/paride/bpck6.c:128: error: ‘verbose’ undeclared (first
> use in this function)
> drivers/block/paride/bpck6.c: In function ‘bpck6_probe_unit’:
> drivers/block/paride/bpck6.c:162: error: ‘verbose’ undeclared (first
> use in this function)
> drivers/block/paride/bpck6.c: In function ‘bpck6_init’:
> drivers/block/paride/bpck6.c:253: error: ‘verbose’ undeclared (first
> use in this function)
> drivers/block/paride/bpck6.c: In function ‘__check_verbose’:
> drivers/block/paride/bpck6.c:266: error: ‘verbose’ undeclared (first
> use in this function)
> drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
> declaration of ‘type name’
> drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
> declaration of ‘type name’
> drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
> declaration of ‘type name’
> drivers/block/paride/bpck6.c:266: error: size of array ‘type name’ is negative
> drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
> declaration of ‘type name’
> drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
> declaration of ‘type name’
> drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
> declaration of ‘type name’
> drivers/block/paride/bpck6.c: At top level:
> drivers/block/paride/bpck6.c:266: error: ‘verbose’ undeclared here
> (not in a function)
> drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
> declaration of ‘type name’
> make[2]: *** [drivers/block/paride/bpck6.o] Error 1
> make[1]: *** [drivers/block/paride] Error 2
> make: *** [drivers] Error 2
> 
> Apparently due to the change in commit a367680f90a94
> 
> Carles

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

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

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

* linux-next: build failure
       [not found] <CAHfT02u5as-YvAvwznMveNY_FbeDWLbj0NL6O78MRfeLQ5mpsA@mail.gmail.com>
@ 2011-12-22 23:55 ` Carles Pey
  2011-12-23  6:08   ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Carles Pey @ 2011-12-22 23:55 UTC (permalink / raw)
  To: linux-next

Hi all,

It failed while building today's linux-next commit 4765f871e50f0 on i686:

drivers/block/paride/bpck6.c:24: error: expected ‘=’, ‘,’, ‘;’, ‘asm’
or ‘__attribute__’ before ‘verbose’
drivers/block/paride/bpck6.c: In function ‘bpck6_connect’:
drivers/block/paride/bpck6.c:94: error: ‘verbose’ undeclared (first
use in this function)
drivers/block/paride/bpck6.c:94: error: (Each undeclared identifier is
reported only once
drivers/block/paride/bpck6.c:94: error: for each function it appears in.)
drivers/block/paride/bpck6.c: In function ‘bpck6_disconnect’:
drivers/block/paride/bpck6.c:118: error: ‘verbose’ undeclared (first
use in this function)
drivers/block/paride/bpck6.c: In function ‘bpck6_test_port’:
drivers/block/paride/bpck6.c:128: error: ‘verbose’ undeclared (first
use in this function)
drivers/block/paride/bpck6.c: In function ‘bpck6_probe_unit’:
drivers/block/paride/bpck6.c:162: error: ‘verbose’ undeclared (first
use in this function)
drivers/block/paride/bpck6.c: In function ‘bpck6_init’:
drivers/block/paride/bpck6.c:253: error: ‘verbose’ undeclared (first
use in this function)
drivers/block/paride/bpck6.c: In function ‘__check_verbose’:
drivers/block/paride/bpck6.c:266: error: ‘verbose’ undeclared (first
use in this function)
drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
declaration of ‘type name’
drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
declaration of ‘type name’
drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
declaration of ‘type name’
drivers/block/paride/bpck6.c:266: error: size of array ‘type name’ is negative
drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
declaration of ‘type name’
drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
declaration of ‘type name’
drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
declaration of ‘type name’
drivers/block/paride/bpck6.c: At top level:
drivers/block/paride/bpck6.c:266: error: ‘verbose’ undeclared here
(not in a function)
drivers/block/paride/bpck6.c:266: warning: type defaults to ‘int’ in
declaration of ‘type name’
make[2]: *** [drivers/block/paride/bpck6.o] Error 1
make[1]: *** [drivers/block/paride] Error 2
make: *** [drivers] Error 2

Apparently due to the change in commit a367680f90a94

Carles

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

* Re: linux-next: build failure
  2009-04-08  4:04 Stephen Rothwell
@ 2009-04-08  5:12 ` Alan Modra
  0 siblings, 0 replies; 96+ messages in thread
From: Alan Modra @ 2009-04-08  5:12 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, Paul Mackerras, linuxppc-dev

On Wed, Apr 08, 2009 at 02:04:07PM +1000, Stephen Rothwell wrote:
>   LD      vmlinux.o
> powerpc-linux-ld: TOC section size exceeds 64k

I'm starting to sound like a cracked record, but I'll say it again:
ld -r does not merely package together object files, it transforms
them.   Try using thin archives instead.

-- 
Alan Modra
Australia Development Lab, IBM

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

* linux-next: build failure
@ 2009-04-08  4:04 Stephen Rothwell
  2009-04-08  5:12 ` Alan Modra
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2009-04-08  4:04 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: linux-next, linuxppc-dev, amodra

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

Hi all,

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

  LD      vmlinux.o
powerpc-linux-ld: TOC section size exceeds 64k

I will think about (and appreciate suggestions on) how to fix this ...
-- 
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] 96+ messages in thread

* Re: linux-next: build failure
  2009-02-02  9:02 Stephen Rothwell
  2009-02-02 19:43 ` Yinghai Lu
@ 2009-02-03  6:14 ` David Miller
  1 sibling, 0 replies; 96+ messages in thread
From: David Miller @ 2009-02-03  6:14 UTC (permalink / raw)
  To: sfr; +Cc: mingo, linux-next, yinghai

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 2 Feb 2009 20:02:54 +1100

> sparc: fixup for sparseirq changes
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Applied, thanks Stephen.

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

* Re: linux-next: build failure
  2009-02-02  9:02 Stephen Rothwell
@ 2009-02-02 19:43 ` Yinghai Lu
  2009-02-03  6:14 ` David Miller
  1 sibling, 0 replies; 96+ messages in thread
From: Yinghai Lu @ 2009-02-02 19:43 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: David S. Miller, Ingo Molnar, linux-next

Stephen Rothwell wrote:
> Hi Dave, Ingo,
> 
> Today's linux-next build (sparc64 defconfig) failed like this:
> 
> arch/sparc/kernel/nmi.c: In function 'perfctr_irq':
> arch/sparc/kernel/nmi.c:97: error: 'struct kernel_stat' has no member named 'irqs'
> 
> Probably caused by commit e5553a6d04421eec326a629571d696e8e745a0e4
> ("sparc64: Implement NMI watchdog on capable cpus") from the
> sparc-current tree interacting with commit
> d7e51e66899f95dabc89b4d4c6674a6e50fa37fc ("sparseirq: make some func to
> be used with genirq") from the sparseirq tree.
> 
> I have temporarily applied the patch below.  I don't know if it is
> correct (but it fixes the build).  If it is, it should be applicable to
> the sparc-current tree as the needed interface exists in Linus' current
> tree.

that is right fix.

YH

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

* linux-next: build failure
@ 2009-02-02  9:02 Stephen Rothwell
  2009-02-02 19:43 ` Yinghai Lu
  2009-02-03  6:14 ` David Miller
  0 siblings, 2 replies; 96+ messages in thread
From: Stephen Rothwell @ 2009-02-02  9:02 UTC (permalink / raw)
  To: David S. Miller, Ingo Molnar; +Cc: linux-next, Yinghai Lu

Hi Dave, Ingo,

Today's linux-next build (sparc64 defconfig) failed like this:

arch/sparc/kernel/nmi.c: In function 'perfctr_irq':
arch/sparc/kernel/nmi.c:97: error: 'struct kernel_stat' has no member named 'irqs'

Probably caused by commit e5553a6d04421eec326a629571d696e8e745a0e4
("sparc64: Implement NMI watchdog on capable cpus") from the
sparc-current tree interacting with commit
d7e51e66899f95dabc89b4d4c6674a6e50fa37fc ("sparseirq: make some func to
be used with genirq") from the sparseirq tree.

I have temporarily applied the patch below.  I don't know if it is
correct (but it fixes the build).  If it is, it should be applicable to
the sparc-current tree as the needed interface exists in Linus' current
tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 2 Feb 2009 20:00:15 +1100
Subject: [PATCH] sparc: fixup for sparseirq changes

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/sparc/kernel/nmi.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/sparc/kernel/nmi.c b/arch/sparc/kernel/nmi.c
index ffc6900..09f088e 100644
--- a/arch/sparc/kernel/nmi.c
+++ b/arch/sparc/kernel/nmi.c
@@ -94,7 +94,7 @@ notrace __kprobes void perfctr_irq(int irq, struct pt_regs *regs)
 		       pt_regs_trap_type(regs), SIGINT) == NOTIFY_STOP)
 		touched = 1;
 
-	sum = kstat_cpu(cpu).irqs[0];
+	sum = kstat_irqs_cpu(0, cpu);
 	if (__get_cpu_var(nmi_touch)) {
 		__get_cpu_var(nmi_touch) = 0;
 		touched = 1;
-- 
1.6.0.5

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

* Re: linux-next: build failure
  2009-01-08  5:20 Stephen Rothwell
@ 2009-01-08  5:42 ` David Miller
  0 siblings, 0 replies; 96+ messages in thread
From: David Miller @ 2009-01-08  5:42 UTC (permalink / raw)
  To: sfr; +Cc: linux-next

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 8 Jan 2009 16:20:07 +1100

> Today's linux-next build (sparc64 defconfig) failed like this:
> 
> drivers/base/topology.c: In function 'show_physical_package_id':
> drivers/base/topology.c:103: error: implicit declaration of function 'cpu_data'
> drivers/base/topology.c:103: error: request for member 'proc_id' in something not a structure or union
> drivers/base/topology.c: In function 'show_core_id':
> drivers/base/topology.c:106: error: request for member 'core_id' in something not a structure or union
> 
> I cherry-picked the fix out of Linus' tree.

Ok :-)

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

* linux-next: build failure
@ 2009-01-08  5:20 Stephen Rothwell
  2009-01-08  5:42 ` David Miller
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2009-01-08  5:20 UTC (permalink / raw)
  To: David S. Miller; +Cc: linux-next

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

Hi Dave,

Today's linux-next build (sparc64 defconfig) failed like this:

drivers/base/topology.c: In function 'show_physical_package_id':
drivers/base/topology.c:103: error: implicit declaration of function 'cpu_data'
drivers/base/topology.c:103: error: request for member 'proc_id' in something not a structure or union
drivers/base/topology.c: In function 'show_core_id':
drivers/base/topology.c:106: error: request for member 'core_id' in something not a structure or union

I cherry-picked the fix out of Linus' tree.
-- 
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] 96+ messages in thread

* Re: linux-next: build failure
  2008-12-09  7:34 Stephen Rothwell
@ 2008-12-09 21:05 ` Jesse Barnes
  0 siblings, 0 replies; 96+ messages in thread
From: Jesse Barnes @ 2008-12-09 21:05 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Dave Airlie, linux-next, Eric Anholt, Venki Pallipadi

On Monday, December 08, 2008 11:34 pm Stephen Rothwell wrote:
> Hi Dave,
>
> Today's linux-next build (powerpc allyesconfig) failed like this:
>
> drivers/gpu/drm/drm_gem.c: In function 'drm_gem_mmap':
> drivers/gpu/drm/drm_gem.c:519: error: '_PAGE_CACHE_WC' undeclared (first
> use in this function)
>
> Caused by commit 33b801854540a4f5205c0b2b4b91987e7f21af08 ("drm: GEM mmap
> support").  I tried to revert just that commit, but it lead me down a
> road of dependent commits, so I have reverted the whole drm tree for
> today.
>
> _PAGE_CACHE_WC appears to be defined only for x86 and, before the above
> commit, was not used outside arch/x86.

We might be able to use the new pgprot_writecombine function, but I think 
that's only in an x86 branch atm...  And it doesn't look like it's properly 
stubbed out on non-x86, which means more #ifdefs.

-- 
Jesse Barnes, Intel Open Source Technology Center

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

* linux-next: build failure
@ 2008-12-09  7:34 Stephen Rothwell
  2008-12-09 21:05 ` Jesse Barnes
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2008-12-09  7:34 UTC (permalink / raw)
  To: Dave Airlie; +Cc: linux-next, Jesse Barnes, Eric Anholt

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

Hi Dave,

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

drivers/gpu/drm/drm_gem.c: In function 'drm_gem_mmap':
drivers/gpu/drm/drm_gem.c:519: error: '_PAGE_CACHE_WC' undeclared (first use in this function)

Caused by commit 33b801854540a4f5205c0b2b4b91987e7f21af08 ("drm: GEM mmap
support").  I tried to revert just that commit, but it lead me down a
road of dependent commits, so I have reverted the whole drm tree for
today.

_PAGE_CACHE_WC appears to be defined only for x86 and, before the above
commit, was not used outside arch/x86.

-- 
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] 96+ messages in thread

* Re: linux-next: build failure
  2008-11-11  8:10 Stephen Rothwell
  2008-11-11  8:15 ` Sujith
@ 2008-11-11  9:18 ` David Miller
  1 sibling, 0 replies; 96+ messages in thread
From: David Miller @ 2008-11-11  9:18 UTC (permalink / raw)
  To: sfr; +Cc: linville, linux-next, Sujith.Manoharan

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 11 Nov 2008 19:10:42 +1100

> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> drivers/net/wireless/ath9k/main.c: At top level:
> drivers/net/wireless/ath9k/main.c:827: warning: conflicting types for 'ath_detach'
> drivers/net/wireless/ath9k/main.c:827: error: static declaration of 'ath_detach' follows non-static declaration
> drivers/net/wireless/ath9k/main.c:812: error: previous implicit declaration of 'ath_detach' was here

It only passed my allmodconfig tests on sparc64 because this code is
guarded by "CONFIG_RFKILL" but not "CONFIG_RFKILL_MODULE".

I wonder how many times that kind of error exists (checking FOO but
not FOO_MODULE) in the tree :-/

In any event, John please get me a fix for this at your next
opportunity.

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

* linux-next: build failure
  2008-11-11  8:10 Stephen Rothwell
@ 2008-11-11  8:15 ` Sujith
  2008-11-11  9:18 ` David Miller
  1 sibling, 0 replies; 96+ messages in thread
From: Sujith @ 2008-11-11  8:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: John W. Linville, linux-next, Sujith Manoharan, David S. Miller

Stephen Rothwell wrote:
> Hi John, Dave,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> drivers/net/wireless/ath9k/main.c: At top level:
> drivers/net/wireless/ath9k/main.c:827: warning: conflicting types for 'ath_detach'
> drivers/net/wireless/ath9k/main.c:827: error: static declaration of 'ath_detach' follows non-static declaration
> drivers/net/wireless/ath9k/main.c:812: error: previous implicit declaration of 'ath_detach' was here
> 
> Caused by commit 9c84b7978f1b99048bf31be5a0218cd509e74148 ("ath9k:
> Streamline attach/detach") (from the wireless/net tree) which added a
> call to the static function before it was defined.
> 
> I added the patch below, which then lead to:
> 
> drivers/net/wireless/ath9k/main.c: In function 'ath_start_rfkill_poll':
> drivers/net/wireless/ath9k/main.c:818: error: 'hw' undeclared (first use in this function)
> 
> So I gave up and reverted the wireless tree for today (I actually
> reverted the merge of the wireless tree into the net tree).

A patch was already posted to fix this:
http://marc.info/?l=linux-wireless&m=122580350232179&w=2

Sujith

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

* linux-next: build failure
@ 2008-11-11  8:10 Stephen Rothwell
  2008-11-11  8:15 ` Sujith
  2008-11-11  9:18 ` David Miller
  0 siblings, 2 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-11-11  8:10 UTC (permalink / raw)
  To: John W. Linville; +Cc: linux-next, Sujith, David S. Miller

Hi John, Dave,

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

drivers/net/wireless/ath9k/main.c: At top level:
drivers/net/wireless/ath9k/main.c:827: warning: conflicting types for 'ath_detach'
drivers/net/wireless/ath9k/main.c:827: error: static declaration of 'ath_detach' follows non-static declaration
drivers/net/wireless/ath9k/main.c:812: error: previous implicit declaration of 'ath_detach' was here

Caused by commit 9c84b7978f1b99048bf31be5a0218cd509e74148 ("ath9k:
Streamline attach/detach") (from the wireless/net tree) which added a
call to the static function before it was defined.

I added the patch below, which then lead to:

drivers/net/wireless/ath9k/main.c: In function 'ath_start_rfkill_poll':
drivers/net/wireless/ath9k/main.c:818: error: 'hw' undeclared (first use in this function)

So I gave up and reverted the wireless tree for today (I actually
reverted the merge of the wireless tree into the net tree).

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

diff --git a/drivers/net/wireless/ath9k/main.c b/drivers/net/wireless/ath9k/main.c
index fb50aa0..dc66fb7 100644
--- a/drivers/net/wireless/ath9k/main.c
+++ b/drivers/net/wireless/ath9k/main.c
@@ -28,6 +28,8 @@ MODULE_DESCRIPTION("Support for Atheros 802.11n wireless LAN cards.");
 MODULE_SUPPORTED_DEVICE("Atheros 802.11n WLAN cards");
 MODULE_LICENSE("Dual BSD/GPL");
 
+static void ath_detach(struct ath_softc *sc);
+
 static struct pci_device_id ath_pci_id_table[] __devinitdata = {
 	{ PCI_VDEVICE(ATHEROS, 0x0023) }, /* PCI   */
 	{ PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
-- 
1.5.6.5

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

* Re: linux-next: build failure
  2008-11-07 22:54   ` Stephen Rothwell
@ 2008-11-09 15:50     ` Avi Kivity
  0 siblings, 0 replies; 96+ messages in thread
From: Avi Kivity @ 2008-11-09 15:50 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Hollis Blanchard, Avi Kivity, linux-next, Josh Boyer

Stephen Rothwell wrote:
> Hi Hollis,
>
> On Fri, 07 Nov 2008 10:40:05 -0600 Hollis Blanchard <hollisb@us.ibm.com> wrote:
>   
>> Hi Stephen, it looks like Josh accidentally set the following options in
>> ppc44x_defconfig:
>> +CONFIG_VIRTUALIZATION=y
>> +CONFIG_KVM=y
>> +CONFIG_KVM_BOOKE_HOST=y
>>
>> http://git.kernel.org/?p=linux/kernel/git/jwboyer/powerpc-4xx.git;a=commitdiff;h=8531b7a805833649591fa324cadbab7d6b667f4b
>>
>> Since then, CONFIG_KVM_BOOKE_HOST was renamed to CONFIG_KVM_440.
>> Unfortunately I don't have the right Kconfig constraint in place to
>> catch that, leading to this problem. I will submit a patch for this
>> today.
>>     
>
> OK, thanks.
>   

I've merged and pushed this patch, so this should be fixed.

-- 
error compiling committee.c: too many arguments to function

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

* Re: linux-next: build failure
  2008-11-07 16:40 ` Hollis Blanchard
  2008-11-07 17:05   ` Josh Boyer
@ 2008-11-07 22:54   ` Stephen Rothwell
  2008-11-09 15:50     ` Avi Kivity
  1 sibling, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2008-11-07 22:54 UTC (permalink / raw)
  To: Hollis Blanchard; +Cc: Avi Kivity, linux-next, Josh Boyer

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

Hi Hollis,

On Fri, 07 Nov 2008 10:40:05 -0600 Hollis Blanchard <hollisb@us.ibm.com> wrote:
>
> Hi Stephen, it looks like Josh accidentally set the following options in
> ppc44x_defconfig:
> +CONFIG_VIRTUALIZATION=y
> +CONFIG_KVM=y
> +CONFIG_KVM_BOOKE_HOST=y
> 
> http://git.kernel.org/?p=linux/kernel/git/jwboyer/powerpc-4xx.git;a=commitdiff;h=8531b7a805833649591fa324cadbab7d6b667f4b
> 
> Since then, CONFIG_KVM_BOOKE_HOST was renamed to CONFIG_KVM_440.
> Unfortunately I don't have the right Kconfig constraint in place to
> catch that, leading to this problem. I will submit a patch for this
> today.

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] 96+ messages in thread

* Re: linux-next: build failure
  2008-11-07 17:34       ` Josh Boyer
@ 2008-11-07 21:18         ` Hollis Blanchard
  0 siblings, 0 replies; 96+ messages in thread
From: Hollis Blanchard @ 2008-11-07 21:18 UTC (permalink / raw)
  To: Josh Boyer; +Cc: Stephen Rothwell, Avi Kivity, linux-next

On Fri, 2008-11-07 at 12:34 -0500, Josh Boyer wrote:
> On Fri, 07 Nov 2008 11:24:26 -0600
> Hollis Blanchard <hollisb@us.ibm.com> wrote:
> 
> > I'm not sure if there's precedent for features marked EXPERIMENTAL to be
> > in the defconfig, but simply put I have not done a thorough audit of the
> > KVM 440 code for security or DoS issues. (For example, until yesterday,
> > the guest could trivially flood the host console because I'd left a
> > printk enabled.) It just seems like asking for trouble to enable it in
> > the defconfig.
> 
> If you think it's really in rough enough shape that it's a concern for
> .28, then I can change it back.  Let me know soon.

Well, I'm happy to have the (build) test coverage...

Since KVM can only be invoked via /dev/kvm, and that device node (if
automatically created) only has root permissions, I think it will be OK.

> > That said, I have no complaint about having it enabled for linux-next
> > builds.
> 
> I don't have a separate defconfig for linux-next builds.  We could do
> that but I don't see much value.  I want -next to be building (and
> theoretically testing) what gets built for actual release kernels.

Fair enough.

-- 
Hollis Blanchard
IBM Linux Technology Center

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

* Re: linux-next: build failure
  2008-11-07 17:24     ` Hollis Blanchard
@ 2008-11-07 17:34       ` Josh Boyer
  2008-11-07 21:18         ` Hollis Blanchard
  0 siblings, 1 reply; 96+ messages in thread
From: Josh Boyer @ 2008-11-07 17:34 UTC (permalink / raw)
  To: Hollis Blanchard; +Cc: Stephen Rothwell, Avi Kivity, linux-next

On Fri, 07 Nov 2008 11:24:26 -0600
Hollis Blanchard <hollisb@us.ibm.com> wrote:

> On Fri, 2008-11-07 at 12:05 -0500, Josh Boyer wrote:
> > On Fri, 07 Nov 2008 10:40:05 -0600
> > Hollis Blanchard <hollisb@us.ibm.com> wrote:
> > > 
> > > Hi Stephen, it looks like Josh accidentally set the following options in
> > > ppc44x_defconfig:
> > > +CONFIG_VIRTUALIZATION=y
> > > +CONFIG_KVM=y
> > > +CONFIG_KVM_BOOKE_HOST=y
> > 
> > That wasn't an accident.  I set them based on -rc2 Kconfig values, and
> > enabled it for better build coverage.  Seems it worked. 
> 
> But when you asked me if I thought it was a good idea to enable KVM in
> ppc44x defconfig, I said "no"...

Hm.  I recall you saying "no", and then we had more discussion and
apparently I took that to mean "maybe."

> I'm not sure if there's precedent for features marked EXPERIMENTAL to be
> in the defconfig, but simply put I have not done a thorough audit of the
> KVM 440 code for security or DoS issues. (For example, until yesterday,
> the guest could trivially flood the host console because I'd left a
> printk enabled.) It just seems like asking for trouble to enable it in
> the defconfig.

If you think it's really in rough enough shape that it's a concern for
.28, then I can change it back.  Let me know soon.

EXPERIMENTAL means very little these days because it's used everywhere
and gets forgotten about down the road.  That's more a comment on the
uselessness of EXPERIMENTAL rather than your code, but that's the state
we're at today.  Marking it BROKEN would have prevented me from
enabling it for sure (maybe).

> That said, I have no complaint about having it enabled for linux-next
> builds.

I don't have a separate defconfig for linux-next builds.  We could do
that but I don't see much value.  I want -next to be building (and
theoretically testing) what gets built for actual release kernels.

josh

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

* Re: linux-next: build failure
  2008-11-07 17:05   ` Josh Boyer
@ 2008-11-07 17:24     ` Hollis Blanchard
  2008-11-07 17:34       ` Josh Boyer
  0 siblings, 1 reply; 96+ messages in thread
From: Hollis Blanchard @ 2008-11-07 17:24 UTC (permalink / raw)
  To: Josh Boyer; +Cc: Stephen Rothwell, Avi Kivity, linux-next

On Fri, 2008-11-07 at 12:05 -0500, Josh Boyer wrote:
> On Fri, 07 Nov 2008 10:40:05 -0600
> Hollis Blanchard <hollisb@us.ibm.com> wrote:
> > 
> > Hi Stephen, it looks like Josh accidentally set the following options in
> > ppc44x_defconfig:
> > +CONFIG_VIRTUALIZATION=y
> > +CONFIG_KVM=y
> > +CONFIG_KVM_BOOKE_HOST=y
> 
> That wasn't an accident.  I set them based on -rc2 Kconfig values, and
> enabled it for better build coverage.  Seems it worked. 

But when you asked me if I thought it was a good idea to enable KVM in
ppc44x defconfig, I said "no"...

I'm not sure if there's precedent for features marked EXPERIMENTAL to be
in the defconfig, but simply put I have not done a thorough audit of the
KVM 440 code for security or DoS issues. (For example, until yesterday,
the guest could trivially flood the host console because I'd left a
printk enabled.) It just seems like asking for trouble to enable it in
the defconfig.

That said, I have no complaint about having it enabled for linux-next
builds.

-- 
Hollis Blanchard
IBM Linux Technology Center

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

* Re: linux-next: build failure
  2008-11-07 16:40 ` Hollis Blanchard
@ 2008-11-07 17:05   ` Josh Boyer
  2008-11-07 17:24     ` Hollis Blanchard
  2008-11-07 22:54   ` Stephen Rothwell
  1 sibling, 1 reply; 96+ messages in thread
From: Josh Boyer @ 2008-11-07 17:05 UTC (permalink / raw)
  To: Hollis Blanchard; +Cc: Stephen Rothwell, Avi Kivity, linux-next

On Fri, 07 Nov 2008 10:40:05 -0600
Hollis Blanchard <hollisb@us.ibm.com> wrote:

> On Fri, 2008-11-07 at 20:25 +1100, Stephen Rothwell wrote:
> > Hi Avi,
> > 
> > Today's linux-next build (powerpc ppc44x_config) failed like this:
> > 
> > arch/powerpc/kvm/built-in.o: In function `kvm_vcpu_ioctl':
> > kvm_main.c:(.text+0x890): undefined reference to `kvm_arch_vcpu_ioctl_get_sregs'
> [...]
> 
> > I have reverted the merge of the kvm tree for today.
> 
> Hi Stephen, it looks like Josh accidentally set the following options in
> ppc44x_defconfig:
> +CONFIG_VIRTUALIZATION=y
> +CONFIG_KVM=y
> +CONFIG_KVM_BOOKE_HOST=y

That wasn't an accident.  I set them based on -rc2 Kconfig values, and
enabled it for better build coverage.  Seems it worked. 

> 
> http://git.kernel.org/?p=linux/kernel/git/jwboyer/powerpc-4xx.git;a=commitdiff;h=8531b7a805833649591fa324cadbab7d6b667f4b
> 
> Since then, CONFIG_KVM_BOOKE_HOST was renamed to CONFIG_KVM_440.
> Unfortunately I don't have the right Kconfig constraint in place to
> catch that, leading to this problem. I will submit a patch for this
> today.

Thanks.

josh

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

* Re: linux-next: build failure
  2008-11-07  9:25 Stephen Rothwell
@ 2008-11-07 16:40 ` Hollis Blanchard
  2008-11-07 17:05   ` Josh Boyer
  2008-11-07 22:54   ` Stephen Rothwell
  0 siblings, 2 replies; 96+ messages in thread
From: Hollis Blanchard @ 2008-11-07 16:40 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Avi Kivity, linux-next, Josh Boyer

On Fri, 2008-11-07 at 20:25 +1100, Stephen Rothwell wrote:
> Hi Avi,
> 
> Today's linux-next build (powerpc ppc44x_config) failed like this:
> 
> arch/powerpc/kvm/built-in.o: In function `kvm_vcpu_ioctl':
> kvm_main.c:(.text+0x890): undefined reference to `kvm_arch_vcpu_ioctl_get_sregs'
[...]

> I have reverted the merge of the kvm tree for today.

Hi Stephen, it looks like Josh accidentally set the following options in
ppc44x_defconfig:
+CONFIG_VIRTUALIZATION=y
+CONFIG_KVM=y
+CONFIG_KVM_BOOKE_HOST=y

http://git.kernel.org/?p=linux/kernel/git/jwboyer/powerpc-4xx.git;a=commitdiff;h=8531b7a805833649591fa324cadbab7d6b667f4b

Since then, CONFIG_KVM_BOOKE_HOST was renamed to CONFIG_KVM_440.
Unfortunately I don't have the right Kconfig constraint in place to
catch that, leading to this problem. I will submit a patch for this
today.

-- 
Hollis Blanchard
IBM Linux Technology Center

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

* linux-next: build failure
@ 2008-11-07  9:25 Stephen Rothwell
  2008-11-07 16:40 ` Hollis Blanchard
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2008-11-07  9:25 UTC (permalink / raw)
  To: Avi Kivity; +Cc: linux-next, Hollis Blanchard

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

Hi Avi,

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

arch/powerpc/kvm/built-in.o: In function `kvm_vcpu_ioctl':
kvm_main.c:(.text+0x890): undefined reference to `kvm_arch_vcpu_ioctl_get_sregs'
kvm_main.c:(.text+0xa84): undefined reference to `kvm_arch_vcpu_ioctl_set_fpu'
kvm_main.c:(.text+0xadc): undefined reference to `kvm_arch_vcpu_ioctl_get_regs'
kvm_main.c:(.text+0xb58): undefined reference to `kvm_arch_vcpu_ioctl_get_fpu'
kvm_main.c:(.text+0xc48): undefined reference to `kvm_arch_vcpu_ioctl_translate'
kvm_main.c:(.text+0xd7c): undefined reference to `kvm_arch_vcpu_ioctl_set_regs'
kvm_main.c:(.text+0xdbc): undefined reference to `kvm_arch_vcpu_ioctl_set_sregs'
arch/powerpc/kvm/built-in.o: In function `kvm_exit':
(.text+0x117e): undefined reference to `debugfs_entries'
arch/powerpc/kvm/built-in.o: In function `kvm_exit':
(.text+0x1182): undefined reference to `debugfs_entries'
arch/powerpc/kvm/built-in.o: In function `kvm_exit':
(.text+0x1186): undefined reference to `debugfs_entries'
arch/powerpc/kvm/built-in.o: In function `kvm_init':
(.text+0x13ce): undefined reference to `debugfs_entries'
arch/powerpc/kvm/built-in.o: In function `kvm_init':
(.text+0x13da): undefined reference to `debugfs_entries'
arch/powerpc/kvm/built-in.o:(.text+0x13de): more undefined references to `debugfs_entries' follow
arch/powerpc/kvm/built-in.o: In function `kvm_vm_ioctl':
kvm_main.c:(.text+0x2d20): undefined reference to `kvm_arch_vcpu_setup'
arch/powerpc/kvm/built-in.o: In function `kvm_vcpu_ioctl_interrupt':
(.text+0x38b4): undefined reference to `kvmppc_core_queue_external'
arch/powerpc/kvm/built-in.o: In function `kvm_arch_vcpu_ioctl_run':
(.text+0x3a0c): undefined reference to `kvmppc_core_deliver_interrupts'
arch/powerpc/kvm/built-in.o: In function `kvm_arch_vcpu_ioctl_run':
(.text+0x3a28): undefined reference to `__kvmppc_vcpu_run'
arch/powerpc/kvm/built-in.o: In function `kvm_arch_vcpu_put':
(.text+0x3de0): undefined reference to `kvmppc_core_load_host_debugstate'
arch/powerpc/kvm/built-in.o: In function `kvm_arch_vcpu_put':
(.text+0x3de8): undefined reference to `kvmppc_core_vcpu_put'
arch/powerpc/kvm/built-in.o: In function `kvm_arch_vcpu_load':
(.text+0x3e24): undefined reference to `kvmppc_core_load_guest_debugstate'
arch/powerpc/kvm/built-in.o: In function `kvm_arch_vcpu_load':
(.text+0x3e30): undefined reference to `kvmppc_core_vcpu_load'
arch/powerpc/kvm/built-in.o: In function `kvmppc_decrementer_func':
powerpc.c:(.text+0x3ea4): undefined reference to `kvmppc_core_queue_dec'
arch/powerpc/kvm/built-in.o: In function `kvm_cpu_has_pending_timer':
(.text+0x3efc): undefined reference to `kvmppc_core_pending_dec'
arch/powerpc/kvm/built-in.o: In function `kvm_arch_vcpu_free':
(.text+0x3f1c): undefined reference to `kvmppc_core_vcpu_free'
arch/powerpc/kvm/built-in.o: In function `kvm_arch_vcpu_destroy':
(.text+0x3f3c): undefined reference to `kvmppc_core_vcpu_free'
arch/powerpc/kvm/built-in.o: In function `kvm_arch_vcpu_create':
(.text+0x3f5c): undefined reference to `kvmppc_core_vcpu_create'
arch/powerpc/kvm/built-in.o: In function `kvm_arch_destroy_vm':
(.text+0x3f90): undefined reference to `kvmppc_core_vcpu_free'
arch/powerpc/kvm/built-in.o: In function `kvm_arch_check_processor_compat':
(.text+0x4034): undefined reference to `kvmppc_core_check_processor_compat'
arch/powerpc/kvm/built-in.o: In function `kvmppc_emulate_instruction':
(.text+0x41b4): undefined reference to `kvmppc_core_emulate_op'
arch/powerpc/kvm/built-in.o: In function `kvmppc_emulate_instruction':
(.text+0x4380): undefined reference to `kvmppc_core_queue_program'
arch/powerpc/kvm/built-in.o: In function `kvmppc_emulate_instruction':
(.text+0x45ac): undefined reference to `kvmppc_core_emulate_mtspr'
arch/powerpc/kvm/built-in.o: In function `kvmppc_emulate_instruction':
(.text+0x468c): undefined reference to `kvmppc_core_emulate_mfspr'

I have reverted the merge of the kvm 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] 96+ messages in thread

* linux-next: build failure
@ 2008-10-23  9:51 Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-10-23  9:51 UTC (permalink / raw)
  To: Rusty Russell; +Cc: linux-next, Mike Travis

Hi Rusty,

Today's linux-next build (sparc defconfig) failed like this:

In file included from arch/sparc/include/asm/smp_32.h:15,
                 from arch/sparc/include/asm/smp.h:6,
                 from arch/sparc/include/asm/system_32.h:12,
                 from arch/sparc/include/asm/system.h:6,
                 from include/linux/list.h:7,
                 from include/linux/preempt.h:11,
                 from include/linux/spinlock.h:50,
                 from include/linux/seqlock.h:29,
                 from include/linux/time.h:8,
                 from include/linux/timex.h:57,
                 from include/linux/sched.h:54,
                 from arch/sparc/kernel/asm-offsets.c:13:
include/linux/cpumask.h:110: error: `CONFIG_NR_CPUS' undeclared here (not in a function)

and it went on ...

I applied the following patch.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 23 Oct 2008 20:48:36 +1100
Subject: [PATCH] sparc: fallout from cpumask CONFIG_NR_CPUS changes

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/sparc/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 6b4970e..7b1a000 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -66,7 +66,7 @@ config SMP
 config NR_CPUS
 	int "Maximum number of CPUs (2-32)" if SMP
 	range 2 32 if SMP
-	default "1" if SMP
+	default "1" if !SMP
 	default "32" if SMP
 
 config SPARC
-- 
1.5.6.5

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

* linux-next: build failure
@ 2008-10-23  9:18 Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-10-23  9:18 UTC (permalink / raw)
  To: Rusty Russell; +Cc: linux-next, Mike Travis

Hi Rusty,

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

In file included from include/linux/sched.h:58,
                 from arch/powerpc/kernel/asm-offsets.c:17:
include/linux/cpumask.h:110: error: 'CONFIG_NR_CPUS' undeclared here (not in a function)

Caused by commit d08dde18aebb15633e5c4480814b77d93a4d68f6 ("cpumask:CONFIG_NR_CPUS-always") from the rr tree.  I applied the following patch.

There are several other architectures that don't appear to have been
updated for this change - how confident ae you that none of them have
been broken as powerpc was?
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 23 Oct 2008 20:14:18 +1100
Subject: [PATCH] powerpc: fallout from cpumask CONFIG_NR_CPUS changes

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/platforms/Kconfig.cputype |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 548efa5..e8fd928 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -242,9 +242,9 @@ config SMP
 	  If you don't know what to do here, say N.
 
 config NR_CPUS
-	int "Maximum number of CPUs (2-1024)"
-	range 2 1024
-	depends on SMP
+	int "Maximum number of CPUs (2-1024)" if SMP
+	range 2 1024 if SMP
+	default "1" if !SMP
 	default "32" if PPC64
 	default "4"
 
-- 
1.5.6.5

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

* Re: linux-next: build failure
  2008-10-20 20:47       ` Greg KH
@ 2008-10-20 22:34         ` J.R. Mauro
  0 siblings, 0 replies; 96+ messages in thread
From: J.R. Mauro @ 2008-10-20 22:34 UTC (permalink / raw)
  To: Greg KH
  Cc: Stephen Rothwell, linux-next, Christopher Harrer, Michael Miles,
	LKML, Andrew Morton, linus

On Mon, Oct 20, 2008 at 01:47:50PM -0700, Greg KH wrote:
> On Mon, Oct 20, 2008 at 09:51:42AM -0700, Greg KH wrote:
> > On Mon, Oct 20, 2008 at 12:33:29PM -0400, J.R. Mauro wrote:
> > > On Mon, Oct 20, 2008 at 11:48 AM, Greg KH <greg@kroah.com> wrote:
> > > > On Mon, Oct 20, 2008 at 11:04:20PM +1100, Stephen Rothwell wrote:
> > > >> Hi Greg,
> > > >>
> > > >> Today's linux-next build (powerpc allyesconfig) failed like this:
> > > >>
> > > >> In file included from drivers/staging/sxg/sxg.c:77:
> > > >> drivers/staging/sxg/sxghif.h:859: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Compilation'
> > > >> drivers/staging/sxg/sxg.c: In function 'sxg_transmit_packet':
> > > >> drivers/staging/sxg/sxg.c:1949: error: 'SXG_SGL_BUF_SIZE' undeclared (first use in this function)
> > > >> drivers/staging/sxg/sxg.c:1958: error: implicit declaration of function 'SXG_SGL_BUFFER'
> > > >> drivers/staging/sxg/sxg.c:1958: warning: assignment makes pointer from integer without a cast
> > > >> drivers/staging/sxg/sxg.c: In function 'sxg_mcast_set_mask':
> > > >> drivers/staging/sxg/sxg.c:2846: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
> > > >>
> > > >> I applied the following patch.
> > > >
> > > > Ah, doh, sorry, I should have caught that.  I'll go apply this to the
> > > > tree, thanks.
> > > 
> > > Greg,
> > > 
> > > The slicoss driver also from Alacritech looks like it needs a depends
> > > on X86 as well. Should the sxg and slicoss drivers from Alacritech be
> > > doing things like this (sxg/sxghif.h:851, slicoss/slicoss.c:960):
> > 
> > Yes, it needs it too.
> 
> Hm, it already has this dependancy.  In drivers/staging/slicoss/Kconfig
> we have:
> 	config SLICOSS
> 		tristate "Alacritech Gigabit IS-NIC support"
> 		depends on PCI && X86 && NETDEV_1000
> 
> So we should be fine here.

Sorry about that, had to pull from Linus's tree

> 
> thanks,
> 
> greg k-h

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

* Re: linux-next: build failure
  2008-10-20 15:48 ` Greg KH
  2008-10-20 16:33   ` J.R. Mauro
@ 2008-10-20 22:31   ` Stephen Rothwell
  1 sibling, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-10-20 22:31 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, Christopher Harrer, Michael Miles, LKML,
	Andrew Morton, linus

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

Hi Greg,

On Mon, 20 Oct 2008 08:48:57 -0700 Greg KH <greg@kroah.com> wrote:
>
> Ah, doh, sorry, I should have caught that.  I'll go apply this to the
> tree, thanks.

Linus seems to have already applied it.

-- 
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] 96+ messages in thread

* Re: linux-next: build failure
  2008-10-20 16:51     ` Greg KH
@ 2008-10-20 20:47       ` Greg KH
  2008-10-20 22:34         ` J.R. Mauro
  0 siblings, 1 reply; 96+ messages in thread
From: Greg KH @ 2008-10-20 20:47 UTC (permalink / raw)
  To: J.R. Mauro
  Cc: Stephen Rothwell, linux-next, Christopher Harrer, Michael Miles,
	LKML, Andrew Morton, linus

On Mon, Oct 20, 2008 at 09:51:42AM -0700, Greg KH wrote:
> On Mon, Oct 20, 2008 at 12:33:29PM -0400, J.R. Mauro wrote:
> > On Mon, Oct 20, 2008 at 11:48 AM, Greg KH <greg@kroah.com> wrote:
> > > On Mon, Oct 20, 2008 at 11:04:20PM +1100, Stephen Rothwell wrote:
> > >> Hi Greg,
> > >>
> > >> Today's linux-next build (powerpc allyesconfig) failed like this:
> > >>
> > >> In file included from drivers/staging/sxg/sxg.c:77:
> > >> drivers/staging/sxg/sxghif.h:859: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Compilation'
> > >> drivers/staging/sxg/sxg.c: In function 'sxg_transmit_packet':
> > >> drivers/staging/sxg/sxg.c:1949: error: 'SXG_SGL_BUF_SIZE' undeclared (first use in this function)
> > >> drivers/staging/sxg/sxg.c:1958: error: implicit declaration of function 'SXG_SGL_BUFFER'
> > >> drivers/staging/sxg/sxg.c:1958: warning: assignment makes pointer from integer without a cast
> > >> drivers/staging/sxg/sxg.c: In function 'sxg_mcast_set_mask':
> > >> drivers/staging/sxg/sxg.c:2846: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
> > >>
> > >> I applied the following patch.
> > >
> > > Ah, doh, sorry, I should have caught that.  I'll go apply this to the
> > > tree, thanks.
> > 
> > Greg,
> > 
> > The slicoss driver also from Alacritech looks like it needs a depends
> > on X86 as well. Should the sxg and slicoss drivers from Alacritech be
> > doing things like this (sxg/sxghif.h:851, slicoss/slicoss.c:960):
> 
> Yes, it needs it too.

Hm, it already has this dependancy.  In drivers/staging/slicoss/Kconfig
we have:
	config SLICOSS
		tristate "Alacritech Gigabit IS-NIC support"
		depends on PCI && X86 && NETDEV_1000

So we should be fine here.

thanks,

greg k-h

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

* Re: linux-next: build failure
  2008-10-20 16:33   ` J.R. Mauro
@ 2008-10-20 16:51     ` Greg KH
  2008-10-20 20:47       ` Greg KH
  0 siblings, 1 reply; 96+ messages in thread
From: Greg KH @ 2008-10-20 16:51 UTC (permalink / raw)
  To: J.R. Mauro
  Cc: Stephen Rothwell, linux-next, Christopher Harrer, Michael Miles,
	LKML, Andrew Morton, linus

On Mon, Oct 20, 2008 at 12:33:29PM -0400, J.R. Mauro wrote:
> On Mon, Oct 20, 2008 at 11:48 AM, Greg KH <greg@kroah.com> wrote:
> > On Mon, Oct 20, 2008 at 11:04:20PM +1100, Stephen Rothwell wrote:
> >> Hi Greg,
> >>
> >> Today's linux-next build (powerpc allyesconfig) failed like this:
> >>
> >> In file included from drivers/staging/sxg/sxg.c:77:
> >> drivers/staging/sxg/sxghif.h:859: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Compilation'
> >> drivers/staging/sxg/sxg.c: In function 'sxg_transmit_packet':
> >> drivers/staging/sxg/sxg.c:1949: error: 'SXG_SGL_BUF_SIZE' undeclared (first use in this function)
> >> drivers/staging/sxg/sxg.c:1958: error: implicit declaration of function 'SXG_SGL_BUFFER'
> >> drivers/staging/sxg/sxg.c:1958: warning: assignment makes pointer from integer without a cast
> >> drivers/staging/sxg/sxg.c: In function 'sxg_mcast_set_mask':
> >> drivers/staging/sxg/sxg.c:2846: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
> >>
> >> I applied the following patch.
> >
> > Ah, doh, sorry, I should have caught that.  I'll go apply this to the
> > tree, thanks.
> 
> Greg,
> 
> The slicoss driver also from Alacritech looks like it needs a depends
> on X86 as well. Should the sxg and slicoss drivers from Alacritech be
> doing things like this (sxg/sxghif.h:851, slicoss/slicoss.c:960):

Yes, it needs it too.

thanks,

greg k-h

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

* Re: linux-next: build failure
  2008-10-20 15:48 ` Greg KH
@ 2008-10-20 16:33   ` J.R. Mauro
  2008-10-20 16:51     ` Greg KH
  2008-10-20 22:31   ` Stephen Rothwell
  1 sibling, 1 reply; 96+ messages in thread
From: J.R. Mauro @ 2008-10-20 16:33 UTC (permalink / raw)
  To: Greg KH
  Cc: Stephen Rothwell, linux-next, Christopher Harrer, Michael Miles,
	LKML, Andrew Morton, linus

On Mon, Oct 20, 2008 at 11:48 AM, Greg KH <greg@kroah.com> wrote:
> On Mon, Oct 20, 2008 at 11:04:20PM +1100, Stephen Rothwell wrote:
>> Hi Greg,
>>
>> Today's linux-next build (powerpc allyesconfig) failed like this:
>>
>> In file included from drivers/staging/sxg/sxg.c:77:
>> drivers/staging/sxg/sxghif.h:859: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Compilation'
>> drivers/staging/sxg/sxg.c: In function 'sxg_transmit_packet':
>> drivers/staging/sxg/sxg.c:1949: error: 'SXG_SGL_BUF_SIZE' undeclared (first use in this function)
>> drivers/staging/sxg/sxg.c:1958: error: implicit declaration of function 'SXG_SGL_BUFFER'
>> drivers/staging/sxg/sxg.c:1958: warning: assignment makes pointer from integer without a cast
>> drivers/staging/sxg/sxg.c: In function 'sxg_mcast_set_mask':
>> drivers/staging/sxg/sxg.c:2846: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
>>
>> I applied the following patch.
>
> Ah, doh, sorry, I should have caught that.  I'll go apply this to the
> tree, thanks.

Greg,

The slicoss driver also from Alacritech looks like it needs a depends
on X86 as well. Should the sxg and slicoss drivers from Alacritech be
doing things like this (sxg/sxghif.h:851, slicoss/slicoss.c:960):

#if defined(CONFIG_X86_64)

...

#else
    Stop Compilation;
#endif


>
> greg k-h
> --
> 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/
>

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

* Re: linux-next: build failure
  2008-10-20 12:04 Stephen Rothwell
@ 2008-10-20 15:48 ` Greg KH
  2008-10-20 16:33   ` J.R. Mauro
  2008-10-20 22:31   ` Stephen Rothwell
  0 siblings, 2 replies; 96+ messages in thread
From: Greg KH @ 2008-10-20 15:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, Christopher Harrer, Michael Miles, LKML,
	Andrew Morton, linus

On Mon, Oct 20, 2008 at 11:04:20PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> In file included from drivers/staging/sxg/sxg.c:77:
> drivers/staging/sxg/sxghif.h:859: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Compilation'
> drivers/staging/sxg/sxg.c: In function 'sxg_transmit_packet':
> drivers/staging/sxg/sxg.c:1949: error: 'SXG_SGL_BUF_SIZE' undeclared (first use in this function)
> drivers/staging/sxg/sxg.c:1958: error: implicit declaration of function 'SXG_SGL_BUFFER'
> drivers/staging/sxg/sxg.c:1958: warning: assignment makes pointer from integer without a cast
> drivers/staging/sxg/sxg.c: In function 'sxg_mcast_set_mask':
> drivers/staging/sxg/sxg.c:2846: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'
> 
> I applied the following patch.

Ah, doh, sorry, I should have caught that.  I'll go apply this to the
tree, thanks.

greg k-h

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

* linux-next: build failure
@ 2008-10-20 12:04 Stephen Rothwell
  2008-10-20 15:48 ` Greg KH
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2008-10-20 12:04 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, Christopher Harrer, Michael Miles, LKML,
	Andrew Morton, linus

Hi Greg,

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

In file included from drivers/staging/sxg/sxg.c:77:
drivers/staging/sxg/sxghif.h:859: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Compilation'
drivers/staging/sxg/sxg.c: In function 'sxg_transmit_packet':
drivers/staging/sxg/sxg.c:1949: error: 'SXG_SGL_BUF_SIZE' undeclared (first use in this function)
drivers/staging/sxg/sxg.c:1958: error: implicit declaration of function 'SXG_SGL_BUFFER'
drivers/staging/sxg/sxg.c:1958: warning: assignment makes pointer from integer without a cast
drivers/staging/sxg/sxg.c: In function 'sxg_mcast_set_mask':
drivers/staging/sxg/sxg.c:2846: warning: format '%llx' expects type 'long long unsigned int', but argument 5 has type 'u64'

I applied the following patch.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 20 Oct 2008 22:59:18 +1100
Subject: [PATCH] staging: sxg depends on X86

sxghif.h has code that explicitly will not build fo other architecures.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/staging/sxg/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/sxg/Kconfig b/drivers/staging/sxg/Kconfig
index 1ae3508..6e6cf0b 100644
--- a/drivers/staging/sxg/Kconfig
+++ b/drivers/staging/sxg/Kconfig
@@ -1,6 +1,7 @@
 config SXG
 	tristate "Alacritech SLIC Technology Non-Accelerated 10Gbe support"
 	depends on PCI && NETDEV_10000
+	depends on X86
 	default n
 	help
 	  This driver supports the Alacritech SLIC Technology Non-Accelerated
-- 
1.5.6.5

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

* Re: linux-next: build failure
  2008-10-17  8:21 Stephen Rothwell
@ 2008-10-17 17:37 ` Greg KH
  0 siblings, 0 replies; 96+ messages in thread
From: Greg KH @ 2008-10-17 17:37 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, Ming Lei

On Fri, Oct 17, 2008 at 07:21:09PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> drivers/usb/host/ehci-dbg.c: In function 'fill_buffer':
> drivers/usb/host/ehci-dbg.c:839: error: implicit declaration of function 'vmalloc'
> drivers/usb/host/ehci-dbg.c:839: warning: cast to pointer from integer of different size
> drivers/usb/host/ehci-dbg.c: In function 'debug_close':
> drivers/usb/host/ehci-dbg.c:887: error: implicit declaration of function 'vfree'
> 
> Caused by commit b28e0eaa4a48bdc742978d6dd3688ef1db71928c ("USB:
> ehci-dbg: increase debug buffer size for periodic file") from the usb
> tree.
> 
> I added the following patch.

Thanks, I'll merge this in before sending it off to Linus.

greg k-h

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

* linux-next: build failure
@ 2008-10-17  8:21 Stephen Rothwell
  2008-10-17 17:37 ` Greg KH
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2008-10-17  8:21 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, Ming Lei

Hi Greg,

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

drivers/usb/host/ehci-dbg.c: In function 'fill_buffer':
drivers/usb/host/ehci-dbg.c:839: error: implicit declaration of function 'vmalloc'
drivers/usb/host/ehci-dbg.c:839: warning: cast to pointer from integer of different size
drivers/usb/host/ehci-dbg.c: In function 'debug_close':
drivers/usb/host/ehci-dbg.c:887: error: implicit declaration of function 'vfree'

Caused by commit b28e0eaa4a48bdc742978d6dd3688ef1db71928c ("USB:
ehci-dbg: increase debug buffer size for periodic file") from the usb
tree.

I added the following patch.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 17 Oct 2008 19:19:03 +1100
Subject: [PATCH] usb: vmalloc needs include of vmalloc.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/usb/host/ehci-dbg.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/ehci-dbg.c b/drivers/usb/host/ehci-dbg.c
index 0cb53ca..7119036 100644
--- a/drivers/usb/host/ehci-dbg.c
+++ b/drivers/usb/host/ehci-dbg.c
@@ -18,6 +18,8 @@
 
 /* this file is part of ehci-hcd.c */
 
+#include <linux/vmalloc.h>
+
 #define ehci_dbg(ehci, fmt, args...) \
 	dev_dbg (ehci_to_hcd(ehci)->self.controller , fmt , ## args )
 #define ehci_err(ehci, fmt, args...) \
-- 
1.5.6.5

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

* linux-next: build failure
@ 2008-10-17  7:59 Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-10-17  7:59 UTC (permalink / raw)
  To: David S. Miller; +Cc: linux-next

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

Hi ,

Today's linux-next build (sparc defconfig) failed like this:

.tmp_kallsyms2.o(.rodata+0x0): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x4): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x8): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0xc): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x10): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x14): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x18): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x1c): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x20): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x24): In function `kallsyms_addresses':
: relocation truncated to fit: R_SPARC_32 _text
.tmp_kallsyms2.o(.rodata+0x28): In function `kallsyms_addresses':
: additional relocation overflows omitted from the output

I have no idea what to do about this.
-- 
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] 96+ messages in thread

* Re: linux-next:  build failure
  2008-10-16 16:11   ` Jeremy Fitzhardinge
@ 2008-10-16 16:14     ` Ingo Molnar
  0 siblings, 0 replies; 96+ messages in thread
From: Ingo Molnar @ 2008-10-16 16:14 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Stephen Rothwell, linux-next, ppc-dev, Andrew Morton


* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Ingo Molnar wrote:
>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>>   
>>> Hi all,
>>>
>>> Today's linux-next build (powerpc allyesconfig) failed like this:
>>>
>>> In file included from arch/powerpc/include/asm/mmu-hash64.h:17,
>>>                  from arch/powerpc/include/asm/mmu.h:8,
>>>                  from arch/powerpc/include/asm/pgtable.h:8,
>>>                  from arch/powerpc/mm/slb.c:20:
>>> arch/powerpc/include/asm/page.h:76: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'memstart_addr'
>>> arch/powerpc/include/asm/page.h:77: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'kernstart_addr'
>>>
>>> Caused by commit 600715dcdf567c86f8b2c6173fcfb4b873e25a19 ("generic: add
>>> phys_addr_t for holding physical addresses") from the tip-core tree.
>>> This only fails if CONFIG_RELOCATABLE is set.
>>>
>>> I have applied the patch below.
>>>     
>>
>> applied to tip/core/urgent, thanks Stephen!
>>   
>
> Shouldn't this go via a ppc tree?  Won't having ppc changes in tip.git  
> make people grumpy?

it was broken via a generic topic: tip/core/resources, not the x86 tree.

	Ingo

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

* Re: linux-next:  build failure
  2008-10-16 10:39 ` Ingo Molnar
@ 2008-10-16 16:11   ` Jeremy Fitzhardinge
  2008-10-16 16:14     ` Ingo Molnar
  0 siblings, 1 reply; 96+ messages in thread
From: Jeremy Fitzhardinge @ 2008-10-16 16:11 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Stephen Rothwell, linux-next, ppc-dev, Andrew Morton

Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>   
>> Hi all,
>>
>> Today's linux-next build (powerpc allyesconfig) failed like this:
>>
>> In file included from arch/powerpc/include/asm/mmu-hash64.h:17,
>>                  from arch/powerpc/include/asm/mmu.h:8,
>>                  from arch/powerpc/include/asm/pgtable.h:8,
>>                  from arch/powerpc/mm/slb.c:20:
>> arch/powerpc/include/asm/page.h:76: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'memstart_addr'
>> arch/powerpc/include/asm/page.h:77: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'kernstart_addr'
>>
>> Caused by commit 600715dcdf567c86f8b2c6173fcfb4b873e25a19 ("generic: add
>> phys_addr_t for holding physical addresses") from the tip-core tree.
>> This only fails if CONFIG_RELOCATABLE is set.
>>
>> I have applied the patch below.
>>     
>
> applied to tip/core/urgent, thanks Stephen!
>   

Shouldn't this go via a ppc tree?  Won't having ppc changes in tip.git 
make people grumpy?

    J

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

* Re: linux-next: build failure
  2008-10-16  9:28 Stephen Rothwell
@ 2008-10-16 14:00 ` Eric Van Hensbergen
  0 siblings, 0 replies; 96+ messages in thread
From: Eric Van Hensbergen @ 2008-10-16 14:00 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next

On Thu, Oct 16, 2008 at 4:28 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Eric,
>
> Today's linux-next build (powerpc allyesconfig) failed like this:
>
> net/9p/client.c: At top level:
> net/9p/client.c:698: error: __ksymtab_p9_client_version causes a section type conflict
>
> Caused by commit f0cad54013b07371dcefd8fa36ff1d3918b49695 ("9p: rework
> client code to use new protocol support functions") from the v9fs tree
> which exported a static function.  I have applied the following patch.
>

Applied and pushed to my for-next tree - thanks very much.
Any reason why this showed up in powerpc and not an x86 build? (in
other words, what could I have done to catch this sooner)

                   -eric

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

* Re: linux-next:  build failure
  2008-10-16  9:29 Stephen Rothwell
@ 2008-10-16 10:39 ` Ingo Molnar
  2008-10-16 16:11   ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 96+ messages in thread
From: Ingo Molnar @ 2008-10-16 10:39 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Jeremy Fitzhardinge, linux-next, ppc-dev, Andrew Morton


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> In file included from arch/powerpc/include/asm/mmu-hash64.h:17,
>                  from arch/powerpc/include/asm/mmu.h:8,
>                  from arch/powerpc/include/asm/pgtable.h:8,
>                  from arch/powerpc/mm/slb.c:20:
> arch/powerpc/include/asm/page.h:76: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'memstart_addr'
> arch/powerpc/include/asm/page.h:77: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'kernstart_addr'
> 
> Caused by commit 600715dcdf567c86f8b2c6173fcfb4b873e25a19 ("generic: add
> phys_addr_t for holding physical addresses") from the tip-core tree.
> This only fails if CONFIG_RELOCATABLE is set.
> 
> I have applied the patch below.

applied to tip/core/urgent, thanks Stephen!

	Ingo

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

* linux-next:  build failure
@ 2008-10-16  9:29 Stephen Rothwell
  2008-10-16 10:39 ` Ingo Molnar
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2008-10-16  9:29 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: linux-next, ppc-dev, Ingo Molnar, Andrew Morton

Hi all,

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

In file included from arch/powerpc/include/asm/mmu-hash64.h:17,
                 from arch/powerpc/include/asm/mmu.h:8,
                 from arch/powerpc/include/asm/pgtable.h:8,
                 from arch/powerpc/mm/slb.c:20:
arch/powerpc/include/asm/page.h:76: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'memstart_addr'
arch/powerpc/include/asm/page.h:77: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'kernstart_addr'

Caused by commit 600715dcdf567c86f8b2c6173fcfb4b873e25a19 ("generic: add
phys_addr_t for holding physical addresses") from the tip-core tree.
This only fails if CONFIG_RELOCATABLE is set.

I have applied the patch below.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

>From 3e3a6a5f9479a4d35070c15f863a8635e9865058 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 16 Oct 2008 20:07:00 +1100
Subject: [PATCH] tip-core/powerpc: phys_addr_t has moved to linux/types.h

So include that instead of asm/types.h in asm/page.h for
the CONFIG_RELOCATABLE case.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/include/asm/page.h |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 64e1445..5ac51e6 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -10,9 +10,13 @@
  * 2 of the License, or (at your option) any later version.
  */
 
+#ifndef __ASSEMBLY__
+#include <linux/types.h>
+#else
+#include <asm/types.h>
+#endif
 #include <asm/asm-compat.h>
 #include <asm/kdump.h>
-#include <asm/types.h>
 
 /*
  * On PPC32 page size is 4K. For PPC64 we support either 4K or 64K software
-- 
1.5.6.5

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

* linux-next: build failure
@ 2008-10-16  9:28 Stephen Rothwell
  2008-10-16 14:00 ` Eric Van Hensbergen
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2008-10-16  9:28 UTC (permalink / raw)
  To: Eric Van Hensbergen; +Cc: linux-next

Hi Eric,

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

net/9p/client.c: At top level:
net/9p/client.c:698: error: __ksymtab_p9_client_version causes a section type conflict

Caused by commit f0cad54013b07371dcefd8fa36ff1d3918b49695 ("9p: rework
client code to use new protocol support functions") from the v9fs tree
which exported a static function.  I have applied the following patch.

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

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 16 Oct 2008 20:27:24 +1100
Subject: [PATCH] v9fs: don't export static functions

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 net/9p/client.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/9p/client.c b/net/9p/client.c
index 4cd9e70..7621fe8 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -655,7 +655,7 @@ static void p9_fid_destroy(struct p9_fid *fid)
 	kfree(fid);
 }
 
-static int p9_client_version(struct p9_client *c)
+int p9_client_version(struct p9_client *c)
 {
 	int err = 0;
 	struct p9_req_t *req;
-- 
1.5.6.5

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

* Re: linux-next: build failure
  2008-09-03  8:45 Stephen Rothwell
@ 2008-09-03 10:19 ` David Woodhouse
  0 siblings, 0 replies; 96+ messages in thread
From: David Woodhouse @ 2008-09-03 10:19 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next

On Wed, 2008-09-03 at 18:45 +1000, Stephen Rothwell wrote:
> -typedef __statfs_word __u32
> +#define __statfs_word __u32

Fixed in the git tree, and in the series I just sent out. Thanks.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

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

* linux-next: build failure
@ 2008-09-03  8:45 Stephen Rothwell
  2008-09-03 10:19 ` David Woodhouse
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2008-09-03  8:45 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linux-next

Hi David,

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

In file included from arch/powerpc/include/asm/statfs.h:5,
                 from include/linux/statfs.h:7,
                 from include/linux/vfs.h:5,
                 from fs/open.c:23:
include/asm-generic/statfs.h:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__u32'
include/asm-generic/statfs.h:36: error: two or more data types in declaration specifiers
include/asm-generic/statfs.h:36: warning: useless type name in empty declaration
include/asm-generic/statfs.h:47: error: expected specifier-qualifier-list before '__statfs_word'

and it went downhill from there.

Introduced by commit 97bea16fbd30f35637447cf0884ac0e1fe467a37 ("Make
<asm-generic/statfs.h> suitable for 64-bit platforms") from the dwmw2
tree.  I applied the following patch.

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

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 3 Sep 2008 18:37:34 +1000
Subject: [PATCH] statfs: fix typo

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/asm-generic/statfs.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/asm-generic/statfs.h b/include/asm-generic/statfs.h
index 68b6d69..6129d68 100644
--- a/include/asm-generic/statfs.h
+++ b/include/asm-generic/statfs.h
@@ -17,7 +17,7 @@ typedef __kernel_fsid_t	fsid_t;
 #if BITS_PER_LONG == 64
 #define __statfs_word long
 #else
-typedef __statfs_word __u32
+#define __statfs_word __u32
 #endif
 #endif
 
-- 
1.5.6.5

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

* Re: linux-next: build failure
  2008-08-25 11:28 Stephen Rothwell
  2008-08-25 12:40 ` Ingo Molnar
@ 2008-08-28  7:40 ` David Miller
  1 sibling, 0 replies; 96+ messages in thread
From: David Miller @ 2008-08-28  7:40 UTC (permalink / raw)
  To: sfr; +Cc: mingo, linux-next, linux-kernel

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 25 Aug 2008 21:28:33 +1000

> Hi Ingo,
> 
> Today's linux-next build (sparc64 defconfig) failed like this:
> 
> ERROR: "__BUILD_BUG_ON_non_constant" [drivers/net/sunvnet.ko] undefined!
> ERROR: "__BUILD_BUG_ON_non_constant" [drivers/block/sunvdc.ko] undefined!
> 
> Probably intorduced by commit f5b5d41dd51a31fe70e3a04fb80a3b90b84c6a4e
> ("debug: fix BUILD_BUG_ON() for non-constant expressions").

I think __builtin_constant_p() is not seeing something it
should here.

It isn't accepting:

--------------------
static inline __attribute__((const))
bool is_power_of_2(unsigned long n)
{
	return (n != 0 && ((n & (n - 1)) == 0));
}
--------------------

and thus is_power_of_2(256) as being a constant.

If a 'const' inline function being passed a const argument isn't
constant, what is! :-)

I bet the problem is the fact that is_power_of_2() is a function.

I did some tests and I can only trigger this problem with gcc-3.4 on
sparc, gcc-4.1 and gcc-4.2 worked fine.

It triggers with both -O2 and -Os for the following simple test case:

static inline __attribute__((const))
int is_power_of_2(unsigned long n)
{
	return (n != 0 && ((n & (n - 1)) == 0));
}

extern int bar;

int main(void)
{
	if (!__builtin_constant_p(is_power_of_2(256)))
		bar++;
	return 0;
}

davem@sunset:~/src/GIT/linux-2.6$ gcc-3.4  -Os -o x x.c
/tmp/ccy8FzD8.o: In function `main':
x.c:(.text+0x0): undefined reference to `bar'
x.c:(.text+0x4): undefined reference to `bar'
x.c:(.text+0xc): undefined reference to `bar'
collect2: ld returned 1 exit status
davem@sunset:~/src/GIT/linux-2.6$ gcc-3.4  -O2 -o x x.c
/tmp/ccQNzZuj.o: In function `main':
x.c:(.text+0x0): undefined reference to `bar'
x.c:(.text+0x4): undefined reference to `bar'
x.c:(.text+0xc): undefined reference to `bar'
collect2: ld returned 1 exit status
davem@sunset:~/src/GIT/linux-2.6$ 

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

* Re: linux-next: build failure
  2008-08-27  2:55 ` Rusty Russell
@ 2008-08-27  4:54   ` Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-08-27  4:54 UTC (permalink / raw)
  To: Rusty Russell; +Cc: Johannes Berg, linux-next, netdev

Hi Rusty,

On Wed, 27 Aug 2008 12:55:22 +1000 Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> On Wednesday 27 August 2008 10:06:56 Stephen Rothwell wrote:
> > Introduced by commit 4cb9da6ecc2b0e25056b45981239475f8509d59d ("remove
> > CONFIG_KMOD from net") which added a !CONFIG_MODULES (static inline)
> > version of dev_load() to include/linux/netdevice.h but the copy in
> > net/core/dev.c is not protected by CONFIG_MODULES.
> 
> Thanks.  I've fixed this the simplest way: remove the change to the header.

So, for today, I have applied the following patch after importing the rr
tree:

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

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 27 Aug 2008 14:45:37 +1000
Subject: [PATCH] rr: build fix for remove CONFIG_KMOD from net

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/netdevice.h |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index b215744..2254eb8 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1639,11 +1639,7 @@ extern int		dev_set_allmulti(struct net_device *dev, int inc);
 extern void		netdev_state_change(struct net_device *dev);
 extern void		netdev_bonding_change(struct net_device *dev);
 extern void		netdev_features_change(struct net_device *dev);
-#ifdef CONFIG_MODULES
 extern void		dev_load(struct net *net, const char *name);
-#else
-static inline void	dev_load(struct net *net, const char *name) {};
-#endif
 extern void		dev_mcast_init(void);
 extern int		netdev_max_backlog;
 extern int		weight_p;
-- 
1.5.6.5

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

* Re: linux-next: build failure
  2008-08-27  0:06 Stephen Rothwell
@ 2008-08-27  2:55 ` Rusty Russell
  2008-08-27  4:54   ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Rusty Russell @ 2008-08-27  2:55 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Johannes Berg, linux-next, netdev

On Wednesday 27 August 2008 10:06:56 Stephen Rothwell wrote:
> Introduced by commit 4cb9da6ecc2b0e25056b45981239475f8509d59d ("remove
> CONFIG_KMOD from net") which added a !CONFIG_MODULES (static inline)
> version of dev_load() to include/linux/netdevice.h but the copy in
> net/core/dev.c is not protected by CONFIG_MODULES.

Thanks.  I've fixed this the simplest way: remove the change to the header.

Rusty.

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

* linux-next: build failure
@ 2008-08-27  0:06 Stephen Rothwell
  2008-08-27  2:55 ` Rusty Russell
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2008-08-27  0:06 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-next, Rusty Russell, netdev

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

Hi all,

next-20080826 build (powerpc mpc885_ads_defconfig) failed like this:

net/core/dev.c:1000: error: redefinition of 'dev_load'
include/linux/netdevice.h:1645: error: previous definition of 'dev_load' was here

This also failed for several other builds where CONFIG_MODULES is off.

Introduced by commit 4cb9da6ecc2b0e25056b45981239475f8509d59d ("remove
CONFIG_KMOD from net") which added a !CONFIG_MODULES (static inline)
version of dev_load() to include/linux/netdevice.h but the copy in
net/core/dev.c is not protected by CONFIG_MODULES.

-- 
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] 96+ messages in thread

* Re: linux-next:  build failure
  2008-08-25 11:28 Stephen Rothwell
@ 2008-08-25 12:40 ` Ingo Molnar
  2008-08-28  7:40 ` David Miller
  1 sibling, 0 replies; 96+ messages in thread
From: Ingo Molnar @ 2008-08-25 12:40 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, David Miller, LKML


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Ingo,
> 
> Today's linux-next build (sparc64 defconfig) failed like this:
> 
> ERROR: "__BUILD_BUG_ON_non_constant" [drivers/net/sunvnet.ko] undefined!
> ERROR: "__BUILD_BUG_ON_non_constant" [drivers/block/sunvdc.ko] undefined!
> 
> Probably intorduced by commit f5b5d41dd51a31fe70e3a04fb80a3b90b84c6a4e
> ("debug: fix BUILD_BUG_ON() for non-constant expressions").
> 
> The preprocessed code looks like this:
> 
> static inline __attribute__((always_inline)) u32 vio_dring_avail(struct vio_dring_state *dr,
>       unsigned int ring_size)
> {
>  do { (void)sizeof(char[1 - 2*!!(!is_power_of_2(ring_size))]); if (!__builtin_constant_p(!is_power_of_2(ring_size))) __BUILD_BUG_ON_non_constant++; } while (0);
> 
>  return (dr->pending -
>   ((dr->prod - dr->cons) & (ring_size - 1)));
> }
> 
> I tried turning the above inline function into a macro to no avail.
> 
> I applied the following patch (which is probably not what is wanted, 
> but puts back what was there before).
> 
> I see from LKML that this definition of BUILD_BUG_ON is to be 
> replaced, so this is just a temporary measure.

yeah. Note that it will only be stricter, so more fallout is expected.

	Ingo

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

* linux-next:  build failure
@ 2008-08-25 11:28 Stephen Rothwell
  2008-08-25 12:40 ` Ingo Molnar
  2008-08-28  7:40 ` David Miller
  0 siblings, 2 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-08-25 11:28 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-next, David Miller, LKML

Hi Ingo,

Today's linux-next build (sparc64 defconfig) failed like this:

ERROR: "__BUILD_BUG_ON_non_constant" [drivers/net/sunvnet.ko] undefined!
ERROR: "__BUILD_BUG_ON_non_constant" [drivers/block/sunvdc.ko] undefined!

Probably intorduced by commit f5b5d41dd51a31fe70e3a04fb80a3b90b84c6a4e
("debug: fix BUILD_BUG_ON() for non-constant expressions").

The preprocessed code looks like this:

static inline __attribute__((always_inline)) u32 vio_dring_avail(struct vio_dring_state *dr,
      unsigned int ring_size)
{
 do { (void)sizeof(char[1 - 2*!!(!is_power_of_2(ring_size))]); if (!__builtin_constant_p(!is_power_of_2(ring_size))) __BUILD_BUG_ON_non_constant++; } while (0);

 return (dr->pending -
  ((dr->prod - dr->cons) & (ring_size - 1)));
}

I tried turning the above inline function into a macro to no avail.

I applied the following patch (which is probably not what is wanted, but
puts back what was there before).

I see from LKML that this definition of BUILD_BUG_ON is to be replaced,
so this is just a temporary measure.

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

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 25 Aug 2008 21:16:14 +1000
Subject: [PATCH] revert BUILD_BUG_ON change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/compiler.h |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index d7d313b..a1c082d 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -206,15 +206,9 @@ extern void __chk_io_ptr(const volatile void __iomem *);
  * ( The linker trick relies on gcc optimizing out a multiplication with
  *   constant zero - which should be reasonable enough. )
  */
-#ifndef __ASSEMBLY__
-extern unsigned int __BUILD_BUG_ON_non_constant;
-#endif
-
 #define BUILD_BUG_ON(condition)					\
 do {								\
 	(void)sizeof(char[1 - 2*!!(condition)]);		\
-	if (!__builtin_constant_p(condition))			\
-		__BUILD_BUG_ON_non_constant++;			\
 } while (0)
 
 /*
-- 
1.5.6.3

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

* Re: linux-next: build failure
  2008-07-30 19:16         ` Bartlomiej Zolnierkiewicz
@ 2008-07-30 23:35           ` Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-07-30 23:35 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz
  Cc: Ankita Garg, Adrian Bunk, Ananth N Mavinakayanahalli, linux-next,
	Vivek Goyal, Haren Myneni, kexec

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

Hi Bart,

On Wed, 30 Jul 2008 21:16:55 +0200 Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
>
> On Wednesday 30 July 2008, Ankita Garg wrote:
> > On Wed, Jul 30, 2008 at 09:41:46AM +0300, Adrian Bunk wrote:
> > > On Wed, Jul 30, 2008 at 03:30:28PM +1000, Stephen Rothwell wrote:
> > > > Hi Ananth,
> > > > 
> > > > Today's linux-next build (powerpc allyesconfig) failed like this:
> > > > 
> > > > tests/lkdtm.c:182: error: expected ')' before '*' token
> > > > 
> > > > I have no idea why this fails now when it did not before.
> > > 
> > > Sorry, that's my fault.
> > > (I didn't notice since my allyes builds have CONFIG_MODULES=n, and
> > >  no defconfig seems to have both LKDTM and IDE=y.)
> > > 
> > > Bart, can you either apply Stephen's patch or drop the lkdtm.c chunk 
> > > from my patch?
> > >
> > 
> > I suppose it would be better if the earlier changes are reverted, as
> > lkdtm already has bits to include ide.h depending on CONFIG_IDE being
> > y/n.
> 
> I reverted lktdm.c change (sorry for not noticing it earlier).

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] 96+ messages in thread

* Re: linux-next: build failure
       [not found]       ` <20080730070643.GA18347-xthvdsQ13ZrQT0dZR+AlfA@public.gmane.org>
@ 2008-07-30 19:16         ` Bartlomiej Zolnierkiewicz
  2008-07-30 23:35           ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2008-07-30 19:16 UTC (permalink / raw)
  To: Ankita Garg
  Cc: Stephen Rothwell, Adrian Bunk, Ananth N Mavinakayanahalli,
	kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Haren Myneni,
	linux-next-u79uwXL29TY76Z2rM5mHXA, Vivek Goyal

On Wednesday 30 July 2008, Ankita Garg wrote:
> On Wed, Jul 30, 2008 at 09:41:46AM +0300, Adrian Bunk wrote:
> > On Wed, Jul 30, 2008 at 03:30:28PM +1000, Stephen Rothwell wrote:
> > > Hi Ananth,
> > > 
> > > Today's linux-next build (powerpc allyesconfig) failed like this:
> > > 
> > > tests/lkdtm.c:182: error: expected ')' before '*' token
> > > 
> > > I have no idea why this fails now when it did not before.
> > 
> > Sorry, that's my fault.
> > (I didn't notice since my allyes builds have CONFIG_MODULES=n, and
> >  no defconfig seems to have both LKDTM and IDE=y.)
> > 
> > Bart, can you either apply Stephen's patch or drop the lkdtm.c chunk 
> > from my patch?
> >
> 
> I suppose it would be better if the earlier changes are reverted, as
> lkdtm already has bits to include ide.h depending on CONFIG_IDE being
> y/n.

I reverted lktdm.c change (sorry for not noticing it earlier).

Thanks,
Bart

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

* Re: linux-next: build failure
       [not found]   ` <20080730064146.GA1564-re2QNgSbS3j4D6uPqz5PAwR5/fbUUdgG@public.gmane.org>
@ 2008-07-30  7:06     ` Ankita Garg
       [not found]       ` <20080730070643.GA18347-xthvdsQ13ZrQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 96+ messages in thread
From: Ankita Garg @ 2008-07-30  7:06 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Stephen Rothwell, Ananth N Mavinakayanahalli,
	Bartlomiej Zolnierkiewicz,
	kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Haren Myneni,
	linux-next-u79uwXL29TY76Z2rM5mHXA, Vivek Goyal

On Wed, Jul 30, 2008 at 09:41:46AM +0300, Adrian Bunk wrote:
> On Wed, Jul 30, 2008 at 03:30:28PM +1000, Stephen Rothwell wrote:
> > Hi Ananth,
> > 
> > Today's linux-next build (powerpc allyesconfig) failed like this:
> > 
> > tests/lkdtm.c:182: error: expected ')' before '*' token
> > 
> > I have no idea why this fails now when it did not before.
> 
> Sorry, that's my fault.
> (I didn't notice since my allyes builds have CONFIG_MODULES=n, and
>  no defconfig seems to have both LKDTM and IDE=y.)
> 
> Bart, can you either apply Stephen's patch or drop the lkdtm.c chunk 
> from my patch?
>

I suppose it would be better if the earlier changes are reverted, as
lkdtm already has bits to include ide.h depending on CONFIG_IDE being
y/n.

> > I applied the following patch.
> > -- 
> > Cheers,
> > Stephen Rothwell                    sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org
> > http://www.canb.auug.org.au/~sfr/
> > 
> > From: Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
> > Date: Wed, 30 Jul 2008 15:24:53 +1000
> > Subject: [PATCH] tests: lkdtm needs ide.h
> > 
> > Signed-off-by: Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
> > ---
> >  tests/lkdtm.c |    1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> > 
> > diff --git a/tests/lkdtm.c b/tests/lkdtm.c
> > index 2a40d18..856f060 100644
> > --- a/tests/lkdtm.c
> > +++ b/tests/lkdtm.c
> > @@ -52,6 +52,7 @@
> >  #include <linux/init.h>
> >  #include <linux/interrupt.h>
> >  #include <linux/hrtimer.h>
> > +#include <linux/ide.h>
> >  #include <scsi/scsi_cmnd.h>
> >  
> >  #define NUM_CPOINTS 8
> 
> cu
> Adrian
> 
> -- 
> 
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed

-- 
Regards,
Ankita Garg (ankita-xthvdsQ13ZrQT0dZR+AlfA@public.gmane.org)
Linux Technology Center
IBM India Systems & Technology Labs, 
Bangalore, India   

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

* Re: linux-next: build failure
  2008-07-30  5:30 Stephen Rothwell
  2008-07-30  5:54 ` Ananth N Mavinakayanahalli
@ 2008-07-30  6:41 ` Adrian Bunk
       [not found]   ` <20080730064146.GA1564-re2QNgSbS3j4D6uPqz5PAwR5/fbUUdgG@public.gmane.org>
  1 sibling, 1 reply; 96+ messages in thread
From: Adrian Bunk @ 2008-07-30  6:41 UTC (permalink / raw)
  To: Stephen Rothwell, Bartlomiej Zolnierkiewicz
  Cc: Ananth N Mavinakayanahalli, linux-next, Ankita Garg, Vivek Goyal,
	Haren Myneni, kexec

On Wed, Jul 30, 2008 at 03:30:28PM +1000, Stephen Rothwell wrote:
> Hi Ananth,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> tests/lkdtm.c:182: error: expected ')' before '*' token
> 
> I have no idea why this fails now when it did not before.

Sorry, that's my fault.
(I didn't notice since my allyes builds have CONFIG_MODULES=n, and
 no defconfig seems to have both LKDTM and IDE=y.)

Bart, can you either apply Stephen's patch or drop the lkdtm.c chunk 
from my patch?

> I applied the following patch.
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 30 Jul 2008 15:24:53 +1000
> Subject: [PATCH] tests: lkdtm needs ide.h
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  tests/lkdtm.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/tests/lkdtm.c b/tests/lkdtm.c
> index 2a40d18..856f060 100644
> --- a/tests/lkdtm.c
> +++ b/tests/lkdtm.c
> @@ -52,6 +52,7 @@
>  #include <linux/init.h>
>  #include <linux/interrupt.h>
>  #include <linux/hrtimer.h>
> +#include <linux/ide.h>
>  #include <scsi/scsi_cmnd.h>
>  
>  #define NUM_CPOINTS 8

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

* Re: linux-next: build failure
  2008-07-30  5:30 Stephen Rothwell
@ 2008-07-30  5:54 ` Ananth N Mavinakayanahalli
  2008-07-30  6:41 ` Adrian Bunk
  1 sibling, 0 replies; 96+ messages in thread
From: Ananth N Mavinakayanahalli @ 2008-07-30  5:54 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, Ankita Garg, Vivek Goyal, Haren Myneni, kexec

On Wed, Jul 30, 2008 at 03:30:28PM +1000, Stephen Rothwell wrote:
> Hi Ananth,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> tests/lkdtm.c:182: error: expected ')' before '*' token
> 
> I have no idea why this fails now when it did not before.
> 
> I applied the following patch.

Thanks Stephen!

Ankita, any ideas?

Ananth

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

* linux-next: build failure
@ 2008-07-30  5:30 Stephen Rothwell
  2008-07-30  5:54 ` Ananth N Mavinakayanahalli
  2008-07-30  6:41 ` Adrian Bunk
  0 siblings, 2 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-07-30  5:30 UTC (permalink / raw)
  To: Ananth N Mavinakayanahalli
  Cc: linux-next, Ankita Garg, Vivek Goyal, Haren Myneni, kexec

Hi Ananth,

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

tests/lkdtm.c:182: error: expected ')' before '*' token

I have no idea why this fails now when it did not before.

I applied the following patch.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 30 Jul 2008 15:24:53 +1000
Subject: [PATCH] tests: lkdtm needs ide.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 tests/lkdtm.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tests/lkdtm.c b/tests/lkdtm.c
index 2a40d18..856f060 100644
--- a/tests/lkdtm.c
+++ b/tests/lkdtm.c
@@ -52,6 +52,7 @@
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/hrtimer.h>
+#include <linux/ide.h>
 #include <scsi/scsi_cmnd.h>
 
 #define NUM_CPOINTS 8
-- 
1.5.6.3

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

* Re: linux-next: build failure
  2008-07-29 16:33           ` Linus Torvalds
  2008-07-29 16:42             ` Ingo Molnar
@ 2008-07-29 16:44             ` Linus Torvalds
  1 sibling, 0 replies; 96+ messages in thread
From: Linus Torvalds @ 2008-07-29 16:44 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: KOSAKI Motohiro, Stephen Rothwell, David Miller, linux-next,
	LKML, Andrew Morton, Mike Travis



On Tue, 29 Jul 2008, Linus Torvalds wrote:
>
>   [...]                           since statement expressions are gcc 
> extensions, and as such the gcc people could make up any semantics they 
> want to them, including just defining that a statement expression with 
> an lvalue value is the same lvalue rather than any temporary). 

In fact, that does seem what gcc-4.x does. The way to tell is to do

	const int *x;

	({ *x }) = 1;

and it's (a) legal (assignments to non-lvalues wouldn't work) and (b) 
gives a nice warning about assignment to read-only location, which in turn 
implies that the compiler properly just peeled off the de-reference even 
though it was inside the statement expression.

IOW, at least in gcc-4.3 (and apparently in earlier gcc-4 versions, but 
not in gcc-3.4.5), a statement expression with an lvalue return value _is_ 
actually an lvalue.

But that also means that there is no difference what-so-ever between (x) 
and ({ x; }) in gcc-4. And in gcc-3 there is, because apparently in gcc-3 
a statement expression is never an lvalue (which is actually the sane 
thing, imho).

			Linus

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

* Re: linux-next: build failure
  2008-07-29 16:33           ` Linus Torvalds
@ 2008-07-29 16:42             ` Ingo Molnar
  2008-07-29 16:44             ` Linus Torvalds
  1 sibling, 0 replies; 96+ messages in thread
From: Ingo Molnar @ 2008-07-29 16:42 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: KOSAKI Motohiro, Stephen Rothwell, David Miller, linux-next,
	LKML, Andrew Morton, Mike Travis


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> In contrast, "address-of lvalue" is _guaranteed_ to not do anything 
> stupid like that, and gives just the address-of.
> 
> Oh, and I was wrong about the &*x losing the 'const'. It doesn't. So I 
> think Stephen's patch is fine after all - if somebody tries to modify 
> the end result through the pointer, it will give a big compiler 
> warning.

yeah, both variants do that, i've checked it earlier today - i tried to 
find a way to get something more drastic than a compiler warning. (but 
failed)

	Ingo

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

* Re: linux-next: build failure
  2008-07-29 11:40         ` Ingo Molnar
  2008-07-29 14:31           ` Mike Travis
@ 2008-07-29 16:33           ` Linus Torvalds
  2008-07-29 16:42             ` Ingo Molnar
  2008-07-29 16:44             ` Linus Torvalds
  1 sibling, 2 replies; 96+ messages in thread
From: Linus Torvalds @ 2008-07-29 16:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: KOSAKI Motohiro, Stephen Rothwell, David Miller, linux-next,
	LKML, Andrew Morton, Mike Travis



On Tue, 29 Jul 2008, Ingo Molnar wrote:
> 
> the fix is simple enough.
> 
> but the question is, wont it generate huge artificial stackframes with 
> CONFIG_MAXSMP and NR_CPUS=4096?

Quite the reverse.

The "address-of statement expression" is the one that is more likely to 
generate artificial stack-frames because of a temporary variable (of 
course, I wouldn't count on it, since statement expressions are gcc 
extensions, and as such the gcc people could make up any semantics they 
want to them, including just defining that a statement expression with 
an lvalue value is the same lvalue rather than any temporary). 

In contrast, "address-of lvalue" is _guaranteed_ to not do anything stupid 
like that, and gives just the address-of.

Oh, and I was wrong about the &*x losing the 'const'. It doesn't. So I 
think Stephen's patch is fine after all - if somebody tries to modify the 
end result through the pointer, it will give a big compiler warning.

			Linus

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

* Re: linux-next: build failure
  2008-07-29  8:00 ` Ingo Molnar
  2008-07-29  8:03   ` Stephen Rothwell
  2008-07-29  8:14   ` Wenji Huang
@ 2008-07-29 16:26   ` Linus Torvalds
  2 siblings, 0 replies; 96+ messages in thread
From: Linus Torvalds @ 2008-07-29 16:26 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, David Miller, linux-next, LKML, Andrew Morton,
	Mike Travis



On Tue, 29 Jul 2008, Ingo Molnar wrote:
>
> > @@ -287,7 +287,7 @@ static inline const cpumask_t *get_cpu_mask(unsigned int cpu)
> >   * gcc optimizes it out (it's a constant) and there's no huge stack
> >   * variable created:
> >   */
> > -#define cpumask_of_cpu(cpu) ({ *get_cpu_mask(cpu); })
> > +#define cpumask_of_cpu(cpu) (*get_cpu_mask(cpu))
> 
> hm, i'm wondering - is this a compiler bug?

Not necessarily. The code is fragile.

Doing a statement expression basically creates a new temporary variable 
with pretty much undefined scope. Taking the address of it *may* be 
optimized away to the original cpu_mask pointer, but it's not really a 
well-defined operation: there really _is_ a local temporary variable, and 
if you were to change things through the address-of thing, gcc would be 
buggy if it had done the optimization.

So the "address-of statement expression" really is a dubious construct.

That said, the change that Stephen introduces is _not_ a no-op. It very 
fundamentally changes the code - exactly because now there is no temporary 
value created any more: it's a real lvalue, and now anybody who does 
&cpumask_of_cpu(cpu) will fundamentally get the original pointer back, 
except it has lost the "const".

And that's actually dangerous - exactly because it now loses the "const" 
thing, there may be people who end up modifying the result without 
getting any compile-time warnings.

I would _seriously_ suggest that both the original code and Stephen's 
modified version is really bad. And you should have taken my interface 
as-is - one that returns a "const cpumask_t *", and nothing else. 

Anything else is simply fundamentally broken.

			Linus

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

* Re: linux-next: build failure
  2008-07-29 14:31           ` Mike Travis
@ 2008-07-29 14:33             ` Mike Travis
  0 siblings, 0 replies; 96+ messages in thread
From: Mike Travis @ 2008-07-29 14:33 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: KOSAKI Motohiro, Stephen Rothwell, David Miller, linux-next,
	LKML, Andrew Morton, Linus

Mike Travis wrote:
> Ingo Molnar wrote:
>> * KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
>>
>>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>
>>>>> Hi Ingo,
>>>>>
>>>>> On Tue, 29 Jul 2008 10:00:55 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>>>>>>> -#define cpumask_of_cpu(cpu) ({ *get_cpu_mask(cpu); })
>>>>>>> +#define cpumask_of_cpu(cpu) (*get_cpu_mask(cpu))
>>>>>> hm, i'm wondering - is this a compiler bug?
>>>>> Or maybe a deficiency in such an old compiler (v3.4.5) but the fix 
>>>>> makes sense anyway, right?
>>>> yeah, i was just wondering.
>>> in linux/README
>>>
>>> COMPILING the kernel:
>>>
>>>  - Make sure you have at least gcc 3.2 available.
>>>    For more information, refer to Documentation/Changes.
>>>
>>> So, if 3.4.5 is old, Should we change readme?
>> the fix is simple enough.
>>
>> but the question is, wont it generate huge artificial stackframes with 
>> CONFIG_MAXSMP and NR_CPUS=4096? Maybe it is unable to figure out and 
>> simplify the arithmetics there - or something like that.
>>
>> 	Ingo
> 
> I've looked at stack frames quite extensively and usually they are
> not generated unless you explicitly use a named cpumask variable,
> pass a cpumask by value, expect a cpumask function return, create
> an initializer that contains a cpumask field, and (probably a couple
> more I missed).
> 
> Almost all others are done efficiently via pointers or simple
> struct copies:
> 
> 	cpus_xxx(*cpumask_of_cpu(), ...
> 	struct->cpumask_var = *cpumask_of_cpu()
> 	global_cpumask_var = *cpumask_of_cpu()
> 	etc.
> 
> Thanks,
> Mike

Geez, I edited the above after I first used *cpumask_var and didn't
get the semantics right!

 	cpus_xxx(cpumask_of_cpu(), ...
 	struct->cpumask_var = cpumask_of_cpu()
 	global_cpumask_var = cpumask_of_cpu()

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

* Re: linux-next: build failure
  2008-07-29 11:40         ` Ingo Molnar
@ 2008-07-29 14:31           ` Mike Travis
  2008-07-29 14:33             ` Mike Travis
  2008-07-29 16:33           ` Linus Torvalds
  1 sibling, 1 reply; 96+ messages in thread
From: Mike Travis @ 2008-07-29 14:31 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: KOSAKI Motohiro, Stephen Rothwell, David Miller, linux-next,
	LKML, Andrew Morton, Linus

Ingo Molnar wrote:
> * KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> 
>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>>> Hi Ingo,
>>>>
>>>> On Tue, 29 Jul 2008 10:00:55 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>>>>>> -#define cpumask_of_cpu(cpu) ({ *get_cpu_mask(cpu); })
>>>>>> +#define cpumask_of_cpu(cpu) (*get_cpu_mask(cpu))
>>>>> hm, i'm wondering - is this a compiler bug?
>>>> Or maybe a deficiency in such an old compiler (v3.4.5) but the fix 
>>>> makes sense anyway, right?
>>> yeah, i was just wondering.
>> in linux/README
>>
>> COMPILING the kernel:
>>
>>  - Make sure you have at least gcc 3.2 available.
>>    For more information, refer to Documentation/Changes.
>>
>> So, if 3.4.5 is old, Should we change readme?
> 
> the fix is simple enough.
> 
> but the question is, wont it generate huge artificial stackframes with 
> CONFIG_MAXSMP and NR_CPUS=4096? Maybe it is unable to figure out and 
> simplify the arithmetics there - or something like that.
> 
> 	Ingo

I've looked at stack frames quite extensively and usually they are
not generated unless you explicitly use a named cpumask variable,
pass a cpumask by value, expect a cpumask function return, create
an initializer that contains a cpumask field, and (probably a couple
more I missed).

Almost all others are done efficiently via pointers or simple
struct copies:

	cpus_xxx(*cpumask_of_cpu(), ...
	struct->cpumask_var = *cpumask_of_cpu()
	global_cpumask_var = *cpumask_of_cpu()
	etc.

Thanks,
Mike

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

* Re: linux-next: build failure
  2008-07-29 11:28       ` KOSAKI Motohiro
@ 2008-07-29 11:40         ` Ingo Molnar
  2008-07-29 14:31           ` Mike Travis
  2008-07-29 16:33           ` Linus Torvalds
  0 siblings, 2 replies; 96+ messages in thread
From: Ingo Molnar @ 2008-07-29 11:40 UTC (permalink / raw)
  To: KOSAKI Motohiro
  Cc: Stephen Rothwell, David Miller, linux-next, LKML, Andrew Morton,
	Linus, Mike Travis


* KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:

> > 
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > > Hi Ingo,
> > > 
> > > On Tue, 29 Jul 2008 10:00:55 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> > > >
> > > > > -#define cpumask_of_cpu(cpu) ({ *get_cpu_mask(cpu); })
> > > > > +#define cpumask_of_cpu(cpu) (*get_cpu_mask(cpu))
> > > > 
> > > > hm, i'm wondering - is this a compiler bug?
> > > 
> > > Or maybe a deficiency in such an old compiler (v3.4.5) but the fix 
> > > makes sense anyway, right?
> > 
> > yeah, i was just wondering.
> 
> in linux/README
> 
> COMPILING the kernel:
> 
>  - Make sure you have at least gcc 3.2 available.
>    For more information, refer to Documentation/Changes.
> 
> So, if 3.4.5 is old, Should we change readme?

the fix is simple enough.

but the question is, wont it generate huge artificial stackframes with 
CONFIG_MAXSMP and NR_CPUS=4096? Maybe it is unable to figure out and 
simplify the arithmetics there - or something like that.

	Ingo

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

* Re: linux-next: build failure
  2008-07-29  8:58     ` Ingo Molnar
@ 2008-07-29 11:28       ` KOSAKI Motohiro
  2008-07-29 11:40         ` Ingo Molnar
  0 siblings, 1 reply; 96+ messages in thread
From: KOSAKI Motohiro @ 2008-07-29 11:28 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: kosaki.motohiro, Stephen Rothwell, David Miller, linux-next,
	LKML, Andrew Morton, Linus, Mike Travis

> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi Ingo,
> > 
> > On Tue, 29 Jul 2008 10:00:55 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> > >
> > > > -#define cpumask_of_cpu(cpu) ({ *get_cpu_mask(cpu); })
> > > > +#define cpumask_of_cpu(cpu) (*get_cpu_mask(cpu))
> > > 
> > > hm, i'm wondering - is this a compiler bug?
> > 
> > Or maybe a deficiency in such an old compiler (v3.4.5) but the fix 
> > makes sense anyway, right?
> 
> yeah, i was just wondering.

in linux/README

COMPILING the kernel:

 - Make sure you have at least gcc 3.2 available.
   For more information, refer to Documentation/Changes.



So, if 3.4.5 is old, Should we change readme?

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

* Re: linux-next: build failure
  2008-07-29  8:03   ` Stephen Rothwell
@ 2008-07-29  8:58     ` Ingo Molnar
  2008-07-29 11:28       ` KOSAKI Motohiro
  0 siblings, 1 reply; 96+ messages in thread
From: Ingo Molnar @ 2008-07-29  8:58 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, linux-next, LKML, Andrew Morton, Linus, Mike Travis


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Ingo,
> 
> On Tue, 29 Jul 2008 10:00:55 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > > -#define cpumask_of_cpu(cpu) ({ *get_cpu_mask(cpu); })
> > > +#define cpumask_of_cpu(cpu) (*get_cpu_mask(cpu))
> > 
> > hm, i'm wondering - is this a compiler bug?
> 
> Or maybe a deficiency in such an old compiler (v3.4.5) but the fix 
> makes sense anyway, right?

yeah, i was just wondering.

	Ingo

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

* Re: linux-next: build failure
  2008-07-29  8:00 ` Ingo Molnar
  2008-07-29  8:03   ` Stephen Rothwell
@ 2008-07-29  8:14   ` Wenji Huang
  2008-07-29 16:26   ` Linus Torvalds
  2 siblings, 0 replies; 96+ messages in thread
From: Wenji Huang @ 2008-07-29  8:14 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, David Miller, linux-next, LKML, Andrew Morton,
	Linus, Mike Travis

Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
>> Hi Dave,
>>
>> Today's linux-next build (sparc64 defconfig) failed like this:
>>
>> kernel/time/tick-common.c: In function `tick_check_new_device':
>> kernel/time/tick-common.c:210: error: invalid lvalue in unary `&'
>> kernel/time/tick-common.c:223: error: invalid lvalue in unary `&'
>> kernel/time/tick-common.c:255: error: invalid lvalue in unary `&'
>>
>> gcc is version 3.4.5 sparc64 cross compiler (powercp64 host).
>>
>> The below patch fixes it.
>>
>> when you take the address of the result.  Noticed on a sparc64 compile
>> using a version 3.4.5 cross compiler.
>>
>> kernel/time/tick-common.c: In function `tick_check_new_device':
>> kernel/time/tick-common.c:210: error: invalid lvalue in unary `&'
>> kernel/time/tick-common.c:223: error: invalid lvalue in unary `&'
>> kernel/time/tick-common.c:255: error: invalid lvalue in unary `&'
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>>  include/linux/cpumask.h |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
>> index 96d0509..d3219d7 100644
>> --- a/include/linux/cpumask.h
>> +++ b/include/linux/cpumask.h
>> @@ -287,7 +287,7 @@ static inline const cpumask_t *get_cpu_mask(unsigned int cpu)
>>   * gcc optimizes it out (it's a constant) and there's no huge stack
>>   * variable created:
>>   */
>> -#define cpumask_of_cpu(cpu) ({ *get_cpu_mask(cpu); })
>> +#define cpumask_of_cpu(cpu) (*get_cpu_mask(cpu))
> 
> hm, i'm wondering - is this a compiler bug?
> 
> 	Ingo

Same problem on x86/gcc 3.4.6, but will pass on gcc 4.x

Regards,
Wenji

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

* Re: linux-next: build failure
  2008-07-29  8:00 ` Ingo Molnar
@ 2008-07-29  8:03   ` Stephen Rothwell
  2008-07-29  8:58     ` Ingo Molnar
  2008-07-29  8:14   ` Wenji Huang
  2008-07-29 16:26   ` Linus Torvalds
  2 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2008-07-29  8:03 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: David Miller, linux-next, LKML, Andrew Morton, Linus, Mike Travis

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

Hi Ingo,

On Tue, 29 Jul 2008 10:00:55 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> > -#define cpumask_of_cpu(cpu) ({ *get_cpu_mask(cpu); })
> > +#define cpumask_of_cpu(cpu) (*get_cpu_mask(cpu))
> 
> hm, i'm wondering - is this a compiler bug?

Or maybe a deficiency in such an old compiler (v3.4.5) but the fix makes
sense anyway, right?

-- 
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] 96+ messages in thread

* Re: linux-next: build failure
  2008-07-29  6:23 Stephen Rothwell
@ 2008-07-29  8:00 ` Ingo Molnar
  2008-07-29  8:03   ` Stephen Rothwell
                     ` (2 more replies)
  0 siblings, 3 replies; 96+ messages in thread
From: Ingo Molnar @ 2008-07-29  8:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, linux-next, LKML, Andrew Morton, Linus, Mike Travis


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Dave,
> 
> Today's linux-next build (sparc64 defconfig) failed like this:
> 
> kernel/time/tick-common.c: In function `tick_check_new_device':
> kernel/time/tick-common.c:210: error: invalid lvalue in unary `&'
> kernel/time/tick-common.c:223: error: invalid lvalue in unary `&'
> kernel/time/tick-common.c:255: error: invalid lvalue in unary `&'
> 
> gcc is version 3.4.5 sparc64 cross compiler (powercp64 host).
> 
> The below patch fixes it.
>
> when you take the address of the result.  Noticed on a sparc64 compile
> using a version 3.4.5 cross compiler.
> 
> kernel/time/tick-common.c: In function `tick_check_new_device':
> kernel/time/tick-common.c:210: error: invalid lvalue in unary `&'
> kernel/time/tick-common.c:223: error: invalid lvalue in unary `&'
> kernel/time/tick-common.c:255: error: invalid lvalue in unary `&'
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  include/linux/cpumask.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
> index 96d0509..d3219d7 100644
> --- a/include/linux/cpumask.h
> +++ b/include/linux/cpumask.h
> @@ -287,7 +287,7 @@ static inline const cpumask_t *get_cpu_mask(unsigned int cpu)
>   * gcc optimizes it out (it's a constant) and there's no huge stack
>   * variable created:
>   */
> -#define cpumask_of_cpu(cpu) ({ *get_cpu_mask(cpu); })
> +#define cpumask_of_cpu(cpu) (*get_cpu_mask(cpu))

hm, i'm wondering - is this a compiler bug?

	Ingo

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

* linux-next: build failure
@ 2008-07-29  6:23 Stephen Rothwell
  2008-07-29  8:00 ` Ingo Molnar
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2008-07-29  6:23 UTC (permalink / raw)
  To: David Miller
  Cc: linux-next, LKML, Andrew Morton, Linus, Mike Travis, Ingo Molnar

Hi Dave,

Today's linux-next build (sparc64 defconfig) failed like this:

kernel/time/tick-common.c: In function `tick_check_new_device':
kernel/time/tick-common.c:210: error: invalid lvalue in unary `&'
kernel/time/tick-common.c:223: error: invalid lvalue in unary `&'
kernel/time/tick-common.c:255: error: invalid lvalue in unary `&'

gcc is version 3.4.5 sparc64 cross compiler (powercp64 host).

The below patch fixes it.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 29 Jul 2008 16:07:37 +1000
Subject: [PATCH] cpumask: statement expressions confuse some versions of gcc

when you take the address of the result.  Noticed on a sparc64 compile
using a version 3.4.5 cross compiler.

kernel/time/tick-common.c: In function `tick_check_new_device':
kernel/time/tick-common.c:210: error: invalid lvalue in unary `&'
kernel/time/tick-common.c:223: error: invalid lvalue in unary `&'
kernel/time/tick-common.c:255: error: invalid lvalue in unary `&'

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/cpumask.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 96d0509..d3219d7 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -287,7 +287,7 @@ static inline const cpumask_t *get_cpu_mask(unsigned int cpu)
  * gcc optimizes it out (it's a constant) and there's no huge stack
  * variable created:
  */
-#define cpumask_of_cpu(cpu) ({ *get_cpu_mask(cpu); })
+#define cpumask_of_cpu(cpu) (*get_cpu_mask(cpu))
 
 
 #define CPU_MASK_LAST_WORD BITMAP_LAST_WORD_MASK(NR_CPUS)
-- 
1.5.6.3

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

* linux-next: build failure
@ 2008-07-28  5:07 Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-07-28  5:07 UTC (permalink / raw)
  To: Andrew Vasquez; +Cc: linux-next, LKML, James Bottomley, David S. Miller

Hi James, Andrew,

(Previously reported by Dave Miller.)

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

drivers/scsi/qla2xxx/qla_attr.c: In function 'qla24xx_vport_delete':
drivers/scsi/qla2xxx/qla_attr.c:1184: error: implicit declaration of function 'msleep'

I applied the patch below.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

>From 879b13261ee593b8afcae80a33844f162e8e8a5c Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 28 Jul 2008 15:02:35 +1000
Subject: [PATCH] scsi: msleep is declared in delay.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/scsi/qla2xxx/qla_attr.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c
index 7a4409a..a319a20 100644
--- a/drivers/scsi/qla2xxx/qla_attr.c
+++ b/drivers/scsi/qla2xxx/qla_attr.c
@@ -8,6 +8,7 @@
 
 #include <linux/kthread.h>
 #include <linux/vmalloc.h>
+#include <linux/delay.h>
 
 static int qla24xx_vport_disable(struct fc_vport *, bool);
 
-- 
1.5.6.3

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

* linux-next: build failure
@ 2008-07-28  4:44 Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-07-28  4:44 UTC (permalink / raw)
  To: Karsten Keil; +Cc: linux-next, LKML, David S. Miller

Hi Karsten,

(Previously reported by Dave Miller for Sparc)

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

drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not running on big endian machines now"

I just disabled it using the patch below.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

>From c4f3c0cba3811f71465c332fe36fe30b3b17f507 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 28 Jul 2008 14:38:29 +1000
Subject: [PATCH] hfcmulti is not supported on big endian

So stick it to X86 for now.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/isdn/hardware/mISDN/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/isdn/hardware/mISDN/Kconfig b/drivers/isdn/hardware/mISDN/Kconfig
index 9cd5f5f..1a78575 100644
--- a/drivers/isdn/hardware/mISDN/Kconfig
+++ b/drivers/isdn/hardware/mISDN/Kconfig
@@ -16,6 +16,7 @@ config MISDN_HFCMULTI
 	tristate "Support for HFC multiport cards (HFC-4S/8S/E1)"
 	depends on PCI
 	depends on MISDN
+	depends on X86
 	help
 	  Enable support for cards with Cologne Chip AG's HFC multiport
 	  chip. There are three types of chips that are quite similar,
-- 
1.5.6.3

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

* linux-next: build failure
@ 2008-07-25  6:45 Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-07-25  6:45 UTC (permalink / raw)
  To: linux-next; +Cc: Andrew Morton

Hi all,

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

mm/migrate.c: In function 'remove_migration_pte':
mm/migrate.c:195: error: implicit declaration of function 'update_mmu_cache'

I applied the patch below from Benjamin Herrenschmidt (which he will send
to Linus).

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

>From 1e3519f8e1baec0b733cd42684fcd3d9681662f1 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 25 Jul 2008 16:21:11 +1000
Subject: [PATCH] Move update_mmu_cache() declaration from tlbflush.h to pgtable.h
where it belongs. This fixes some build problems on some configs

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
 include/asm-powerpc/pgtable.h  |   13 +++++++++++++
 include/asm-powerpc/tlbflush.h |   11 -----------
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/include/asm-powerpc/pgtable.h b/include/asm-powerpc/pgtable.h
index d18ffe7..dbb8ca1 100644
--- a/include/asm-powerpc/pgtable.h
+++ b/include/asm-powerpc/pgtable.h
@@ -38,6 +38,19 @@ extern void paging_init(void);
 		remap_pfn_range(vma, vaddr, pfn, size, prot)
 
 #include <asm-generic/pgtable.h>
+
+
+/*
+ * This gets called at the end of handling a page fault, when
+ * the kernel has put a new PTE into the page table for the process.
+ * We use it to ensure coherency between the i-cache and d-cache
+ * for the page which has just been mapped in.
+ * On machines which use an MMU hash table, we use this to put a
+ * corresponding HPTE into the hash table ahead of time, instead of
+ * waiting for the inevitable extra hash-table miss exception.
+ */
+extern void update_mmu_cache(struct vm_area_struct *, unsigned long, pte_t);
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* __KERNEL__ */
diff --git a/include/asm-powerpc/tlbflush.h b/include/asm-powerpc/tlbflush.h
index 5c91081..361cd5c 100644
--- a/include/asm-powerpc/tlbflush.h
+++ b/include/asm-powerpc/tlbflush.h
@@ -162,16 +162,5 @@ extern void __flush_hash_table_range(struct mm_struct *mm, unsigned long start,
 
 #endif
 
-/*
- * This gets called at the end of handling a page fault, when
- * the kernel has put a new PTE into the page table for the process.
- * We use it to ensure coherency between the i-cache and d-cache
- * for the page which has just been mapped in.
- * On machines which use an MMU hash table, we use this to put a
- * corresponding HPTE into the hash table ahead of time, instead of
- * waiting for the inevitable extra hash-table miss exception.
- */
-extern void update_mmu_cache(struct vm_area_struct *, unsigned long, pte_t);
-
 #endif /*__KERNEL__ */
 #endif /* _ASM_POWERPC_TLBFLUSH_H */
-- 
1.5.2.4122.g5cc8f-dirty

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

* Re: linux-next: build failure
  2008-06-30 15:49   ` Randy Dunlap
@ 2008-06-30 23:30     ` Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-06-30 23:30 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Sam Ravnborg, linux-next, Thomas Gleixner, Ingo Molnar, H. Peter Anvin

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

Hi Randy,

On Mon, 30 Jun 2008 08:49:12 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
> On Mon, 30 Jun 2008 08:12:39 -0700 Randy Dunlap wrote:
> 
> > All (ALL) of my randconfig builds on i386 and x86_64 are failing like this.
> 
> I should have said:
> 
> I'm using the daily patch*bz2 file, not git.
> And I'm using O= for output.
> When not using O=, the build does not have this problem.

Thanks for the report.  The patches are generated from the git tree so
should give you a tree with identical content.

I also use O= for all my builds.  Though my x86_64 allmodconfig builds
worked.

-- 
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] 96+ messages in thread

* Re: linux-next: build failure
  2008-06-30 16:10 ` Sam Ravnborg
@ 2008-06-30 16:44   ` Randy Dunlap
  0 siblings, 0 replies; 96+ messages in thread
From: Randy Dunlap @ 2008-06-30 16:44 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: Stephen Rothwell, linux-next, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin

On Mon, 30 Jun 2008 18:10:20 +0200 Sam Ravnborg wrote:

> On Mon, Jun 30, 2008 at 11:22:48PM +1000, Stephen Rothwell wrote:
> > Hi Sam,
> > 
> > Today's linux-next build (i386 defconfig) failed like this:
> > 
> >   GEN     /scratch/sfr/i386_defconfig/Makefile
> >   GEN     /scratch/sfr/i386_defconfig/Makefile
> >   SYMLINK include/asm -> include/asm-x86
> >   Using /scratch/sfr/next as source for kernel
> > /bin/sh: include/asm/asm-offsets.h: No such file or directory
> > 
> > I can only guess that this is a kbuild problem.  The object include directory
> > looked like this:
> > 
> > /scratch/sfr/i386_defconfig/include$ ls -la
> > total 24
> > drwxr-xr-x   5 sfr users 4096 2008-06-30 23:06 .
> > drwxr-xr-x   8 sfr users 4096 2008-06-30 23:06 ..
> > lrwxrwxrwx   1 sfr users    7 2008-06-30 23:06 asm -> asm-x86
> > drwxr-xr-x   2 sfr users 4096 2008-06-30 23:06 asm-i386
> > drwxr-xr-x 184 sfr users 8192 2008-06-30 23:06 config
> > drwxr-xr-x   2 sfr users 4096 2008-06-30 23:06 linux
> 
> The directory "asm-i386" should have been asm-x86.
> My bad.
> 
> This fixes it for me:
> 
> diff --git a/Makefile b/Makefile
> index 9edbdab..f2c181a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -968,8 +968,8 @@ endef
>  define create-symlink
>  	if [ ! -L include/asm ]; then                                      \
>  			echo '  SYMLINK $@ -> include/asm-$(SRCARCH)';     \
> -			if [ ! -d include/asm-$(ARCH) ]; then              \
> -				mkdir -p include/asm-$(ARCH);              \
> +			if [ ! -d include/asm-$(SRCARCH) ]; then           \
> +				mkdir -p include/asm-$(SRCARCH);           \
>  			fi;                                                \
>  			ln -fsn asm-$(SRCARCH) $@;                         \
>  	fi
> 
> 
> I have tested arm with O=... but i386 I tested without O=...
> and I obviosuly forgot to think when I did the above :-(
> 
> I will rebase kbuild-next.git later today to integrate this fix.

Thanks.  That fix is working for me.

---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/

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

* Re: linux-next: build failure
  2008-06-30 13:22 Stephen Rothwell
  2008-06-30 14:06 ` Ingo Molnar
  2008-06-30 15:12 ` Randy Dunlap
@ 2008-06-30 16:10 ` Sam Ravnborg
  2008-06-30 16:44   ` Randy Dunlap
  2 siblings, 1 reply; 96+ messages in thread
From: Sam Ravnborg @ 2008-06-30 16:10 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, Thomas Gleixner, Ingo Molnar, H. Peter Anvin

On Mon, Jun 30, 2008 at 11:22:48PM +1000, Stephen Rothwell wrote:
> Hi Sam,
> 
> Today's linux-next build (i386 defconfig) failed like this:
> 
>   GEN     /scratch/sfr/i386_defconfig/Makefile
>   GEN     /scratch/sfr/i386_defconfig/Makefile
>   SYMLINK include/asm -> include/asm-x86
>   Using /scratch/sfr/next as source for kernel
> /bin/sh: include/asm/asm-offsets.h: No such file or directory
> 
> I can only guess that this is a kbuild problem.  The object include directory
> looked like this:
> 
> /scratch/sfr/i386_defconfig/include$ ls -la
> total 24
> drwxr-xr-x   5 sfr users 4096 2008-06-30 23:06 .
> drwxr-xr-x   8 sfr users 4096 2008-06-30 23:06 ..
> lrwxrwxrwx   1 sfr users    7 2008-06-30 23:06 asm -> asm-x86
> drwxr-xr-x   2 sfr users 4096 2008-06-30 23:06 asm-i386
> drwxr-xr-x 184 sfr users 8192 2008-06-30 23:06 config
> drwxr-xr-x   2 sfr users 4096 2008-06-30 23:06 linux

The directory "asm-i386" should have been asm-x86.
My bad.

This fixes it for me:

diff --git a/Makefile b/Makefile
index 9edbdab..f2c181a 100644
--- a/Makefile
+++ b/Makefile
@@ -968,8 +968,8 @@ endef
 define create-symlink
 	if [ ! -L include/asm ]; then                                      \
 			echo '  SYMLINK $@ -> include/asm-$(SRCARCH)';     \
-			if [ ! -d include/asm-$(ARCH) ]; then              \
-				mkdir -p include/asm-$(ARCH);              \
+			if [ ! -d include/asm-$(SRCARCH) ]; then           \
+				mkdir -p include/asm-$(SRCARCH);           \
 			fi;                                                \
 			ln -fsn asm-$(SRCARCH) $@;                         \
 	fi


I have tested arm with O=... but i386 I tested without O=...
and I obviosuly forgot to think when I did the above :-(

I will rebase kbuild-next.git later today to integrate this fix.

	Sam

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

* Re: linux-next: build failure
  2008-06-30 15:12 ` Randy Dunlap
@ 2008-06-30 15:49   ` Randy Dunlap
  2008-06-30 23:30     ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Randy Dunlap @ 2008-06-30 15:49 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, Sam Ravnborg, linux-next, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin

On Mon, 30 Jun 2008 08:12:39 -0700 Randy Dunlap wrote:

> On Mon, 30 Jun 2008 23:22:48 +1000 Stephen Rothwell wrote:
> 
> > Hi Sam,
> > 
> > Today's linux-next build (i386 defconfig) failed like this:
> > 
> >   GEN     /scratch/sfr/i386_defconfig/Makefile
> >   GEN     /scratch/sfr/i386_defconfig/Makefile
> >   SYMLINK include/asm -> include/asm-x86
> >   Using /scratch/sfr/next as source for kernel
> > /bin/sh: include/asm/asm-offsets.h: No such file or directory
> 
> All (ALL) of my randconfig builds on i386 and x86_64 are failing like this.

I should have said:

I'm using the daily patch*bz2 file, not git.
And I'm using O= for output.
When not using O=, the build does not have this problem.


> 
> > I can only guess that this is a kbuild problem.  The object include directory
> > looked like this:
> > 
> > /scratch/sfr/i386_defconfig/include$ ls -la
> > total 24
> > drwxr-xr-x   5 sfr users 4096 2008-06-30 23:06 .
> > drwxr-xr-x   8 sfr users 4096 2008-06-30 23:06 ..
> > lrwxrwxrwx   1 sfr users    7 2008-06-30 23:06 asm -> asm-x86
> > drwxr-xr-x   2 sfr users 4096 2008-06-30 23:06 asm-i386
> > drwxr-xr-x 184 sfr users 8192 2008-06-30 23:06 config
> > drwxr-xr-x   2 sfr users 4096 2008-06-30 23:06 linux
> > 
> > My powerpc (ppc64_defconfig, allnoconfig, allyesconfig and
> > ppc44x_deconfig), x86_64 (allmodconfig), sparc (defconfig) and sparc64
> > (defconfig) build all worked.  The kisskb overnight builds will show us
> > what else is broken.


---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/

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

* Re: linux-next: build failure
  2008-06-30 13:22 Stephen Rothwell
  2008-06-30 14:06 ` Ingo Molnar
@ 2008-06-30 15:12 ` Randy Dunlap
  2008-06-30 15:49   ` Randy Dunlap
  2008-06-30 16:10 ` Sam Ravnborg
  2 siblings, 1 reply; 96+ messages in thread
From: Randy Dunlap @ 2008-06-30 15:12 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Sam Ravnborg, linux-next, Thomas Gleixner, Ingo Molnar, H. Peter Anvin

On Mon, 30 Jun 2008 23:22:48 +1000 Stephen Rothwell wrote:

> Hi Sam,
> 
> Today's linux-next build (i386 defconfig) failed like this:
> 
>   GEN     /scratch/sfr/i386_defconfig/Makefile
>   GEN     /scratch/sfr/i386_defconfig/Makefile
>   SYMLINK include/asm -> include/asm-x86
>   Using /scratch/sfr/next as source for kernel
> /bin/sh: include/asm/asm-offsets.h: No such file or directory

All (ALL) of my randconfig builds on i386 and x86_64 are failing like this.


> I can only guess that this is a kbuild problem.  The object include directory
> looked like this:
> 
> /scratch/sfr/i386_defconfig/include$ ls -la
> total 24
> drwxr-xr-x   5 sfr users 4096 2008-06-30 23:06 .
> drwxr-xr-x   8 sfr users 4096 2008-06-30 23:06 ..
> lrwxrwxrwx   1 sfr users    7 2008-06-30 23:06 asm -> asm-x86
> drwxr-xr-x   2 sfr users 4096 2008-06-30 23:06 asm-i386
> drwxr-xr-x 184 sfr users 8192 2008-06-30 23:06 config
> drwxr-xr-x   2 sfr users 4096 2008-06-30 23:06 linux
> 
> My powerpc (ppc64_defconfig, allnoconfig, allyesconfig and
> ppc44x_deconfig), x86_64 (allmodconfig), sparc (defconfig) and sparc64
> (defconfig) build all worked.  The kisskb overnight builds will show us
> what else is broken.


---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/

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

* Re: linux-next: build failure
  2008-06-30 14:06 ` Ingo Molnar
@ 2008-06-30 14:46   ` Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-06-30 14:46 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Sam Ravnborg, linux-next, Thomas Gleixner, H. Peter Anvin

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

Hi Ingo,

On Mon, 30 Jun 2008 16:06:44 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> hm, there's no known (or even any recently fixed) kbuild related problem 
> in the stuff that comes towards linux-next from -tip. I've done an 
> integration run earlier today - have you already picked that up?

No, I collected all the trees at about 9:30 am my time i.e. about 15
hours ago.

However, there have been several changes in this area in the kbuild tree
over the past few days ...

-- 
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] 96+ messages in thread

* Re: linux-next: build failure
  2008-06-30 13:22 Stephen Rothwell
@ 2008-06-30 14:06 ` Ingo Molnar
  2008-06-30 14:46   ` Stephen Rothwell
  2008-06-30 15:12 ` Randy Dunlap
  2008-06-30 16:10 ` Sam Ravnborg
  2 siblings, 1 reply; 96+ messages in thread
From: Ingo Molnar @ 2008-06-30 14:06 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Sam Ravnborg, linux-next, Thomas Gleixner, H. Peter Anvin


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Sam,
> 
> Today's linux-next build (i386 defconfig) failed like this:
> 
>   GEN     /scratch/sfr/i386_defconfig/Makefile
>   GEN     /scratch/sfr/i386_defconfig/Makefile
>   SYMLINK include/asm -> include/asm-x86
>   Using /scratch/sfr/next as source for kernel
> /bin/sh: include/asm/asm-offsets.h: No such file or directory
> 
> I can only guess that this is a kbuild problem.  The object include 
> directory looked like this:
> 
> /scratch/sfr/i386_defconfig/include$ ls -la
> total 24
> drwxr-xr-x   5 sfr users 4096 2008-06-30 23:06 .
> drwxr-xr-x   8 sfr users 4096 2008-06-30 23:06 ..
> lrwxrwxrwx   1 sfr users    7 2008-06-30 23:06 asm -> asm-x86
> drwxr-xr-x   2 sfr users 4096 2008-06-30 23:06 asm-i386
> drwxr-xr-x 184 sfr users 8192 2008-06-30 23:06 config
> drwxr-xr-x   2 sfr users 4096 2008-06-30 23:06 linux
> 
> My powerpc (ppc64_defconfig, allnoconfig, allyesconfig and 
> ppc44x_deconfig), x86_64 (allmodconfig), sparc (defconfig) and sparc64 
> (defconfig) build all worked.  The kisskb overnight builds will show 
> us what else is broken.

hm, there's no known (or even any recently fixed) kbuild related problem 
in the stuff that comes towards linux-next from -tip. I've done an 
integration run earlier today - have you already picked that up?

	Ingo

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

* linux-next: build failure
@ 2008-06-30 13:22 Stephen Rothwell
  2008-06-30 14:06 ` Ingo Molnar
                   ` (2 more replies)
  0 siblings, 3 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-06-30 13:22 UTC (permalink / raw)
  To: Sam Ravnborg; +Cc: linux-next, Thomas Gleixner, Ingo Molnar, H. Peter Anvin

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

Hi Sam,

Today's linux-next build (i386 defconfig) failed like this:

  GEN     /scratch/sfr/i386_defconfig/Makefile
  GEN     /scratch/sfr/i386_defconfig/Makefile
  SYMLINK include/asm -> include/asm-x86
  Using /scratch/sfr/next as source for kernel
/bin/sh: include/asm/asm-offsets.h: No such file or directory

I can only guess that this is a kbuild problem.  The object include directory
looked like this:

/scratch/sfr/i386_defconfig/include$ ls -la
total 24
drwxr-xr-x   5 sfr users 4096 2008-06-30 23:06 .
drwxr-xr-x   8 sfr users 4096 2008-06-30 23:06 ..
lrwxrwxrwx   1 sfr users    7 2008-06-30 23:06 asm -> asm-x86
drwxr-xr-x   2 sfr users 4096 2008-06-30 23:06 asm-i386
drwxr-xr-x 184 sfr users 8192 2008-06-30 23:06 config
drwxr-xr-x   2 sfr users 4096 2008-06-30 23:06 linux

My powerpc (ppc64_defconfig, allnoconfig, allyesconfig and
ppc44x_deconfig), x86_64 (allmodconfig), sparc (defconfig) and sparc64
(defconfig) build all worked.  The kisskb overnight builds will show us
what else is broken.

-- 
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] 96+ messages in thread

* Re: linux-next: build failure
       [not found] <20080512154717.2d0947f0.sfr@canb.auug.org.au>
  2008-05-12  7:54 ` David Miller
@ 2008-05-12 16:50 ` Greg KH
  1 sibling, 0 replies; 96+ messages in thread
From: Greg KH @ 2008-05-12 16:50 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, Kay Sievers, David Miller

On Mon, May 12, 2008 at 03:47:17PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next build (sparc64 defconfig) fails like this:
> 
> arch/sparc64/kernel/pci.c: In function `of_create_pci_dev':
> arch/sparc64/kernel/pci.c:412: warning: passing arg 1 of `sprintf' discards qualifiers from pointer target type
> make[2]: *** [arch/sparc64/kernel/pci.o] Error 1
> 
> (I assume sparc64 builds with -Werr)
> 
> This started on May 8 with the introduction of "driver-core: prepare for
> removal of 20 char limit from struct device".
> 
> The sparc64 pci code above looks like this:
> 
> 	sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
> 		dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));

This is my fault, I've dropped the offending patch from my queue right
now, will add it back in when I have the cross-compilers set up locally
to prevent this from happening in the future.

My appologies,

greg k-h

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

* Re: linux-next: build failure
  2008-05-12  8:53       ` David Miller
@ 2008-05-12 10:42         ` Stephen Rothwell
  0 siblings, 0 replies; 96+ messages in thread
From: Stephen Rothwell @ 2008-05-12 10:42 UTC (permalink / raw)
  To: David Miller; +Cc: greg, linux-next, kay.sievers

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

Hi Dave,

On Mon, 12 May 2008 01:53:49 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> :-)  The fix is likely something like this:
> 
> diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
> index 5275074..776703e 100644
> --- a/arch/powerpc/kernel/pci_64.c
> +++ b/arch/powerpc/kernel/pci_64.c
> @@ -189,8 +189,8 @@ struct pci_dev *of_create_pci_dev(struct device_node *node,
>  
>  	dev->cfg_size = pci_cfg_space_size(dev);
>  
> -	sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
> -		dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
> +	dev_set_name(&dev->dev, "%04x:%02x:%02x.%d", pci_domain_nr(bus),
> +		     dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
>  	dev->class = get_int_prop(node, "class-code", 0);
>  	dev->revision = get_int_prop(node, "revision-id", 0);
>  
> diff --git a/arch/sparc64/kernel/pci.c b/arch/sparc64/kernel/pci.c
> index 112b09f..bfc8c5d 100644
> --- a/arch/sparc64/kernel/pci.c
> +++ b/arch/sparc64/kernel/pci.c
> @@ -408,8 +408,8 @@ struct pci_dev *of_create_pci_dev(struct pci_pbm_info *pbm,
>  	dev->class = class >> 8;
>  	dev->revision = class & 0xff;
>  
> -	sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
> -		dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
> +	dev_set_name(&dev->dev, "%04x:%02x:%02x.%d", pci_domain_nr(bus),
> +		     dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
>  
>  	if (ofpci_verbose)
>  		printk("    class: 0x%x device name: %s\n",
> 

Thanks.  If there is nothing in Greg's tree tomorrow I will apply this
temporarily.

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

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

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

* Re: linux-next: build failure
  2008-05-12  8:15     ` Stephen Rothwell
@ 2008-05-12  8:53       ` David Miller
  2008-05-12 10:42         ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: David Miller @ 2008-05-12  8:53 UTC (permalink / raw)
  To: sfr; +Cc: greg, linux-next, kay.sievers

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 12 May 2008 18:15:57 +1000

> Hi Dave,
> 
> On Mon, 12 May 2008 18:09:03 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Mon, 12 May 2008 00:54:54 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> > >
> > > There is identical code in arch/powerpc/kernel/pci_64.c, it doesn't
> > > break the build there becuase powerpc doesn't use -Werror (yet) :-)
> > 
> > OK, I will look for your fix and copy it over, thanks.
> 
> That should have had a smiley :-)

:-)  The fix is likely something like this:

diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 5275074..776703e 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -189,8 +189,8 @@ struct pci_dev *of_create_pci_dev(struct device_node *node,
 
 	dev->cfg_size = pci_cfg_space_size(dev);
 
-	sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
-		dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
+	dev_set_name(&dev->dev, "%04x:%02x:%02x.%d", pci_domain_nr(bus),
+		     dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
 	dev->class = get_int_prop(node, "class-code", 0);
 	dev->revision = get_int_prop(node, "revision-id", 0);
 
diff --git a/arch/sparc64/kernel/pci.c b/arch/sparc64/kernel/pci.c
index 112b09f..bfc8c5d 100644
--- a/arch/sparc64/kernel/pci.c
+++ b/arch/sparc64/kernel/pci.c
@@ -408,8 +408,8 @@ struct pci_dev *of_create_pci_dev(struct pci_pbm_info *pbm,
 	dev->class = class >> 8;
 	dev->revision = class & 0xff;
 
-	sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
-		dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
+	dev_set_name(&dev->dev, "%04x:%02x:%02x.%d", pci_domain_nr(bus),
+		     dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
 
 	if (ofpci_verbose)
 		printk("    class: 0x%x device name: %s\n",

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

* Re: linux-next: build failure
  2008-05-12  8:09   ` Stephen Rothwell
@ 2008-05-12  8:15     ` Stephen Rothwell
  2008-05-12  8:53       ` David Miller
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2008-05-12  8:15 UTC (permalink / raw)
  To: David Miller; +Cc: greg, linux-next, kay.sievers

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

Hi Dave,

On Mon, 12 May 2008 18:09:03 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 12 May 2008 00:54:54 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> >
> > There is identical code in arch/powerpc/kernel/pci_64.c, it doesn't
> > break the build there becuase powerpc doesn't use -Werror (yet) :-)
> 
> OK, I will look for your fix and copy it over, thanks.

That should have had a smiley :-)

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

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

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

* Re: linux-next: build failure
  2008-05-12  7:54 ` David Miller
@ 2008-05-12  8:09   ` Stephen Rothwell
  2008-05-12  8:15     ` Stephen Rothwell
  0 siblings, 1 reply; 96+ messages in thread
From: Stephen Rothwell @ 2008-05-12  8:09 UTC (permalink / raw)
  To: David Miller; +Cc: greg, linux-next, kay.sievers

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

Hi Dave,

On Mon, 12 May 2008 00:54:54 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> There is identical code in arch/powerpc/kernel/pci_64.c, it doesn't
> break the build there becuase powerpc doesn't use -Werror (yet) :-)

OK, I will look for your fix and copy it over, thanks.

> I'm getting a little tired of all of these breakages that occur when
> the core PCI probing under drivers/pci or related datastructures are
> modified but nobody even tests the build of powerpc or sparc's OF
> based PCI bus probing code.
> 
> There have also been functional breakages due to core PCI changes
> because of this, an update goes into the drivers/pci/*.c code but
> doesn't get noticed for arch/{sparc64,powerpc}/'s PCI probing code
> until some poor arch maintainer or user tries to bootup on those
> platforms.

One of the reasons that we have linux-next, of course.  However, it would
be nice if Greg could find a couple of cross compilers for the major
architectures :-)

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

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

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

* Re: linux-next: build failure
       [not found] <20080512154717.2d0947f0.sfr@canb.auug.org.au>
@ 2008-05-12  7:54 ` David Miller
  2008-05-12  8:09   ` Stephen Rothwell
  2008-05-12 16:50 ` Greg KH
  1 sibling, 1 reply; 96+ messages in thread
From: David Miller @ 2008-05-12  7:54 UTC (permalink / raw)
  To: sfr; +Cc: greg, linux-next, kay.sievers

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 12 May 2008 15:47:17 +1000

> Today's linux-next build (sparc64 defconfig) fails like this:
> 
> arch/sparc64/kernel/pci.c: In function `of_create_pci_dev':
> arch/sparc64/kernel/pci.c:412: warning: passing arg 1 of `sprintf' discards qualifiers from pointer target type
> make[2]: *** [arch/sparc64/kernel/pci.o] Error 1
> 
> (I assume sparc64 builds with -Werr)

Yes, it builds everything except the FPU emulator under arch/sparc64
with -Werror

> This started on May 8 with the introduction of "driver-core: prepare for
> removal of 20 char limit from struct device".
> 
> The sparc64 pci code above looks like this:
> 
> 	sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(bus),
> 		dev->bus->number, PCI_SLOT(devfn), PCI_FUNC(devfn));
> 

There is identical code in arch/powerpc/kernel/pci_64.c, it doesn't
break the build there becuase powerpc doesn't use -Werror (yet) :-)

I'm getting a little tired of all of these breakages that occur when
the core PCI probing under drivers/pci or related datastructures are
modified but nobody even tests the build of powerpc or sparc's OF
based PCI bus probing code.

There have also been functional breakages due to core PCI changes
because of this, an update goes into the drivers/pci/*.c code but
doesn't get noticed for arch/{sparc64,powerpc}/'s PCI probing code
until some poor arch maintainer or user tries to bootup on those
platforms.

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

end of thread, other threads:[~2014-05-12 17:05 UTC | newest]

Thread overview: 96+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-03 15:58 linux-next build failure Mark Salter
2014-01-03 22:56 ` Andrew Morton
2014-01-06 15:21   ` Mark Salter
  -- strict thread matches above, loose matches on Subject: below --
2014-05-12 13:18 Mark Salter
2014-05-12 15:47 ` Mark Salter
2014-05-12 17:05 ` Al Viro
2013-11-08 16:51 Mark Salter
2013-10-30 15:27 Mark Salter
2013-10-30 20:37 ` Stephen Rothwell
2013-10-30 20:50   ` Andrew Morton
2013-10-30 23:17     ` Stephen Rothwell
     [not found] <CAHfT02u5as-YvAvwznMveNY_FbeDWLbj0NL6O78MRfeLQ5mpsA@mail.gmail.com>
2011-12-22 23:55 ` linux-next: " Carles Pey
2011-12-23  6:08   ` Stephen Rothwell
2011-12-30 19:43     ` Carles Pey
2009-04-08  4:04 Stephen Rothwell
2009-04-08  5:12 ` Alan Modra
2009-02-02  9:02 Stephen Rothwell
2009-02-02 19:43 ` Yinghai Lu
2009-02-03  6:14 ` David Miller
2009-01-08  5:20 Stephen Rothwell
2009-01-08  5:42 ` David Miller
2008-12-09  7:34 Stephen Rothwell
2008-12-09 21:05 ` Jesse Barnes
2008-11-11  8:10 Stephen Rothwell
2008-11-11  8:15 ` Sujith
2008-11-11  9:18 ` David Miller
2008-11-07  9:25 Stephen Rothwell
2008-11-07 16:40 ` Hollis Blanchard
2008-11-07 17:05   ` Josh Boyer
2008-11-07 17:24     ` Hollis Blanchard
2008-11-07 17:34       ` Josh Boyer
2008-11-07 21:18         ` Hollis Blanchard
2008-11-07 22:54   ` Stephen Rothwell
2008-11-09 15:50     ` Avi Kivity
2008-10-23  9:51 Stephen Rothwell
2008-10-23  9:18 Stephen Rothwell
2008-10-20 12:04 Stephen Rothwell
2008-10-20 15:48 ` Greg KH
2008-10-20 16:33   ` J.R. Mauro
2008-10-20 16:51     ` Greg KH
2008-10-20 20:47       ` Greg KH
2008-10-20 22:34         ` J.R. Mauro
2008-10-20 22:31   ` Stephen Rothwell
2008-10-17  8:21 Stephen Rothwell
2008-10-17 17:37 ` Greg KH
2008-10-17  7:59 Stephen Rothwell
2008-10-16  9:29 Stephen Rothwell
2008-10-16 10:39 ` Ingo Molnar
2008-10-16 16:11   ` Jeremy Fitzhardinge
2008-10-16 16:14     ` Ingo Molnar
2008-10-16  9:28 Stephen Rothwell
2008-10-16 14:00 ` Eric Van Hensbergen
2008-09-03  8:45 Stephen Rothwell
2008-09-03 10:19 ` David Woodhouse
2008-08-27  0:06 Stephen Rothwell
2008-08-27  2:55 ` Rusty Russell
2008-08-27  4:54   ` Stephen Rothwell
2008-08-25 11:28 Stephen Rothwell
2008-08-25 12:40 ` Ingo Molnar
2008-08-28  7:40 ` David Miller
2008-07-30  5:30 Stephen Rothwell
2008-07-30  5:54 ` Ananth N Mavinakayanahalli
2008-07-30  6:41 ` Adrian Bunk
     [not found]   ` <20080730064146.GA1564-re2QNgSbS3j4D6uPqz5PAwR5/fbUUdgG@public.gmane.org>
2008-07-30  7:06     ` Ankita Garg
     [not found]       ` <20080730070643.GA18347-xthvdsQ13ZrQT0dZR+AlfA@public.gmane.org>
2008-07-30 19:16         ` Bartlomiej Zolnierkiewicz
2008-07-30 23:35           ` Stephen Rothwell
2008-07-29  6:23 Stephen Rothwell
2008-07-29  8:00 ` Ingo Molnar
2008-07-29  8:03   ` Stephen Rothwell
2008-07-29  8:58     ` Ingo Molnar
2008-07-29 11:28       ` KOSAKI Motohiro
2008-07-29 11:40         ` Ingo Molnar
2008-07-29 14:31           ` Mike Travis
2008-07-29 14:33             ` Mike Travis
2008-07-29 16:33           ` Linus Torvalds
2008-07-29 16:42             ` Ingo Molnar
2008-07-29 16:44             ` Linus Torvalds
2008-07-29  8:14   ` Wenji Huang
2008-07-29 16:26   ` Linus Torvalds
2008-07-28  5:07 Stephen Rothwell
2008-07-28  4:44 Stephen Rothwell
2008-07-25  6:45 Stephen Rothwell
2008-06-30 13:22 Stephen Rothwell
2008-06-30 14:06 ` Ingo Molnar
2008-06-30 14:46   ` Stephen Rothwell
2008-06-30 15:12 ` Randy Dunlap
2008-06-30 15:49   ` Randy Dunlap
2008-06-30 23:30     ` Stephen Rothwell
2008-06-30 16:10 ` Sam Ravnborg
2008-06-30 16:44   ` Randy Dunlap
     [not found] <20080512154717.2d0947f0.sfr@canb.auug.org.au>
2008-05-12  7:54 ` David Miller
2008-05-12  8:09   ` Stephen Rothwell
2008-05-12  8:15     ` Stephen Rothwell
2008-05-12  8:53       ` David Miller
2008-05-12 10:42         ` Stephen Rothwell
2008-05-12 16:50 ` Greg KH

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