[PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename

[PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename

[Paul Mackerras]

This fixes two places in the powerpc perf_event (perf_counter) code
where 'list_entry' needs to be changed to 'group_entry', but were
missed in commit 65abc865 ("perf_counter: Rename list_entry ->
group_entry, counter_list -> group_list").

This also changes 'event' back to 'counter' in a couple of contexts:

* Field and function names that deal with the limited-function
  counters: it's really the hardware counters whose function is
  limited, not the events that they count.  Hence:

  MAX_LIMITED_HWEVENTS -> MAX_LIMITED_HWCOUNTERS
  limited_event -> limited_counter
  freeze/thaw_limited_events -> freeze/thaw_limited_counters

* The machine-specific PMU description struct (struct power_pmu): this
  renames 'n_event' back to 'n_counter' since it really describes how
  many hardware counters the machine has.  (Renaming this back avoids
  a compile error in each of the machine-specific PMU back-ends where
  they initialize their power_pmu struct.)

Signed-off-by: Paul Mackerras <paulus@samba.org>
---
 arch/powerpc/include/asm/perf_event.h |    4 +--
 arch/powerpc/kernel/perf_event.c      |   38 +++++++++++++++++-----------------
 2 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/arch/powerpc/include/asm/perf_event.h b/arch/powerpc/include/asm/perf_event.h
index 2499aaa..3288ce3 100644
--- a/arch/powerpc/include/asm/perf_event.h
+++ b/arch/powerpc/include/asm/perf_event.h
@@ -14,7 +14,7 @@
 
 #define MAX_HWEVENTS		8
 #define MAX_EVENT_ALTERNATIVES	8
-#define MAX_LIMITED_HWEVENTS	2
+#define MAX_LIMITED_HWCOUNTERS	2
 
 /*
  * This struct provides the constants and functions needed to
@@ -22,7 +22,7 @@
  */
 struct power_pmu {
 	const char	*name;
-	int		n_event;
+	int		n_counter;
 	int		max_alternatives;
 	unsigned long	add_fields;
 	unsigned long	test_adder;
diff --git a/arch/powerpc/kernel/perf_event.c b/arch/powerpc/kernel/perf_event.c
index 197b7d9..bbcbae1 100644
--- a/arch/powerpc/kernel/perf_event.c
+++ b/arch/powerpc/kernel/perf_event.c
@@ -30,8 +30,8 @@ struct cpu_hw_events {
 	u64 events[MAX_HWEVENTS];
 	unsigned int flags[MAX_HWEVENTS];
 	unsigned long mmcr[3];
-	struct perf_event *limited_event[MAX_LIMITED_HWEVENTS];
-	u8  limited_hwidx[MAX_LIMITED_HWEVENTS];
+	struct perf_event *limited_counter[MAX_LIMITED_HWCOUNTERS];
+	u8  limited_hwidx[MAX_LIMITED_HWCOUNTERS];
 	u64 alternatives[MAX_HWEVENTS][MAX_EVENT_ALTERNATIVES];
 	unsigned long amasks[MAX_HWEVENTS][MAX_EVENT_ALTERNATIVES];
 	unsigned long avalues[MAX_HWEVENTS][MAX_EVENT_ALTERNATIVES];
@@ -253,7 +253,7 @@ static int power_check_constraints(struct cpu_hw_events *cpuhw,
 	unsigned long addf = ppmu->add_fields;
 	unsigned long tadd = ppmu->test_adder;
 
-	if (n_ev > ppmu->n_event)
+	if (n_ev > ppmu->n_counter)
 		return -1;
 
 	/* First see if the events will go on as-is */
@@ -426,7 +426,7 @@ static int is_limited_pmc(int pmcnum)
 		&& (pmcnum == 5 || pmcnum == 6);
 }
 
-static void freeze_limited_events(struct cpu_hw_events *cpuhw,
+static void freeze_limited_counters(struct cpu_hw_events *cpuhw,
 				    unsigned long pmc5, unsigned long pmc6)
 {
 	struct perf_event *event;
@@ -434,7 +434,7 @@ static void freeze_limited_events(struct cpu_hw_events *cpuhw,
 	int i;
 
 	for (i = 0; i < cpuhw->n_limited; ++i) {
-		event = cpuhw->limited_event[i];
+		event = cpuhw->limited_counter[i];
 		if (!event->hw.idx)
 			continue;
 		val = (event->hw.idx == 5) ? pmc5 : pmc6;
@@ -445,7 +445,7 @@ static void freeze_limited_events(struct cpu_hw_events *cpuhw,
 	}
 }
 
-static void thaw_limited_events(struct cpu_hw_events *cpuhw,
+static void thaw_limited_counters(struct cpu_hw_events *cpuhw,
 				  unsigned long pmc5, unsigned long pmc6)
 {
 	struct perf_event *event;
@@ -453,7 +453,7 @@ static void thaw_limited_events(struct cpu_hw_events *cpuhw,
 	int i;
 
 	for (i = 0; i < cpuhw->n_limited; ++i) {
-		event = cpuhw->limited_event[i];
+		event = cpuhw->limited_counter[i];
 		event->hw.idx = cpuhw->limited_hwidx[i];
 		val = (event->hw.idx == 5) ? pmc5 : pmc6;
 		atomic64_set(&event->hw.prev_count, val);
@@ -495,9 +495,9 @@ static void write_mmcr0(struct cpu_hw_events *cpuhw, unsigned long mmcr0)
 		       "i" (SPRN_PMC5), "i" (SPRN_PMC6));
 
 	if (mmcr0 & MMCR0_FC)
-		freeze_limited_events(cpuhw, pmc5, pmc6);
+		freeze_limited_counters(cpuhw, pmc5, pmc6);
 	else
-		thaw_limited_events(cpuhw, pmc5, pmc6);
+		thaw_limited_counters(cpuhw, pmc5, pmc6);
 
 	/*
 	 * Write the full MMCR0 including the event overflow interrupt
@@ -653,7 +653,7 @@ void hw_perf_enable(void)
 			continue;
 		idx = hwc_index[i] + 1;
 		if (is_limited_pmc(idx)) {
-			cpuhw->limited_event[n_lim] = event;
+			cpuhw->limited_counter[n_lim] = event;
 			cpuhw->limited_hwidx[n_lim] = idx;
 			++n_lim;
 			continue;
@@ -702,7 +702,7 @@ static int collect_events(struct perf_event *group, int max_count,
 		flags[n] = group->hw.event_base;
 		events[n++] = group->hw.config;
 	}
-	list_for_each_entry(event, &group->sibling_list, list_entry) {
+	list_for_each_entry(event, &group->sibling_list, group_entry) {
 		if (!is_software_event(event) &&
 		    event->state != PERF_EVENT_STATE_OFF) {
 			if (n >= max_count)
@@ -742,7 +742,7 @@ int hw_perf_group_sched_in(struct perf_event *group_leader,
 		return 0;
 	cpuhw = &__get_cpu_var(cpu_hw_events);
 	n0 = cpuhw->n_events;
-	n = collect_events(group_leader, ppmu->n_event - n0,
+	n = collect_events(group_leader, ppmu->n_counter - n0,
 			   &cpuhw->event[n0], &cpuhw->events[n0],
 			   &cpuhw->flags[n0]);
 	if (n < 0)
@@ -764,7 +764,7 @@ int hw_perf_group_sched_in(struct perf_event *group_leader,
 	cpuctx->active_oncpu += n;
 	n = 1;
 	event_sched_in(group_leader, cpu);
-	list_for_each_entry(sub, &group_leader->sibling_list, list_entry) {
+	list_for_each_entry(sub, &group_leader->sibling_list, group_entry) {
 		if (sub->state != PERF_EVENT_STATE_OFF) {
 			event_sched_in(sub, cpu);
 			++n;
@@ -797,7 +797,7 @@ static int power_pmu_enable(struct perf_event *event)
 	 */
 	cpuhw = &__get_cpu_var(cpu_hw_events);
 	n0 = cpuhw->n_events;
-	if (n0 >= ppmu->n_event)
+	if (n0 >= ppmu->n_counter)
 		goto out;
 	cpuhw->event[n0] = event;
 	cpuhw->events[n0] = event->hw.config;
@@ -848,11 +848,11 @@ static void power_pmu_disable(struct perf_event *event)
 		}
 	}
 	for (i = 0; i < cpuhw->n_limited; ++i)
-		if (event == cpuhw->limited_event[i])
+		if (event == cpuhw->limited_counter[i])
 			break;
 	if (i < cpuhw->n_limited) {
 		while (++i < cpuhw->n_limited) {
-			cpuhw->limited_event[i-1] = cpuhw->limited_event[i];
+			cpuhw->limited_counter[i-1] = cpuhw->limited_counter[i];
 			cpuhw->limited_hwidx[i-1] = cpuhw->limited_hwidx[i];
 		}
 		--cpuhw->n_limited;
@@ -1078,7 +1078,7 @@ const struct pmu *hw_perf_event_init(struct perf_event *event)
 	 */
 	n = 0;
 	if (event->group_leader != event) {
-		n = collect_events(event->group_leader, ppmu->n_event - 1,
+		n = collect_events(event->group_leader, ppmu->n_counter - 1,
 				   ctrs, events, cflags);
 		if (n < 0)
 			return ERR_PTR(-EINVAL);
@@ -1230,7 +1230,7 @@ static void perf_event_interrupt(struct pt_regs *regs)
 	int nmi;
 
 	if (cpuhw->n_limited)
-		freeze_limited_events(cpuhw, mfspr(SPRN_PMC5),
+		freeze_limited_counters(cpuhw, mfspr(SPRN_PMC5),
 					mfspr(SPRN_PMC6));
 
 	perf_read_regs(regs);
@@ -1260,7 +1260,7 @@ static void perf_event_interrupt(struct pt_regs *regs)
 	 * Any that we processed in the previous loop will not be negative.
 	 */
 	if (!found) {
-		for (i = 0; i < ppmu->n_event; ++i) {
+		for (i = 0; i < ppmu->n_counter; ++i) {
 			if (is_limited_pmc(i + 1))
 				continue;
 			val = read_pmc(i + 1);

Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename

[Benjamin Herrenschmidt]

On Tue, 2009-09-22 at 09:48 +1000, Paul Mackerras wrote:
> This fixes two places in the powerpc perf_event (perf_counter) code
> where 'list_entry' needs to be changed to 'group_entry', but were
> missed in commit 65abc865 ("perf_counter: Rename list_entry ->
> group_entry, counter_list -> group_list").

Ingo: This is becoming a recurring one now... powerpc build upstream  is
broken approx everyday by some new perfctr build breakage.

You really aren't build testing other architectures than x86 right ?

Ben.

> This also changes 'event' back to 'counter' in a couple of contexts:
> 
> * Field and function names that deal with the limited-function
>   counters: it's really the hardware counters whose function is
>   limited, not the events that they count.  Hence:
> 
>   MAX_LIMITED_HWEVENTS -> MAX_LIMITED_HWCOUNTERS
>   limited_event -> limited_counter
>   freeze/thaw_limited_events -> freeze/thaw_limited_counters
> 
> * The machine-specific PMU description struct (struct power_pmu): this
>   renames 'n_event' back to 'n_counter' since it really describes how
>   many hardware counters the machine has.  (Renaming this back avoids
>   a compile error in each of the machine-specific PMU back-ends where
>   they initialize their power_pmu struct.)
> 
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
>  arch/powerpc/include/asm/perf_event.h |    4 +--
>  arch/powerpc/kernel/perf_event.c      |   38 +++++++++++++++++-----------------
>  2 files changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/perf_event.h b/arch/powerpc/include/asm/perf_event.h
> index 2499aaa..3288ce3 100644
> --- a/arch/powerpc/include/asm/perf_event.h
> +++ b/arch/powerpc/include/asm/perf_event.h
> @@ -14,7 +14,7 @@
>  
>  #define MAX_HWEVENTS		8
>  #define MAX_EVENT_ALTERNATIVES	8
> -#define MAX_LIMITED_HWEVENTS	2
> +#define MAX_LIMITED_HWCOUNTERS	2
>  
>  /*
>   * This struct provides the constants and functions needed to
> @@ -22,7 +22,7 @@
>   */
>  struct power_pmu {
>  	const char	*name;
> -	int		n_event;
> +	int		n_counter;
>  	int		max_alternatives;
>  	unsigned long	add_fields;
>  	unsigned long	test_adder;
> diff --git a/arch/powerpc/kernel/perf_event.c b/arch/powerpc/kernel/perf_event.c
> index 197b7d9..bbcbae1 100644
> --- a/arch/powerpc/kernel/perf_event.c
> +++ b/arch/powerpc/kernel/perf_event.c
> @@ -30,8 +30,8 @@ struct cpu_hw_events {
>  	u64 events[MAX_HWEVENTS];
>  	unsigned int flags[MAX_HWEVENTS];
>  	unsigned long mmcr[3];
> -	struct perf_event *limited_event[MAX_LIMITED_HWEVENTS];
> -	u8  limited_hwidx[MAX_LIMITED_HWEVENTS];
> +	struct perf_event *limited_counter[MAX_LIMITED_HWCOUNTERS];
> +	u8  limited_hwidx[MAX_LIMITED_HWCOUNTERS];
>  	u64 alternatives[MAX_HWEVENTS][MAX_EVENT_ALTERNATIVES];
>  	unsigned long amasks[MAX_HWEVENTS][MAX_EVENT_ALTERNATIVES];
>  	unsigned long avalues[MAX_HWEVENTS][MAX_EVENT_ALTERNATIVES];
> @@ -253,7 +253,7 @@ static int power_check_constraints(struct cpu_hw_events *cpuhw,
>  	unsigned long addf = ppmu->add_fields;
>  	unsigned long tadd = ppmu->test_adder;
>  
> -	if (n_ev > ppmu->n_event)
> +	if (n_ev > ppmu->n_counter)
>  		return -1;
>  
>  	/* First see if the events will go on as-is */
> @@ -426,7 +426,7 @@ static int is_limited_pmc(int pmcnum)
>  		&& (pmcnum == 5 || pmcnum == 6);
>  }
>  
> -static void freeze_limited_events(struct cpu_hw_events *cpuhw,
> +static void freeze_limited_counters(struct cpu_hw_events *cpuhw,
>  				    unsigned long pmc5, unsigned long pmc6)
>  {
>  	struct perf_event *event;
> @@ -434,7 +434,7 @@ static void freeze_limited_events(struct cpu_hw_events *cpuhw,
>  	int i;
>  
>  	for (i = 0; i < cpuhw->n_limited; ++i) {
> -		event = cpuhw->limited_event[i];
> +		event = cpuhw->limited_counter[i];
>  		if (!event->hw.idx)
>  			continue;
>  		val = (event->hw.idx == 5) ? pmc5 : pmc6;
> @@ -445,7 +445,7 @@ static void freeze_limited_events(struct cpu_hw_events *cpuhw,
>  	}
>  }
>  
> -static void thaw_limited_events(struct cpu_hw_events *cpuhw,
> +static void thaw_limited_counters(struct cpu_hw_events *cpuhw,
>  				  unsigned long pmc5, unsigned long pmc6)
>  {
>  	struct perf_event *event;
> @@ -453,7 +453,7 @@ static void thaw_limited_events(struct cpu_hw_events *cpuhw,
>  	int i;
>  
>  	for (i = 0; i < cpuhw->n_limited; ++i) {
> -		event = cpuhw->limited_event[i];
> +		event = cpuhw->limited_counter[i];
>  		event->hw.idx = cpuhw->limited_hwidx[i];
>  		val = (event->hw.idx == 5) ? pmc5 : pmc6;
>  		atomic64_set(&event->hw.prev_count, val);
> @@ -495,9 +495,9 @@ static void write_mmcr0(struct cpu_hw_events *cpuhw, unsigned long mmcr0)
>  		       "i" (SPRN_PMC5), "i" (SPRN_PMC6));
>  
>  	if (mmcr0 & MMCR0_FC)
> -		freeze_limited_events(cpuhw, pmc5, pmc6);
> +		freeze_limited_counters(cpuhw, pmc5, pmc6);
>  	else
> -		thaw_limited_events(cpuhw, pmc5, pmc6);
> +		thaw_limited_counters(cpuhw, pmc5, pmc6);
>  
>  	/*
>  	 * Write the full MMCR0 including the event overflow interrupt
> @@ -653,7 +653,7 @@ void hw_perf_enable(void)
>  			continue;
>  		idx = hwc_index[i] + 1;
>  		if (is_limited_pmc(idx)) {
> -			cpuhw->limited_event[n_lim] = event;
> +			cpuhw->limited_counter[n_lim] = event;
>  			cpuhw->limited_hwidx[n_lim] = idx;
>  			++n_lim;
>  			continue;
> @@ -702,7 +702,7 @@ static int collect_events(struct perf_event *group, int max_count,
>  		flags[n] = group->hw.event_base;
>  		events[n++] = group->hw.config;
>  	}
> -	list_for_each_entry(event, &group->sibling_list, list_entry) {
> +	list_for_each_entry(event, &group->sibling_list, group_entry) {
>  		if (!is_software_event(event) &&
>  		    event->state != PERF_EVENT_STATE_OFF) {
>  			if (n >= max_count)
> @@ -742,7 +742,7 @@ int hw_perf_group_sched_in(struct perf_event *group_leader,
>  		return 0;
>  	cpuhw = &__get_cpu_var(cpu_hw_events);
>  	n0 = cpuhw->n_events;
> -	n = collect_events(group_leader, ppmu->n_event - n0,
> +	n = collect_events(group_leader, ppmu->n_counter - n0,
>  			   &cpuhw->event[n0], &cpuhw->events[n0],
>  			   &cpuhw->flags[n0]);
>  	if (n < 0)
> @@ -764,7 +764,7 @@ int hw_perf_group_sched_in(struct perf_event *group_leader,
>  	cpuctx->active_oncpu += n;
>  	n = 1;
>  	event_sched_in(group_leader, cpu);
> -	list_for_each_entry(sub, &group_leader->sibling_list, list_entry) {
> +	list_for_each_entry(sub, &group_leader->sibling_list, group_entry) {
>  		if (sub->state != PERF_EVENT_STATE_OFF) {
>  			event_sched_in(sub, cpu);
>  			++n;
> @@ -797,7 +797,7 @@ static int power_pmu_enable(struct perf_event *event)
>  	 */
>  	cpuhw = &__get_cpu_var(cpu_hw_events);
>  	n0 = cpuhw->n_events;
> -	if (n0 >= ppmu->n_event)
> +	if (n0 >= ppmu->n_counter)
>  		goto out;
>  	cpuhw->event[n0] = event;
>  	cpuhw->events[n0] = event->hw.config;
> @@ -848,11 +848,11 @@ static void power_pmu_disable(struct perf_event *event)
>  		}
>  	}
>  	for (i = 0; i < cpuhw->n_limited; ++i)
> -		if (event == cpuhw->limited_event[i])
> +		if (event == cpuhw->limited_counter[i])
>  			break;
>  	if (i < cpuhw->n_limited) {
>  		while (++i < cpuhw->n_limited) {
> -			cpuhw->limited_event[i-1] = cpuhw->limited_event[i];
> +			cpuhw->limited_counter[i-1] = cpuhw->limited_counter[i];
>  			cpuhw->limited_hwidx[i-1] = cpuhw->limited_hwidx[i];
>  		}
>  		--cpuhw->n_limited;
> @@ -1078,7 +1078,7 @@ const struct pmu *hw_perf_event_init(struct perf_event *event)
>  	 */
>  	n = 0;
>  	if (event->group_leader != event) {
> -		n = collect_events(event->group_leader, ppmu->n_event - 1,
> +		n = collect_events(event->group_leader, ppmu->n_counter - 1,
>  				   ctrs, events, cflags);
>  		if (n < 0)
>  			return ERR_PTR(-EINVAL);
> @@ -1230,7 +1230,7 @@ static void perf_event_interrupt(struct pt_regs *regs)
>  	int nmi;
>  
>  	if (cpuhw->n_limited)
> -		freeze_limited_events(cpuhw, mfspr(SPRN_PMC5),
> +		freeze_limited_counters(cpuhw, mfspr(SPRN_PMC5),
>  					mfspr(SPRN_PMC6));
>  
>  	perf_read_regs(regs);
> @@ -1260,7 +1260,7 @@ static void perf_event_interrupt(struct pt_regs *regs)
>  	 * Any that we processed in the previous loop will not be negative.
>  	 */
>  	if (!found) {
> -		for (i = 0; i < ppmu->n_event; ++i) {
> +		for (i = 0; i < ppmu->n_counter; ++i) {
>  			if (is_limited_pmc(i + 1))
>  				continue;
>  			val = read_pmc(i + 1);
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Tue, 2009-09-22 at 09:48 +1000, Paul Mackerras wrote:
>
> > This fixes two places in the powerpc perf_event (perf_counter) code 
> > where 'list_entry' needs to be changed to 'group_entry', but were 
> > missed in commit 65abc865 ("perf_counter: Rename list_entry -> 
> > group_entry, counter_list -> group_list").

Oops, indeed - queued up the fix and will send it to Linus shortly - 
thanks!

> Ingo: This is becoming a recurring one now... powerpc build upstream 
> is broken approx everyday by some new perfctr build breakage.
>
> You really aren't build testing other architectures than x86 right ?

On the contrary - i am build testing every architecture on a daily 
basis. (and sometimes i do it multiple times a day - yesterday i did 5 
cross builds during the rename) In fact i am testing more architectures 
than linux-next does.

Here's the log of the test i ran yesterday before i sent those bits to 
Linus:

testing 24 architectures.
                                 (warns)               (warns)
testing      alpha:  -git:  pass (   24),  -tip:  pass (   24)
testing        arm:  -git:  fail (   11),  -tip:  fail (   13)
testing   blackfin:  -git:  pass (    3),  -tip:  pass (    3)
testing       cris:  -git:  fail (   34),  -tip:  pass (   20)
testing        frv:  -git:  fail (   13),  -tip:  fail (   13)
testing      h8300:  -git:  fail (  441),  -tip:  fail (  185)
testing       i386:  -git:  pass (    2),  -tip:  pass (    5)
testing       ia64:  -git:  fail (  172),  -tip:  pass (  160)
testing       m32r:  -git:  pass (   39),  -tip:  pass (   39)
testing       m68k:  -git:  pass (   42),  -tip:  pass (   42)
testing  m68knommu:  -git:  fail (   80),  -tip:  fail (   80)
testing microblaze:  -git:  fail (   14),  -tip:  fail (   14)
testing       mips:  -git:  pass (    6),  -tip:  pass (    6)
testing    mn10300:  -git:  fail (   10),  -tip:  fail (   10)
testing     parisc:  -git:  pass (   26),  -tip:  pass (   26)
testing    powerpc:  -git:  fail (   36),  -tip:  fail (   45)
testing       s390:  -git:  pass (    6),  -tip:  pass (    6)
testing      score:  -git:  fail (   13),  -tip:  fail (   13)
testing         sh:  -git:  fail (   22),  -tip:  fail (   19)
testing      sparc:  -git:  pass (    3),  -tip:  pass (    3)
testing         um:  -git:  pass (    3),  -tip:  pass (    3)
testing     xtensa:  -git:  fail (   46),  -tip:  fail (   46)
testing     x86-64:  -git:  pass (    0),  -tip:  pass (    0)
testing     x86-32:  -git:  pass (    0),  -tip:  pass (    0)

In fact there are architectures that dont build in Linus's tree and 
build in -tip:

testing       cris:  -git:  fail (   34),  -tip:  pass (   20)

Because not only do i test every architecture i also try to fix upstream 
bugs on non-x86 pro-actively. See for example this upstream fix:

 8d7ac69: Blackfin: Fix link errors with binutils 2.19 and GCC 4.3

Nevertheless you are right that i should have caught this particular 
PowerPC build bug - i missed it - sorry about that!

Thanks,

	Ingo

Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename

[Benjamin Herrenschmidt]

On Tue, 2009-09-22 at 09:28 +0200, Ingo Molnar wrote:
> 
> Nevertheless you are right that i should have caught this particular 
> PowerPC build bug - i missed it - sorry about that!
> 
Allright. Well, to help in general, we are setting up a build-bot
here too that will build -tip HEAD for at least powerpc daily with
a few configs too.

Cheers,
Ben.

Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename

[Ingo Molnar]

* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Tue, 2009-09-22 at 09:28 +0200, Ingo Molnar wrote:
> > 
> > Nevertheless you are right that i should have caught this particular 
> > PowerPC build bug - i missed it - sorry about that!
> 
> Allright. Well, to help in general, we are setting up a build-bot here 
> too that will build -tip HEAD for at least powerpc daily with a few 
> configs too.

Cool, that's really useful! Especially during the weekends that will be 
helpful, in that timeframe linux-next driven testing has a latency of 
72-95 hours and -tip usually has an uptick in patches.

Thanks,

	Ingo

Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename

[Michael Ellerman]

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

On Tue, 2009-09-22 at 18:00 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2009-09-22 at 09:28 +0200, Ingo Molnar wrote:
> > 
> > Nevertheless you are right that i should have caught this particular 
> > PowerPC build bug - i missed it - sorry about that!
> > 
> Allright. Well, to help in general, we are setting up a build-bot
> here too that will build -tip HEAD for at least powerpc daily with
> a few configs too.

Results here:

http://kisskb.ellerman.id.au/kisskb/branch/12/

cheers

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename

[Ingo Molnar]

* Michael Ellerman <michael@ellerman.id.au> wrote:

> On Tue, 2009-09-22 at 18:00 +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2009-09-22 at 09:28 +0200, Ingo Molnar wrote:
> > > 
> > > Nevertheless you are right that i should have caught this particular 
> > > PowerPC build bug - i missed it - sorry about that!
> > > 
> > Allright. Well, to help in general, we are setting up a build-bot
> > here too that will build -tip HEAD for at least powerpc daily with
> > a few configs too.
> 
> Results here:
> 
> http://kisskb.ellerman.id.au/kisskb/branch/12/

ok, seems green for today - the two failures are: one a powerpc 
toolchain problem it appears, plus a mainline warning.

Btw., for me to be able to notice failures there it would have to email 
me automatically if there's any -tip build failures that do not occur 
with the upstream branch. Does it have such a feature?

	Ingo

Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename

[Michael Ellerman]

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

On Wed, 2009-09-23 at 14:44 +0200, Ingo Molnar wrote:
> * Michael Ellerman <michael@ellerman.id.au> wrote:
> 
> > On Tue, 2009-09-22 at 18:00 +1000, Benjamin Herrenschmidt wrote:
> > > On Tue, 2009-09-22 at 09:28 +0200, Ingo Molnar wrote:
> > > > 
> > > > Nevertheless you are right that i should have caught this particular 
> > > > PowerPC build bug - i missed it - sorry about that!
> > > > 
> > > Allright. Well, to help in general, we are setting up a build-bot
> > > here too that will build -tip HEAD for at least powerpc daily with
> > > a few configs too.
> > 
> > Results here:
> > 
> > http://kisskb.ellerman.id.au/kisskb/branch/12/
> 
> ok, seems green for today - the two failures are: one a powerpc 
> toolchain problem it appears, plus a mainline warning.

Yep that looks more or less normal.

> Btw., for me to be able to notice failures there it would have to email 
> me automatically if there's any -tip build failures that do not occur 
> with the upstream branch. Does it have such a feature?

Not really, it sends mails to me, but it doesn't have a way to filter
them by branch. I think the plan is we'll keep an eye on it and either
send you patches or at least let you know that it's broken.

cheers

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename

[Ingo Molnar]

* Michael Ellerman <michael@ellerman.id.au> wrote:

> On Wed, 2009-09-23 at 14:44 +0200, Ingo Molnar wrote:
> > * Michael Ellerman <michael@ellerman.id.au> wrote:
> > 
> > > On Tue, 2009-09-22 at 18:00 +1000, Benjamin Herrenschmidt wrote:
> > > > On Tue, 2009-09-22 at 09:28 +0200, Ingo Molnar wrote:
> > > > > 
> > > > > Nevertheless you are right that i should have caught this particular 
> > > > > PowerPC build bug - i missed it - sorry about that!
> > > > > 
> > > > Allright. Well, to help in general, we are setting up a build-bot
> > > > here too that will build -tip HEAD for at least powerpc daily with
> > > > a few configs too.
> > > 
> > > Results here:
> > > 
> > > http://kisskb.ellerman.id.au/kisskb/branch/12/
> > 
> > ok, seems green for today - the two failures are: one a powerpc 
> > toolchain problem it appears, plus a mainline warning.
> 
> Yep that looks more or less normal.
> 
> > Btw., for me to be able to notice failures there it would have to 
> > email me automatically if there's any -tip build failures that do 
> > not occur with the upstream branch. Does it have such a feature?
> 
> Not really, it sends mails to me, but it doesn't have a way to filter 
> them by branch. I think the plan is we'll keep an eye on it and either 
> send you patches or at least let you know that it's broken.

how many mails are those per day, typically? If there's not too many and 
if there's a way to send all of them to me i could post-filter them for 
-tip relevance. If that is feasible. You bouncing it to me later is 
certainly also a solution. (but lengthens the latency of fixes, 
obviously.)

	Ingo

Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename

[Michael Ellerman]

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

On Thu, 2009-09-24 at 14:14 +0200, Ingo Molnar wrote:
> * Michael Ellerman <michael@ellerman.id.au> wrote:
> 
> > On Wed, 2009-09-23 at 14:44 +0200, Ingo Molnar wrote:
> > > * Michael Ellerman <michael@ellerman.id.au> wrote:
> > > 
> > > > On Tue, 2009-09-22 at 18:00 +1000, Benjamin Herrenschmidt wrote:
> > > > > On Tue, 2009-09-22 at 09:28 +0200, Ingo Molnar wrote:
> > > > > > 
> > > > > > Nevertheless you are right that i should have caught this particular 
> > > > > > PowerPC build bug - i missed it - sorry about that!
> > > > > > 
> > > > > Allright. Well, to help in general, we are setting up a build-bot
> > > > > here too that will build -tip HEAD for at least powerpc daily with
> > > > > a few configs too.
> > > > 
> > > > Results here:
> > > > 
> > > > http://kisskb.ellerman.id.au/kisskb/branch/12/
> > > 
> > > ok, seems green for today - the two failures are: one a powerpc 
> > > toolchain problem it appears, plus a mainline warning.
> > 
> > Yep that looks more or less normal.
> > 
> > > Btw., for me to be able to notice failures there it would have to 
> > > email me automatically if there's any -tip build failures that do 
> > > not occur with the upstream branch. Does it have such a feature?
> > 
> > Not really, it sends mails to me, but it doesn't have a way to filter 
> > them by branch. I think the plan is we'll keep an eye on it and either 
> > send you patches or at least let you know that it's broken.
> 
> how many mails are those per day, typically? If there's not too many and 
> if there's a way to send all of them to me i could post-filter them for 
> -tip relevance. If that is feasible. You bouncing it to me later is 
> certainly also a solution. (but lengthens the latency of fixes, 
> obviously.)

Lots of mails - there are an insane number of arm configs for
starters :)

Give me a day or two, I should be able to add a per-branch setting for
who to send mails to without too much trouble.

cheers

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename

[Stephen Rothwell]

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

Hi Ingo,

On Thu, 24 Sep 2009 23:25:55 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
>
> Give me a day or two, I should be able to add a per-branch setting for
> who to send mails to without too much trouble.

In the mean time I don't now if someone has pointed you at these today:

http://kisskb.ellerman.id.au/kisskb/branch/12/

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

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

Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename

[Ingo Molnar]

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

> Hi Ingo,
> 
> On Thu, 24 Sep 2009 23:25:55 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
> >
> > Give me a day or two, I should be able to add a per-branch setting for
> > who to send mails to without too much trouble.
> 
> In the mean time I don't now if someone has pointed you at these today:
> 
> http://kisskb.ellerman.id.au/kisskb/branch/12/

That's an upstream warning.

-tip supports fail-on-build-warnings build mode (for the whole kernel) 
via the CONFIG_ALLOW_WARNINGS .config setting. So if you do allnoconfig 
builds, make sure you turn on CONFIG_ALLOW_WARNINGS=y to get the same 
build behavior as with Linus's tree.

	Ingo

Re: [PATCH] perf_event, powerpc: Fix compilation after big perf_counter rename

[Stephen Rothwell]

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

Hi Ingo,

On Thu, 1 Oct 2009 09:42:01 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > On Thu, 24 Sep 2009 23:25:55 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
> > >
> > > Give me a day or two, I should be able to add a per-branch setting for
> > > who to send mails to without too much trouble.
> > 
> > In the mean time I don't now if someone has pointed you at these today:
> > 
> > http://kisskb.ellerman.id.au/kisskb/branch/12/
> 
> That's an upstream warning.

When I sent that to you, I was referring to these build results:

http://kisskb.ellerman.id.au/kisskb/buildresult/1307802/

which (as you say) was only a waning in the rest of the kernel but is
turned into an error by the -Werror we use when building arch/powerpc.
The warning came from commit 4765c1db84c73f775eb1822a009117cbae524e9e
("rcu-tiny: The Bloatwatch Edition, v6") in the -tip tree and fixed by
commit 5ef9b8e59c043624fb44e31439cecf7f8b4cd62a ("rcu: Clean up the
warning message about RCU not defined") the next day (in the -tip tree).
So no big problem.  Neither of these commits are upstream.

I was just filling in the role of notifying you of build problems until
Michael can automate it.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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