[PATCH] oprofile: re-arm APIC_DM_NMI in ppro_check_ctrs()

[Eric Dumazet]

Andi Kleen a écrit :
> Eric Dumazet <dada1@xxxxxxxxxxxxx> writes:
>
> > diff --git a/arch/x86/oprofile/op_model_ppro.c b/arch/x86/oprofile/op_model_ppro.c
> > index 3f1b81a..716d26f 100644
> > --- a/arch/x86/oprofile/op_model_ppro.c
> > +++ b/arch/x86/oprofile/op_model_ppro.c
> > @@ -69,7 +69,7 @@ static void ppro_setup_ctrs(struct op_msrs const * const msrs)
> >  	int i;
> >  
> >  	if (!reset_value) {
> > -		reset_value = kmalloc(sizeof(unsigned) * num_counters,
> > +		reset_value = kmalloc(sizeof(reset_value[0]) * num_counters,
>
> Thanks for tracking this down.
>
> But that still doesn't explain why 2.6.27 fails too?

Desesperatly Seeking Oprofile, next round.

I know *nothing* about APIC but spent few hours to try several tricks
and finally found something.

It solved my problem : oprofile can run several hours without
any freeze of NMI on any core.

# grep NMI /proc/interrupts
NMI:   10902884    9635871   10333815    8372989    7971483    8298373    8877495   10206963   Non-maskable interrupts
...
# grep NMI /proc/interrupts
NMI:   15518834   14340713   15038694   13078235   12676585   13003394   13582115   14912146   Non-maskable interrupts


Can anybody understand and explain what is happening ?

Is it a software or hardware problem ?

[PATCH] oprofile: re-arm APIC_DM_NMI in ppro_check_ctrs()

While using oprofile on my HP BL460c G1, (two quad core intel E5450 CPU),
I noticed that one CPU after the other could not get anymore NMI.

After a while, all cores where blocked (ie not generating events for oprofile)
I tried all major linux versions and all where affected by this freeze.

I found that we have to re-arm APIC_DM_NMI *before* writing to MSR counter
when we get event notification.

Signed-off-by: Eric Dumazet <dada1@xxxxxxxxxxxxx>
arch/x86/oprofile/op_model_ppro.c |    8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/x86/oprofile/op_model_ppro.c b/arch/x86/oprofile/op_model_ppro.c
index 3f1b81a..7b142da 100644
--- a/arch/x86/oprofile/op_model_ppro.c
+++ b/arch/x86/oprofile/op_model_ppro.c
@@ -132,13 +132,15 @@ static int ppro_check_ctrs(struct pt_regs * const regs,
 		rdmsrl(msrs->counters[i].addr, val);
 		if (CTR_OVERFLOWED(val)) {
 			oprofile_add_sample(regs, i);
+			/*
+			 * We need to unmask the apic vector *before*
+			 * writing reset_value to msr counter
+			 */
+			apic_write(APIC_LVTPC, APIC_DM_NMI);
 			wrmsrl(msrs->counters[i].addr, -reset_value[i]);
 		}
 	}
 
-	/* Only P6 based Pentium M need to re-unmask the apic vector but it
-	 * doesn't hurt other P6 variant */
-	apic_write(APIC_LVTPC, apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED);
 
 	/* We can't work out if we really handled an interrupt. We
 	 * might have caught a *second* counter just after overflowing