Re: perf sw_event related lockup

[Stephane Eranian]

On Mon, Nov 18, 2013 at 5:44 PM, Vince Weaver <vincent.weaver@xxxxxxxxx> wrote:
> On Mon, 18 Nov 2013, Stephane Eranian wrote:
>
>> What's the config for this test?
>> Need to host CPU type and the event config.
>> Otherwise there is not much I can do with the crash dump.
>
> It's 3.12, on a core2 machine.
>
On core2, there is no offcore-response event, therefore you should not
get to the shared_reg_*() code OR it should return immediately. Looks
like here, it calls into it and finds some pointers NULL:
cpuc->shared_regs, I bet.

Now, I am trying to understand how we got there:

        xreg = &event->hw.extra_reg;
        if (xreg->idx != EXTRA_REG_NONE) {
                c = __intel_shared_reg_get_constraints(cpuc, event, xreg);

        }

        breg = &event->hw.branch_reg;
        if (breg->idx != EXTRA_REG_NONE) {
                d = __intel_shared_reg_get_constraints(cpuc, event, breg);
        }

So one of those tests is true.

That means breg->idx is pointing to a LBR_SELECT MSR but that does
not exist on Core2, or xreg->idx is pointing to a shared resource
which does not exist either.
For the former, it would mean it thinks there is hw LBR filtering, but
that's wrong. For the latter, it means it thinks that Core 2 has a
x86_pmu.extra_regs. I would check those two cases. Don't know
how this could happen.

I could debug this but I don't have a Core 2 machine that I can
easily crash. But maybe I can fake this on a IVB laptop. Just
would need the perf_event_attr struct.


ly I don't have the event config.  To reproduce I start my perf_fuzzer
> running and typically it will hit the error/lockup within an hour or so
> of fuzzing assuming it doesn't hit one of the other outstanding bugs
> first.
>
> I can probably narrow it down but that involves a lot of luck as well as a
> lot of time and I might not get a chance to do so until next month at the
> earliest.
>
> Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/