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_at_ 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.Received on Mon Oct 15 2012 - 06:12:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:31 UTC