hi,
The assertion I am seeing on HSW now is:
[ 114.652263] WARNING: CPU: 6 PID: 3538 at
arch/x86/kernel/cpu/perf_event.c:1209 x86_pmu_start+0xaa/0x100()
[ 114.652264] Modules linked in: snd_hda_codec_hdmi i915 bnep rfcomm
bluetooth drm_kms_helper snd_hda_codec_realtek snd_hda_codec_generic
drm
On Thu, Jul 16, 2015 at 12:15 AM, Peter Zijlstra wrote:
> On Thu, Jul 16, 2015 at 08:02:03AM +0200, Stephane Eranian wrote:
>> Been running it for a couple of hours, so far so good. I will let it
>> run all night.
>
> Thanks!
>
Well, it died on NHM in the same function despite your patch. Need to
On Thu, Jul 16, 2015 at 08:02:03AM +0200, Stephane Eranian wrote:
> Been running it for a couple of hours, so far so good. I will let it
> run all night.
Thanks!
> > ---
> > arch/x86/kernel/cpu/perf_event_intel_ds.c | 29
> > +
> > 1 file changed, 13 insertions(+), 1
On Wed, Jul 15, 2015 at 2:35 PM, Peter Zijlstra wrote:
> On Wed, Jul 15, 2015 at 08:42:50AM +0200, Stephane Eranian wrote:
>> On Fri, Jul 3, 2015 at 9:49 PM, Vince Weaver
>> wrote:
>> > On Fri, 3 Jul 2015, Peter Zijlstra wrote:
>> >
>> >> That said, its far too warm and I might just not be makin
On Wed, Jul 15, 2015 at 08:42:50AM +0200, Stephane Eranian wrote:
> On Fri, Jul 3, 2015 at 9:49 PM, Vince Weaver wrote:
> > On Fri, 3 Jul 2015, Peter Zijlstra wrote:
> >
> >> That said, its far too warm and I might just not be making sense.
> >
> > you need to come visit Maine! Although I am not
On Fri, Jul 3, 2015 at 9:49 PM, Vince Weaver wrote:
> On Fri, 3 Jul 2015, Peter Zijlstra wrote:
>
>> That said, its far too warm and I might just not be making sense.
>
> you need to come visit Maine! Although I am not sure the cooler weather
> necessarily improves my kernel debugging skills.
>
>
On Mon, 6 Jul 2015, Liang, Kan wrote:
>
> > On Mon, 6 Jul 2015, Liang, Kan wrote:
> >
> > >
> > > > On Fri, Jul 03, 2015 at 08:08:27PM +, Liang, Kan wrote:
> > > > > If we cleared the last bit, we not only drain the buffer but also
> > > > > decrease the event->ctx->pmu, which is used to flu
> On Mon, 6 Jul 2015, Liang, Kan wrote:
>
> >
> > > On Fri, Jul 03, 2015 at 08:08:27PM +, Liang, Kan wrote:
> > > > If we cleared the last bit, we not only drain the buffer but also
> > > > decrease the event->ctx->pmu, which is used to flush the PEBS
> > > > buffer during context switches.
>
On Mon, 6 Jul 2015, Liang, Kan wrote:
>
> > On Fri, Jul 03, 2015 at 08:08:27PM +, Liang, Kan wrote:
> > > If we cleared the last bit, we not only drain the buffer but also
> > > decrease the event->ctx->pmu, which is used to flush the PEBS buffer
> > > during context switches.
> > > We need t
> On Fri, Jul 03, 2015 at 08:08:27PM +, Liang, Kan wrote:
> > If we cleared the last bit, we not only drain the buffer but also
> > decrease the event->ctx->pmu, which is used to flush the PEBS buffer
> > during context switches.
> > We need to disable cpuc->pebs_enabled before changing
> > ev
On Fri, Jul 03, 2015 at 08:08:27PM +, Liang, Kan wrote:
> If we cleared the last bit, we not only drain the buffer but also decrease
> the event->ctx->pmu, which is used to flush the PEBS buffer during
> context switches.
> We need to disable cpuc->pebs_enabled before changing
> event->ctx->p
>
> I've not yet tried to reproduce, but the below could explain things.
>
> On disabling an event we first clear our cpuc->pebs_enabled bits, only to
> then check them to see if there are any set, and if so, drain the buffer.
>
> If we just cleared the last bit, we'll fail to drain the buffer.
On Fri, 3 Jul 2015, Peter Zijlstra wrote:
> That said, its far too warm and I might just not be making sense.
you need to come visit Maine! Although I am not sure the cooler weather
necessarily improves my kernel debugging skills.
I managed to lock the machine (again this is with the patch app
On Fri, Jul 03, 2015 at 08:56:57PM +0200, Stephane Eranian wrote:
> Where do you see that we use cpuc->pebs_enabled after clearing it
> in pebs_disable() to check for overflow or active in drain_pebs()?
> I only see it used in get_next_pebs_record_by_bit()?
| static inline bool pebs_is_enabled(st
Peter,
On Fri, Jul 3, 2015 at 3:13 PM, Peter Zijlstra wrote:
> On Thu, Jul 02, 2015 at 11:18:10AM -0400, Vince Weaver wrote:
>>
>> So sad to say the lack of fuzzer reports was because I was out of town for
>> a bit, not due to the kernel suddenly getting amazingly better.
>>
>> In any case I am r
On Fri, 3 Jul 2015, Peter Zijlstra wrote:
> On Thu, Jul 02, 2015 at 11:18:10AM -0400, Vince Weaver wrote:
> >
> > So sad to say the lack of fuzzer reports was because I was out of town for
> > a bit, not due to the kernel suddenly getting amazingly better.
> >
> > In any case I am running again
On Thu, Jul 02, 2015 at 11:18:10AM -0400, Vince Weaver wrote:
>
> So sad to say the lack of fuzzer reports was because I was out of town for
> a bit, not due to the kernel suddenly getting amazingly better.
>
> In any case I am running against current git and getting a lot of
> warnings, but mo
On Thu, Jul 02, 2015 at 11:18:10AM -0400, Vince Weaver wrote:
> This is current linus-git on a Haswell machine with peterz's patch to fix
> the aux buffer spinlock recursion (I can still crash the kernel if that
> patch is not applied).
Argh, thanks for reminding me of that patch.
--
To unsubscr
So sad to say the lack of fuzzer reports was because I was out of town for
a bit, not due to the kernel suddenly getting amazingly better.
In any case I am running against current git and getting a lot of
warnings, but most of them seem to be old ones. This following one looks
new though.
Th
19 matches
Mail list logo
