Andi Kleen a écrit : > Eric Dumazet 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 arch/x86/oprofile/op_model_ppro.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-)