On Thu, May 10, 2012 at 10:44 AM, Will Deacon wrote:
> On Wed, May 09, 2012 at 10:45:08PM +0100, Jon Hunter wrote:
>> Hi All,
>
> Hi Jon,
>
>> I have posted my latest series here [1] based upon that from Will [2]
>> which attempts to fix the EMU CD based upon the inputs from this thread.
>> It is
On Mon, Jan 30, 2012 at 8:14 PM, Will Deacon wrote:
> On Mon, Jan 30, 2012 at 05:45:19PM +0000, stephane eranian wrote:
>> There you go, no attachment, not sure the omap list
>> supports this.
>
> Cheers Stephane.
>
>> There is something quite interesting to observe.
oop for %d seconds\n", delay);
alarm(delay);
noploop();
return 0;
}
On Mon, Jan 30, 2012 at 6:24 PM, Will Deacon wrote:
> On Mon, Jan 30, 2012 at 05:15:53PM +, stephane eranian wrote:
>> Still need to investigate why the frequency mode does
>> not yield the c
On Mon, Jan 30, 2012 at 5:08 PM, Måns Rullgård wrote:
> stephane eranian writes:
>
>> Same result for me on CPU1:
>>
>> top - 16:20:24 up 1:45, 1 user, load average: 0.29, 0.08, 0.07
>> Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie
>&g
on, Jan 30, 2012 at 3:49 PM, Ming Lei wrote:
> On Mon, Jan 30, 2012 at 9:43 PM, stephane eranian
> wrote:
>> Same results for me with 3.3.0-rc1 + 5 patches.
>
> In fact, I think the only effect of the patch is to enable pmu
> interrupt handling,
> which may cause so much dif
0:00.63 top
1 root 20 0 2564 1532 952 S 0 0.2 0:01.26 init
I am connecting to the board via ssh.
But the results don't look correct to me.
On Mon, Jan 30, 2012 at 11:24 AM, stephane eranian
wrote:
> Ok, let me try again with 3.3.0-rc1, that was with 3.2.0.
> The
Ok, let me try again with 3.3.0-rc1, that was with 3.2.0.
The only thing that changed was that one line and it made
a big difference.
On Mon, Jan 30, 2012 at 10:40 AM, Ming Lei wrote:
> Hi,
>
> On Mon, Jan 30, 2012 at 1:36 AM, stephane eranian
> wrote:
>> Hi,
>>
&g
rupts, it breaks the timer tick logic somehow.
The perf problem is related to timer tick.
I am hoping that the tradeoff is not:
PMU interrupts but broken timer ticks
vs.
No PMU interrupts but working timer ticks
On Fri, Jan 27, 2012 at 6:16 PM, stephane eranian
wrote:
> On Fri, Jan
On Fri, Jan 27, 2012 at 6:10 PM, Will Deacon wrote:
> On Fri, Jan 27, 2012 at 05:03:28PM +0000, stephane eranian wrote:
>> On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon wrote:
>> > That said, if you see any bugs in the code please do shout!
>> >
>> I suspect there
On Fri, Jan 27, 2012 at 5:59 PM, Will Deacon wrote:
> On Fri, Jan 27, 2012 at 03:57:25PM +0000, stephane eranian wrote:
>> On Fri, Jan 27, 2012 at 4:54 PM, Will Deacon wrote:
>> >
>> > Ok. Note that on ARM the PMU generates a standard IRQ (i.e. not an NMI) so
>&g
On Fri, Jan 27, 2012 at 4:54 PM, Will Deacon wrote:
> On Fri, Jan 27, 2012 at 03:45:53PM +0000, stephane eranian wrote:
>> Hi,
>
> Hi Stephane,
>
>> Ok, with the one-line patch [1], this works much better now.
>> No more wrap around a 4 billion cycles.
>
>
Hi,
Ok, with the one-line patch [1], this works much better now.
No more wrap around a 4 billion cycles.
Sampling is okay, though I noticed it tends to not get the
correct number of samples for a controlled run:
$ perf record -e cycles -c 1009213 noploop 10
noploop for 10 seconds
$ perf report
2012/1/27 Will Deacon :
> Mans,
>
> On Fri, Jan 27, 2012 at 12:56:35PM +, Måns Rullgård wrote:
>> Will Deacon writes:
>> > Did this lead anywhere in the end? It seems as though Ming Lei has a
>> > working
>> > setup but Stephane is unable to replicate it, despite applying the
>> > necessary
On Fri, Jan 27, 2012 at 1:13 PM, Will Deacon wrote:
> Hi guys,
>
> On Sat, Jan 21, 2012 at 09:16:57AM +, stephane eranian wrote:
>> On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei wrote:
>> > On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian
>> >
On Sat, Jan 21, 2012 at 4:25 AM, Ming Lei wrote:
> On Fri, Jan 20, 2012 at 9:47 PM, stephane eranian
> wrote:
>> Started afresh from:
>>
>> 90a4c0f uml: fix compile for x86-64
>>
>> And added 3, 4, 5, 6:
>> 603c316 arm: omap4: pmu: support runtime pm
>
.config file.
My HW:
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x1
CPU part: 0xc09
CPU revision: 2
Hardware: OMAP4 Panda board
Revision: 0020
There must be something I am missing here.
On Thu, Jan 19, 2012 at 6:07 PM, stephane eranian
wrote
s you were referring to a different pair of patches.
On Thu, Jan 19, 2012 at 2:51 PM, Ming Lei wrote:
> Hi,
>
> On Thu, Jan 19, 2012 at 9:32 PM, stephane eranian
> wrote:
>> On Thu, Jan 19, 2012 at 2:26 PM, Ming Lei wrote:
>>> Hi,
>>>
>>> On Thu, Jan 1
On Thu, Jan 19, 2012 at 2:26 PM, Ming Lei wrote:
> Hi,
>
> On Thu, Jan 19, 2012 at 9:14 PM, Ming Lei wrote:
>> On Thu, Jan 19, 2012 at 8:51 PM, stephane eranian
>> wrote:
>>> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei wrote:
>>>> Hi,
>>>>
On Thu, Jan 19, 2012 at 1:51 PM, stephane eranian
wrote:
> On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei wrote:
>> Hi,
>>
>> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
>> wrote:
>>> Hi,
>>>
>>> Ok some update on this.
>>> Wit
On Thu, Jan 19, 2012 at 1:45 PM, Ming Lei wrote:
> Hi,
>
> On Thu, Jan 19, 2012 at 7:34 PM, stephane eranian
> 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
>
> Yo
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 wrote:
> Hi,
>
> On Thu, Jan 19, 2012 at 5:58 AM, stephane eranian
> wrote:
>> Ming,
>>
>> Ok, so I used Linus&#x
7 AM, Ming Lei wrote:
> Hi,
>
> On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian
>> 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.
>
>&
On Wed, Jan 18, 2012 at 5:18 AM, Ming Lei wrote:
> Hi stephane & Will,
>
> On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian
> wrote:
>> See the dmesg from my 3.2 kernel:
>>
>>
>> [ 0.00] Booting Linux on physical CPU 0[ 0.00]
>
> L
See the dmesg from my 3.2 kernel:
[ 0.00] Booting Linux on physical CPU 0[ 0.00]
Initializing cgroup subsys cpuset[ 0.00] Initializing cgroup
subsys cpu[ 0.00] Linux version 3.2.0-omap4 (eranian@panda)
(gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #9 SMP PR[
0.00
Hi,
I am trying to get perf_event to work properly on my OMAP4 Pandabaord
running the 3.2.0 kernel. I am the developer on libpfm4 and a regular
contributor to the perf_event subsystem and perf tool. I want to use
a Pandaboard to test libpfm4 ARM support.
I have been talking with Will Deacon and h
25 matches
Mail list logo
