Messages in this thread |  | | Date | Mon, 18 Nov 2013 17:58:45 +0100 | Subject | Re: perf sw_event related lockup | From | Stephane Eranian <> |
| |
On Mon, Nov 18, 2013 at 5:44 PM, Vince Weaver <vincent.weaver@maine.edu> 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
|  |