On Fri 2019-01-25 08:00:56, Andi Kleen wrote:
> > [Fri Jan 25 10:28:53 2019] perf: interrupt took too long (2501 > 2500),
> > lowering kernel.perf_event_max_sample_rate to 79750
> > [Fri Jan 25 10:29:08 2019] perf: interrupt took too long (3136 > 3126),
> > lowering kernel.perf_event_max_sample_r
On Fri, 1 Feb 2019, Jiri Olsa wrote:
> >
> > I've just started fuzzing with the patch applied. Often it takes a few
> > hours to trigger the bug.
>
> cool, thanks
I let it run overnight and no crash.
> > Added question about this bug. It appeared that the crash was triggered
> > by the BTS
On Sat, Feb 02, 2019 at 08:54:35AM +0530, Ravi Bangoria wrote:
>
>
> On 2/1/19 1:24 PM, Ravi Bangoria wrote:
> > I ran fuzzer for couple of hours but I didn't see any crash with
> > your previous patch.
> >
> > I'll try this newer one as well.
>
> I ran fuzzer for ~8 hrs and no lockup so far.
On 2/1/19 1:24 PM, Ravi Bangoria wrote:
> I ran fuzzer for couple of hours but I didn't see any crash with
> your previous patch.
>
> I'll try this newer one as well.
I ran fuzzer for ~8 hrs and no lockup so far.
Thanks.
On Fri, Feb 01, 2019 at 11:27:28AM -0500, Vince Weaver wrote:
> On Fri, 1 Feb 2019, Jiri Olsa wrote:
>
> > with attached patch I did not trigger the fuzzer crash
> > for over a day now, could you guys try?
>
> I've just started fuzzing with the patch applied. Often it takes a few
> hours to tri
On Fri, 1 Feb 2019, Jiri Olsa wrote:
> with attached patch I did not trigger the fuzzer crash
> for over a day now, could you guys try?
I've just started fuzzing with the patch applied. Often it takes a few
hours to trigger the bug.
Added question about this bug. It appeared that the crash wa
Hi Jiri,
On 2/1/19 1:13 PM, Jiri Olsa wrote:
> On Thu, Jan 31, 2019 at 09:27:11AM +0100, Jiri Olsa wrote:
>> On Wed, Jan 30, 2019 at 07:36:48PM +0100, Jiri Olsa wrote:
>>
>> SNIP
>>
>>> diff --git a/kernel/events/core.c b/kernel/events/core.c
>>> index 280a72b3a553..22ec63a0782e 100644
>>> --- a/k
On Thu, Jan 31, 2019 at 09:27:11AM +0100, Jiri Olsa wrote:
> On Wed, Jan 30, 2019 at 07:36:48PM +0100, Jiri Olsa wrote:
>
> SNIP
>
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index 280a72b3a553..22ec63a0782e 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> Yeah, a loop stuck looks really scary inside an NMI handler.
> Should I just go ahead to send a patch to remove this warning?
> Or probably turn it into a pr_info()?
Not at this point. Would need to fix the PMU reset first to be
more selective.
-Andi
On Fri, Jan 25, 2019 at 8:02 AM Andi Kleen wrote:
>
> > [Fri Jan 25 10:28:53 2019] perf: interrupt took too long (2501 > 2500),
> > lowering kernel.perf_event_max_sample_rate to 79750
> > [Fri Jan 25 10:29:08 2019] perf: interrupt took too long (3136 > 3126),
> > lowering kernel.perf_event_max_s
On Thu, Jan 31, 2019 at 01:28:34PM +0530, Ravi Bangoria wrote:
> Hi Andi,
>
> On 1/25/19 9:30 PM, Andi Kleen wrote:
> >> [Fri Jan 25 10:28:53 2019] perf: interrupt took too long (2501 > 2500),
> >> lowering kernel.perf_event_max_sample_rate to 79750
> >> [Fri Jan 25 10:29:08 2019] perf: interrupt
On Wed, Jan 30, 2019 at 07:36:48PM +0100, Jiri Olsa wrote:
SNIP
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 280a72b3a553..22ec63a0782e 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -4969,6 +4969,26 @@ static void __perf_event_period(struct perf_event
Hi Andi,
On 1/25/19 9:30 PM, Andi Kleen wrote:
>> [Fri Jan 25 10:28:53 2019] perf: interrupt took too long (2501 > 2500),
>> lowering kernel.perf_event_max_sample_rate to 79750
>> [Fri Jan 25 10:29:08 2019] perf: interrupt took too long (3136 > 3126),
>> lowering kernel.perf_event_max_sample_rat
On Wed, Jan 30, 2019 at 07:36:48PM +0100, Jiri Olsa wrote:
> On Fri, Jan 25, 2019 at 12:16:27PM +0530, Ravi Bangoria wrote:
>
> SNIP
>
> > [ 1432.176374] general protection fault: [#1] SMP PTI
> > [ 1432.182253] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW
> > 5.0.0-rc
On Wed, Jan 30, 2019 at 12:39:47PM -0800, Andi Kleen wrote:
> Jiri Olsa writes:
> >
> > the patch adds check_eriod pmu callback.. I need to check if there's
> > better way to do this, but so far it fixes the crash for me
> >
> > if you guys could check this patch, that'd be great
>
> There's alre
Jiri Olsa writes:
>
> the patch adds check_eriod pmu callback.. I need to check if there's
> better way to do this, but so far it fixes the crash for me
>
> if you guys could check this patch, that'd be great
There's already a limit_period callback, perhaps that could
be extended. But ok, can do
On Fri, Jan 25, 2019 at 12:16:27PM +0530, Ravi Bangoria wrote:
SNIP
> [ 1432.176374] general protection fault: [#1] SMP PTI
> [ 1432.182253] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW
> 5.0.0-rc3-ravi-pfuzzer+ #1
>
> [Fri Jan 25 10:28:53 2019] perf: interrupt took too long (2501 > 2500),
> lowering kernel.perf_event_max_sample_rate to 79750
> [Fri Jan 25 10:29:08 2019] perf: interrupt took too long (3136 > 3126),
> lowering kernel.perf_event_max_sample_rate to 63750
> [Fri Jan 25 10:29:11 2019] perf: interr
On Fri, 25 Jan 2019, Ravi Bangoria wrote:
> I'm seeing a system crash while running perf_fuzzer with upstream kernel
> on an Intel machine. I hit the crash twice (out of which I don't have log
> of first crash so don't know if the reason is same for both the crashes).
> I've attached my .config wi
19 matches
Mail list logo
