Stephen Rothwell wrote on 12/01/2010 00:58:05:
>
> Hi all,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> cc1: error: include/linux/autoconf.h: No such file or directory
>
> (while building the boot wrappers - lots more of the same)
>
> Caused by commit ac4c2a3bbe5db5
Stephen Rothwell wrote on 12/01/2010 00:58:05:
>
> Hi all,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> cc1: error: include/linux/autoconf.h: No such file or directory
>
> (while building the boot wrappers - lots more of the same)
>
> Caused by commit ac4c2a3bbe5db5
Hi all,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
cc1: error: include/linux/autoconf.h: No such file or directory
(while building the boot wrappers - lots more of the same)
Caused by commit ac4c2a3bbe5db5fc570b1d0ee1e474db7cb22585 ("zlib:
optimize inffast when copying
Hi all,
Today's linux-next build (powerpc64, gcc 4.1.3) failed like this:
drivers/video/logo/logo_linux_mono.c:11: error: logo_linux_mono_data causes a
section type conflict
Caused by commit ae52bb2384f721562f15f719de1acb8e934733cb ("fbdev: move
logo externs to header file") but probably really
Hi Ingo,
On Fri, 12 Jun 2009 16:11:18 +0200 Ingo Molnar wrote:
>
> But that's axiomatic, isnt it? linux-next build-tests PowerPC as the
> first in the row of tests - so no change that was in linux-next can
> ever cause a build failure on PowerPC, right?
Not really. I build a powerpc ppc64_def
Hi Ingo,
On Fri, 12 Jun 2009 15:44:28 +0200 Ingo Molnar wrote:
>
> In terms of test coverage, at least for our trees, less than 1% of
> the bugs we handle get reported in a linux-next context - and most
> of the bugs that get reported (against say the scheduler tree) are
> related to rare arch
On Fri, 2009-06-12 at 16:11 +0200, Ingo Molnar wrote:
> > Maybe. But maybe it's representative... so far in this merge
> > window, 100% of the powerpc build and runtime breakage upstream
> > comes from stuff that didn't get into -next before.
>
> But that's axiomatic, isnt it? linux-next build-t
> Uhm, the bug you are making a big deal of would have been found and
> fixed by Paulus a few hours after any such mail - and probably by me
> too as i do daily cross builds to Power.
>
> So yes, we had a bug, but any extra linux-next hoops would not have
> prevented it: i could still have mes
* Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-12 at 15:49 +0200, Ingo Molnar wrote:
> > * Benjamin Herrenschmidt wrote:
> >
> > > On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> > > > On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> > >
> > > > To some extent, he
* Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-12 at 15:44 +0200, Ingo Molnar wrote:
>
> > This is certainly doable for agreeable features - which is the bulk
> > - and it is being done.
> >
> > But this is a catch-22 for _controversial_ new features - which
> > perfcounters clearly was,
On Fri, 2009-06-12 at 15:49 +0200, Ingo Molnar wrote:
> * Benjamin Herrenschmidt wrote:
>
> > On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> > > On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> >
> > > To some extent, here, the issue is on Linus side and it's up to him
On Fri, 2009-06-12 at 15:44 +0200, Ingo Molnar wrote:
> This is certainly doable for agreeable features - which is the bulk
> - and it is being done.
>
> But this is a catch-22 for _controversial_ new features - which
> perfcounters clearly was, in case you turned off your lkml
> subscription
* Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
>
> > To some extent, here, the issue is on Linus side and it's up to him (Hey
> > Linus ! still listening ?) to maybe be more proactive a
* Benjamin Herrenschmidt wrote:
> > linux-next should not be second-guessing maintainers and should
> > not act as an "approval forum" for controversial features,
> > increasing the (already quite substantial) pressure on
> > maintainers to apply more crap.
>
> I agree here. That's not the p
On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> To some extent, here, the issue is on Linus side and it's up to him (Hey
> Linus ! still listening ?) to maybe be more proactive at giving an ack
> or nack so that we can get
On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> * Benjamin Herrenschmidt wrote:
> linux-next has integration testing so that interactions between
> maintainer trees are mapped and that architectures that otherwise
> few people use get build-tested too (well beyond their practical
> rel
* Benjamin Herrenschmidt wrote:
> > Ah - thanks. The bug was caused by me being a bit too optimistic
> > in applying the shiny-new Power7 support patches on the last
> > day. (nice CPU btw.)
>
> In that case paulus tells me it's actually Peter screwing up
> moving something from the powerpc
* Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-12 at 10:24 +1000, Stephen Rothwell wrote:
>
> > From: Stephen Rothwell
> > Date: Fri, 12 Jun 2009 10:14:22 +1000
> > Subject: [PATCH] perfcounters: remove powerpc definitions of
> > perf_counter_do_pending
> >
> > Commit 925d519ab82b6dd7aca9
On Fri, 2009-06-12 at 11:43 +0200, Peter Zijlstra wrote:
> On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> > We should at least -try- to follow the
> > process we've defined, don't you think ?
>
> So you're saying -next should include whole new subsystems even though
> its not c
* Peter Zijlstra wrote:
> On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> > We should at least -try- to follow the
> > process we've defined, don't you think ?
>
> So you're saying -next should include whole new subsystems even
> though its not clear they will be merged?
>
>
On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> We should at least -try- to follow the
> process we've defined, don't you think ?
So you're saying -next should include whole new subsystems even though
its not clear they will be merged?
That'll invariably create the opposite cas
> Ah - thanks. The bug was caused by me being a bit too optimistic in
> applying the shiny-new Power7 support patches on the last day. (nice
> CPU btw.)
In that case paulus tells me it's actually Peter screwing up moving
something from the powerpc code to generic :-)
.../...
> Such bugs happ
On Fri, 2009-06-12 at 10:24 +1000, Stephen Rothwell wrote:
> From: Stephen Rothwell
> Date: Fri, 12 Jun 2009 10:14:22 +1000
> Subject: [PATCH] perfcounters: remove powerpc definitions of
> perf_counter_do_pending
>
> Commit 925d519ab82b6dd7aca9420d809ee83819c08db2 ("perf_counter:
> unify and fi
Stephen Rothwell writes:
> Subject: [PATCH] perfcounters: remove powerpc definitions of
> perf_counter_do_pending
>
> Commit 925d519ab82b6dd7aca9420d809ee83819c08db2 ("perf_counter:
> unify and fix delayed counter wakeup") added global definitions.
>
> Signed-off-by: Stephen Rothwell
Acked-by
Hi all,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
include/linux/perf_counter.h:677: error: redefinition of
'perf_counter_do_pending'
arch/powerpc/include/asm/hw_irq.h:170: note: previous definition of
'perf_counter_do_pending' was here
Caused by commit 925d519ab82b6d
Hi Ingo,
On Mon, 12 Jan 2009 10:32:14 +0100 Ingo Molnar wrote:
>
> * Stephen Rothwell wrote:
>
> > > It slipped through because it didnt get caught in build tests because
> > > cpufreq isnt enabled in the powerpc defconfig.
> >
> > Which is one of the reasons we have linux-next: "integration
* Michael Ellerman wrote:
> On Mon, 2009-01-12 at 10:05 +0100, Ingo Molnar wrote:
> > * Benjamin Herrenschmidt wrote:
> >
> > > On Mon, 2009-01-12 at 10:48 +1100, Stephen Rothwell wrote:
> > > > Hi Linus,
> > > >
> > > > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> >
On Mon, 2009-01-12 at 10:05 +0100, Ingo Molnar wrote:
> * Benjamin Herrenschmidt wrote:
>
> > On Mon, 2009-01-12 at 10:48 +1100, Stephen Rothwell wrote:
> > > Hi Linus,
> > >
> > > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > >
> > > arch/powerpc/platforms/pasemi/cpu
* Stephen Rothwell wrote:
> > It slipped through because it didnt get caught in build tests because
> > cpufreq isnt enabled in the powerpc defconfig.
>
> Which is one of the reasons we have linux-next: "integration testing".
Build bugs slipped through that net too in the past.
And we dont r
Hi Ingo,
On Mon, 12 Jan 2009 10:05:52 +0100 Ingo Molnar wrote:
>
> Yeah - and that build bug was stupid too - when touching a generic file
> that is called include/linux/cpufreq.h and changing a key data field one
> should at minimum get the idea that it's generic for a reason and should
> sta
* Benjamin Herrenschmidt wrote:
> On Mon, 2009-01-12 at 10:48 +1100, Stephen Rothwell wrote:
> > Hi Linus,
> >
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> >
> > arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
> > arch/powerpc/platform
On Mon, 2009-01-12 at 10:48 +1100, Stephen Rothwell wrote:
> Hi Linus,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
> arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types
Hi Linus,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
arch/powerpc/platforms/pasemi/cpufreq.c: In function 'pas_cpufreq_cpu_init':
arch/powerpc/platforms/pasemi/cpufreq.c:216: error: incompatible types in
assignment
arch/powerpc/platforms/powermac/cpufreq_64.c: In functi
Hi Dave, Neil,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
drivers/net/ibmveth.c: In function 'ibmveth_poll':
drivers/net/ibmveth.c:1034: warning: passing argument 1 of
'netif_rx_reschedule' from incompatible pointer type
drivers/net/ibmveth.c:1034: error: too many argum
Hi all,
Today's linux-next (really just Linus' tree) build (powerpc
ppc64_defconfig) failed like this:
fs/nfs/nfsroot.c:130: error: tokens causes a section type conflict
"tokens" is a match_table_t which has const added to it in commit
f9247273cb69ba101877e946d2d83044409cc8c5 "UFS: add const to
35 matches
Mail list logo
