[CFT]hwpmc update for sandybridge-e
Fabien Thomas
fabien.thomas at netasq.com
Mon Oct 15 08:12:53 UTC 2012
Le 13 oct. 2012 à 00:54, hiren panchasara a écrit :
>
>
> On Fri, Oct 5, 2012 at 1:05 AM, Fabien Thomas <fabien.thomas at netasq.com> wrote:
>
> Le 5 oct. 2012 à 10:00, Fabien Thomas a écrit :
>
> >
> > Le 5 oct. 2012 à 00:46, Sean Bruno a écrit :
> >
> >> So, I did the bear minimum and kind of hacked things together without
> >> understanding precisely what I was doing, and I was able to massage the
> >> sandybridge-e CPUs into giving me some basic functions.
> >>
> >> Comments or concerns before I commit this?
> >>
> >> http://people.freebsd.org/~sbruno/pmc_sandybridge.txt
> >
> > Hi Sean,
> >
> > The only modification required is this one
> > http://svnweb.freebsd.org/base?view=revision&revision=237196
> >
> > but davide@ removed it for a problem that need to be looked at.
>
> Looking at the doc this CPU require a full set of PMC as the list of event are different.
> So this mean full manpage, full event list, …
>
> Doc:
> "
> The events in Table 19-3 apply to
> processors with CPUID signature of DisplayFamily_DisplayModel encoding with the
> following values: 06_2AH and 06_2DH. The events in Table 19-4 apply to processors
> with CPUID signature 06_2AH. The events in Table 19-5 apply to processors with
> CPUID signature 06_2DH.
> "
>
> Required change will be the same as this commit if you want to look at it:
> http://svnweb.freebsd.org/base?view=revision&revision=240164
>
> Hi All,
>
> With help of Sean, I've prepared another semi-working patch:
> http://www.strugglingcoder.info/patches/hwpmc_sbx_1.txt
Great, i've quickly looked at the patch:
I'm not sure to understand why you have removed code in your case for uncore.
If you dont want to support remove it like for ivy bridge.
some minor:
+#define sandybridge_xeon_aliases core2_aliases
+#define sandybridge_xeon_aliases_without_iaf core2_aliases_without_iaf
+ case PMC_CPU_INTEL_SANDYBRIDGE_XEON:
+ pmc_class_table[n++] = &ucf_class_table_descr;
+ pmc_class_table[n++] = &sandybridgeuc_class_table_descr;
+ PMC_MDEP_INIT_INTEL_V2(sandybridge_xeon);
+ break;
keep this sorted.
>
> I still haven't written the man page. I wanted to get some feedback (bashing/yelling) before spending more time on this.
>
> I am not quite sure how to handle uncore events. I've put ugly hack to avoid wrmsr/rdmsr for this particular set of processors. I bet there are better ways to handle this situation. (in hwpmc_uncore.c)
>
> Here is the o/p of "pmccontrol -L":
> http://www.strugglingcoder.info/patches/pmccontrol_1.txt
>
> I've run the pmctest.py script (by gnn):
> http://www.strugglingcoder.info/patches/pmctestpy_1.txt
>
> I am seeing "invalid argument" for some events. I've tried to check pmc_events.h to see that those events are listed. Not sure what else I should check.
>
Seems you need to double check the event list:
"pmcstat: ERROR: Cannot allocate process-mode pmc with specification "L2_L1D_WB_RQSTS.MISS": Invalid argument"
map to 28 01 which is not in the table:
IAPDESCR(28H, 0x28, IAP_M_CORE | IAP_M_MESI, IAP_F_ALLCPUSCORE2),
IAPDESCR(28H_01H, 0x28, 0x01, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_IB),
IAPDESCR(28H_02H, 0x28, 0x02, IAP_F_FM | IAP_F_I7 | IAP_F_WM),
- IAPDESCR(28H_04H, 0x28, 0x04, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_IB),
- IAPDESCR(28H_08H, 0x28, 0x08, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_IB),
+ IAPDESCR(28H_04H, 0x28, 0x04, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_IB |
+ IAP_F_SBX),
+ IAPDESCR(28H_08H, 0x28, 0x08, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_IB |
+ IAP_F_SBX),
IAPDESCR(28H_0FH, 0x28, 0x0F, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_IB),
> I've also tried to follow the commands Fabien listed for testing on http://freebsd.1045724.n5.nabble.com/CFT-hwpmc-support-for-Intel-Ivy-Bridge-tp5740299p5740577.html
>
> I am getting panic on following:
> - Soft counter:
> pmcstat -SPAGE_FAULT.ALL -w4 -T
>
Not related but need to be investigated. (I will look at it.)
> panic details:
> -bash-4.2$ panic: userret: Returning with with pinned thread
> cpuid = 22
> KDB: enter: panic
> [ thread pid 4084 tid 100302 ]
> Stopped at kdb_enter+0x3b: movq $0,0xa74122(%rip)
> db> bt
> Tracing pid 4084 tid 100302 td 0xfffffe0016dbc000
> kdb_enter() at kdb_enter+0x3b
> panic() at panic+0x1d1
> userret() at userret+0x15c
> trap() at trap+0x200
> calltrap() at calltrap+0x8
> --- trap 0xc, rip = 0x8013d86a0, rsp = 0x7fffffffd4b0, rbp = 0x801800b98 ---
> db> show pcpu
> cpuid = 22
> dynamic pcpu = 0xffffff807f000280
> curthread = 0xfffffe0016dbc000: pid 4084 "pmcstat"
> curpcb = 0xffffff86be955b80
> fpcurthread = 0xfffffe0016dbc000: pid 4084 "pmcstat"
> idlethread = 0xfffffe000a510000: tid 100025 "idle: cpu22"
> curpmap = 0xfffffe00160f6be8
> tssp = 0xffffffff81531970
> commontssp = 0xffffffff81531970
> rsp0 = 0xffffff86be955b80
> gs32p = 0xffffffff8152faa8
> ldt = 0xffffffff8152fae8
> tss = 0xffffffff8152fad8
> spin locks held:
>
> db> show registers
> cs 0x20
> ds 0x3b
> es 0x3b003b
> fs 0x1b0013
> gs 0x1b
> ss 0
> rax 0x12
> rcx 0x1fc
> rdx 0
> rbx 0xffffffff80ec14ea __func__.3526+0x1c2
> rsp 0xffffff86be955770
> rbp 0xffffff86be955790
> rsi 0x80
> rdi 0xffffff86be9555f0
> r8 0
> r9 0xffffff86be9556a0
> r10 0x700
> r11 0xffffffff812c2900 txtrndrsw
> r12 0
> r13 0xfffffe0016dbc000
> r14 0xffffff86be955ac0
> r15 0xc
> rip 0xffffffff80901f1b kdb_enter+0x3b
> rflags 0x86
> kdb_enter+0x3b: movq $0,0xa74122(%rip)
> db>
>
> Please let me know if anything else I can provide.
>
> Thanks a ton,
> Hiren
>
> p.s. I don't know how computers work.
More information about the freebsd-current
mailing list