lkml.org 
[lkml]   [2008]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    Subject[PATCH] oprofile: re-arm APIC_DM_NMI in ppro_check_ctrs()
    Andi Kleen a écrit :
    > Eric Dumazet <dada1@cosmosbay.com> 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@cosmosbay.com>
    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
    \
     
     \ /
      Last update: 2008-11-10 15:25    [W:0.101 / U:58.608 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site