On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei <ming.lei@xxxxxxxxxxxxx> wrote: > Hi, > > On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian > <eranian@xxxxxxxxxxxxxx> wrote: >> Hi, >> >> Ok some update on this. >> With your .config file + 3.2.0 (Linus) + patch 3, 4, 5, 6, I get a kernel that > > You forget patch 1 and patch 2? > They are already in 3.2.0. Unless I am mistaken. are you sure you don't have anything else applied? >> boots. It does recognize the PMU. However, it still does not count correctly >> and I believe for the same reason.: no interrupts are delivered. >> >> I run a cycle burner program on CPU0, I watch /proc/interrupts. >> and then I run libpfm4 program that does per-cpu monitoring on CPU0 and >> print the counts every second: > > I just run 'perf top', then watch output of '/proc/interrupts' in > another terminal. I am sure I can see perf is OK and interrupts are > generated on my pandaboard. > >> >> $ sudo ./syst_count -d 10 -p -c 0 -e cpu_cycles >> <press CTRL-C to quit before 10s time limit> >> # 1s ----- >> CPU0 G0 1008129147 cpu_cycles (scaling 0.00%, >> ena=1000152588, run=1000152588) >> # 2s ----- >> CPU0 G0 2016240766 cpu_cycles (scaling 0.00%, >> ena=2000335693, run=2000335693) >> # 3s ----- >> CPU0 G0 3024249265 cpu_cycles (scaling 0.00%, >> ena=3000427245, run=3000427245) >> # 4s ----- >> CPU0 G0 4072779364 cpu_cycles (scaling 0.00%, >> ena=4040710449, run=4040710449) >> # 5s ----- >> CPU0 G0 785954705 cpu_cycles (scaling 0.00%, >> ena=5040954589, run=5040954589) >> # 6s ----- >> CPU0 G0 1803397848 cpu_cycles (scaling 0.00%, >> ena=6050384520, run=6050384520) >> # 7s ----- >> >> You clearly see that after 4s you've reached the 32-bit limit of the >> counter and then you wrap around. >> It should show 5 billions or so cycles. Over the entire run, no >> arm-pmu interrupt was delivered according >> to /proc/interrupts. >> >> I guess you can test the same condition using perf directly, use a >> program that burns cycles >> for a know duration. Try < 4s and then > 4s. I use 1s vs. 10s and I >> expect the count to be >> 10x larger in the latter test case. If it's not then, interrupts are >> not coming in, >> >> >> On Thu, Jan 19, 2012 at 2:21 AM, Ming Lei <ming.lei@xxxxxxxxxxxxx> wrote: >>> Hi, >>> >>> On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian >>> <eranian@xxxxxxxxxxxxxx> wrote: >>>> Ming, >>>> >>>> Ok, so I used Linus' tree @ >>>> >>>> It already includes patches #1 and #2. I applied 4-6. >>> >>> The patch #3 is missed? >>> >>>> Recompiled but my kernel does not boot, I don't see >>>> anything on the serial console. Could be a broken >>> >>> I don't think that the patches can cause your non boot, you >>> can try the linus tree kernel first, then try the patches. >>> >>>> .config file. Could you send me your .config for Panda? >>> >>> See the attachment. >>> >>>> >>>> Thanks. >>>> >>>> On Wed, Jan 18, 2012 at 11:07 AM, Ming Lei <ming.lei@xxxxxxxxxxxxx> wrote: >>>>> Hi, >>>>> >>>>> On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <eranian@xxxxxxxxxxxxxx> >>>>>> Should I use Will's -next tree as the base instead of Linus'? >>>>> >>>>> Either one is OK. If you use linus tree as base, you need to apply the #1 and >>>>> #2 patch manually. >>>>> >>>>>> Given that MARC is shutdown today, would you mind packing those patches >>>>>> into a tarball and sending them to me directly? >>>>> >>>>> See attachment, which includes the patches from #3 to #6. >>>>> >>>>>> >>>>>> When you mention Will's -next tree, are you talking about: >>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf >>>>> >>>>> It is perf/omap4 brach, you can pick up the two patches[1][2] directly from >>>>> the branch. >>>>> >>>>> >>>>> thanks, >>>>> -- >>>>> Ming Lei >>>>> >>>>> [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c >>>>> >>>>> [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in >>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
