On 08/08/13 05:09, Will Deacon wrote:
> Well spotted, thanks. If you make that return -EINVAL instead of -ENOENT (to
> match what we do for cache events) then:
>
> Acked-by: Will Deacon
>
> Could you stick it in the patch system please?
Submitted as 7810/1
--
Qualcomm Innovation Center, Inc.
On Thu, 8 Aug 2013, Will Deacon wrote:
> On the flip side, the good news is that we know the problem is there. We're
> probably generating interrupts at some horrendous rate for the lock-up
> are you running your fuzzer as root?
No, I'm running the fuzzer as a regular user.
> Also, is your
On Thu, Aug 08, 2013 at 03:53:31AM +0100, Vince Weaver wrote:
> On Wed, 7 Aug 2013, Vince Weaver wrote:
> > On Wed, 7 Aug 2013, Stephen Boyd wrote:
> > > diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> > > index d9f5cd4..21f7790 100644
> > > ---
On Thu, Aug 08, 2013 at 12:18:08AM +0100, Stephen Boyd wrote:
> Is config some really big value? It looks like config (or more
> specifically event->attr.config) is ecececec which is larger than 9
> (PERF_COUNT_HW_MAX). I'm fairly certain r4 is event->attr.type
> (PERF_TYPE_HARDWARE) and so we're
On Thu, Aug 08, 2013 at 12:18:08AM +0100, Stephen Boyd wrote:
Is config some really big value? It looks like config (or more
specifically event-attr.config) is ecececec which is larger than 9
(PERF_COUNT_HW_MAX). I'm fairly certain r4 is event-attr.type
(PERF_TYPE_HARDWARE) and so we're out of
On Thu, Aug 08, 2013 at 03:53:31AM +0100, Vince Weaver wrote:
On Wed, 7 Aug 2013, Vince Weaver wrote:
On Wed, 7 Aug 2013, Stephen Boyd wrote:
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index d9f5cd4..21f7790 100644
--- a/arch/arm/kernel/perf_event.c
+++
On Thu, 8 Aug 2013, Will Deacon wrote:
On the flip side, the good news is that we know the problem is there. We're
probably generating interrupts at some horrendous rate for the lock-up
are you running your fuzzer as root?
No, I'm running the fuzzer as a regular user.
Also, is your
On 08/08/13 05:09, Will Deacon wrote:
Well spotted, thanks. If you make that return -EINVAL instead of -ENOENT (to
match what we do for cache events) then:
Acked-by: Will Deacon will.dea...@arm.com
Could you stick it in the patch system please?
Submitted as 7810/1
--
Qualcomm Innovation
On Wed, 7 Aug 2013, Vince Weaver wrote:
> On Wed, 7 Aug 2013, Stephen Boyd wrote:
>
> > ---8<
> >
> > diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> > index d9f5cd4..21f7790 100644
> > --- a/arch/arm/kernel/perf_event.c
> > +++ b/arch/arm/kernel/perf_event.c
> >
On Wed, 7 Aug 2013, Stephen Boyd wrote:
> ---8<
>
> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> index d9f5cd4..21f7790 100644
> --- a/arch/arm/kernel/perf_event.c
> +++ b/arch/arm/kernel/perf_event.c
> @@ -53,7 +53,12 @@ armpmu_map_cache_event(const unsigned
On Wed, 7 Aug 2013, Stephen Boyd wrote:
> Is config some really big value? It looks like config (or more
> specifically event->attr.config) is ecececec which is larger than 9
> (PERF_COUNT_HW_MAX). I'm fairly certain r4 is event->attr.type
> (PERF_TYPE_HARDWARE) and so we're out of bounds on that
On 08/07/13 15:31, Will Deacon wrote:
> On Wed, Aug 07, 2013 at 09:14:55PM +0100, Vince Weaver wrote:
>
>> [ 388.509063] Unable to handle kernel paging request at virtual address
>> 73fd14cc
>> [ 388.509063] pgd = eca6c000
>> [ 388.519805] [73fd14cc] *pgd=
>> [ 388.523651] Internal
On Wed, Aug 07, 2013 at 09:14:55PM +0100, Vince Weaver wrote:
> Hello
Hi Vince,
> I don't have time to come up with a test case right now, but I've
> applied the patch to fix the oops from two days ago, and re-ran
> my perf_fuzzer tool and it immediately came up with another issue on ARM.
> This
Hello
I don't have time to come up with a test case right now, but I've
applied the patch to fix the oops from two days ago, and re-ran
my perf_fuzzer tool and it immediately came up with another issue on ARM.
This is an ARM Pandaboard running 3.11-rc4 with the one-line
oops fix from the other
Hello
I don't have time to come up with a test case right now, but I've
applied the patch to fix the oops from two days ago, and re-ran
my perf_fuzzer tool and it immediately came up with another issue on ARM.
This is an ARM Pandaboard running 3.11-rc4 with the one-line
oops fix from the other
On Wed, Aug 07, 2013 at 09:14:55PM +0100, Vince Weaver wrote:
Hello
Hi Vince,
I don't have time to come up with a test case right now, but I've
applied the patch to fix the oops from two days ago, and re-ran
my perf_fuzzer tool and it immediately came up with another issue on ARM.
This is
On 08/07/13 15:31, Will Deacon wrote:
On Wed, Aug 07, 2013 at 09:14:55PM +0100, Vince Weaver wrote:
[ 388.509063] Unable to handle kernel paging request at virtual address
73fd14cc
[ 388.509063] pgd = eca6c000
[ 388.519805] [73fd14cc] *pgd=
[ 388.523651] Internal error: Oops: 5
On Wed, 7 Aug 2013, Stephen Boyd wrote:
Is config some really big value? It looks like config (or more
specifically event-attr.config) is ecececec which is larger than 9
(PERF_COUNT_HW_MAX). I'm fairly certain r4 is event-attr.type
(PERF_TYPE_HARDWARE) and so we're out of bounds on that array
On Wed, 7 Aug 2013, Stephen Boyd wrote:
---8
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index d9f5cd4..21f7790 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -53,7 +53,12 @@ armpmu_map_cache_event(const unsigned
On Wed, 7 Aug 2013, Vince Weaver wrote:
On Wed, 7 Aug 2013, Stephen Boyd wrote:
---8
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index d9f5cd4..21f7790 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -53,7 +53,12
20 matches
Mail list logo
