On 12/12/14 18:10, Steve Capper wrote:
On 12 December 2014 at 22:42, David Long wrote:
On 12/10/14 11:38, Steve Capper wrote:
On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
On 12/09/14 08:33, Steve Capper wrote:
On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote
(2014/12/13 8:10), Steve Capper wrote:
> On 12 December 2014 at 22:42, David Long wrote:
>> On 12/10/14 11:38, Steve Capper wrote:
>>>
>>> On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
On 12/09/14 08:33, Steve Capper wrote:
>
> On Thu, Dec 04, 2014 at 08:53:03PM +09
On 12 December 2014 at 22:42, David Long wrote:
> On 12/10/14 11:38, Steve Capper wrote:
>>
>> On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
>>>
>>> On 12/09/14 08:33, Steve Capper wrote:
On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
>>
>>
>> [...]
>>
>>
On 12/10/14 11:38, Steve Capper wrote:
On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
On 12/09/14 08:33, Steve Capper wrote:
On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
[...]
Not sure if this is helpful, but the following also caused a crash for
me:
echo
On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
> On 12/09/14 08:33, Steve Capper wrote:
> >On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
[...]
> >
> >Not sure if this is helpful, but the following also caused a crash for
> >me:
> >
> >echo "p:trace_event_buffer_lo
On 12/09/14 08:33, Steve Capper wrote:
On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
(2014/12/04 20:29), Steve Capper wrote:
I'd like to ask you to try my fix on your machine, with my reproducing
methods. (do not use sytemtap nor perf, those can have other issues)
Thank
On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
> (2014/12/04 20:29), Steve Capper wrote:
>
> >> I'd like to ask you to try my fix on your machine, with my reproducing
> >> methods. (do not use sytemtap nor perf, those can have other issues)
> >>
> >
> > Thank you Masami,
> >
>
On 12/03/2014 08:16 PM, William Cohen wrote:
> On 12/03/2014 05:54 PM, David Long wrote:
>> On 12/03/14 09:54, William Cohen wrote:
>>> On 12/01/2014 04:37 AM, Masami Hiramatsu wrote:
(2014/11/29 1:01), Steve Capper wrote:
> On 27 November 2014 at 06:07, Masami Hiramatsu
> wrote:
(2014/12/04 20:29), Steve Capper wrote:
>> I'd like to ask you to try my fix on your machine, with my reproducing
>> methods. (do not use sytemtap nor perf, those can have other issues)
>>
>
> Thank you Masami,
>
> I tried the following commands:
>
> echo "p:trace_event_buffer_lock_reserve
> tr
On 4 December 2014 at 10:43, Masami Hiramatsu
wrote:
> (2014/12/04 19:21), Steve Capper wrote:
>> On 4 December 2014 at 02:48, David Long wrote:
>>> On 12/03/14 20:16, William Cohen wrote:
>>>
>>> [...]
>>>
The perf issue seems to be independent and can be reproduced without using
(2014/12/04 19:21), Steve Capper wrote:
> On 4 December 2014 at 02:48, David Long wrote:
>> On 12/03/14 20:16, William Cohen wrote:
>>
>> [...]
>>
>>>
>>> The perf issue seems to be independent and can be reproduced without using
>>> any kprobe support. I need to get a simple reproducer and menti
On 4 December 2014 at 02:48, David Long wrote:
> On 12/03/14 20:16, William Cohen wrote:
>
> [...]
>
>>
>> The perf issue seems to be independent and can be reproduced without using
>> any kprobe support. I need to get a simple reproducer and mention it on the
>> linux-perf-user list.
>>
>> -Will
On 12/03/14 20:16, William Cohen wrote:
[...]
The perf issue seems to be independent and can be reproduced without using any
kprobe support. I need to get a simple reproducer and mention it on the
linux-perf-user list.
-Will
OK, my confusion came from all the different things perf can
On 12/03/2014 05:54 PM, David Long wrote:
> On 12/03/14 09:54, William Cohen wrote:
>> On 12/01/2014 04:37 AM, Masami Hiramatsu wrote:
>>> (2014/11/29 1:01), Steve Capper wrote:
On 27 November 2014 at 06:07, Masami Hiramatsu
wrote:
> (2014/11/27 3:59), Steve Capper wrote:
>> The
On 12/03/14 17:54, David Long wrote:
On 12/03/14 09:54, William Cohen wrote:
On 12/01/2014 04:37 AM, Masami Hiramatsu wrote:
(2014/11/29 1:01), Steve Capper wrote:
[...]
That would explain why the state of play of the interrupts is in an
unexpected state in the crash I reported:
"The point
On 12/03/14 09:54, William Cohen wrote:
On 12/01/2014 04:37 AM, Masami Hiramatsu wrote:
(2014/11/29 1:01), Steve Capper wrote:
On 27 November 2014 at 06:07, Masami Hiramatsu
wrote:
(2014/11/27 3:59), Steve Capper wrote:
The crash is extremely easy to reproduce.
I've not observed any missed
On 12/01/2014 04:37 AM, Masami Hiramatsu wrote:
> (2014/11/29 1:01), Steve Capper wrote:
>> On 27 November 2014 at 06:07, Masami Hiramatsu
>> wrote:
>>> (2014/11/27 3:59), Steve Capper wrote:
The crash is extremely easy to reproduce.
I've not observed any missed events on a kprobe o
(2014/12/03 4:27), William Cohen wrote:
> On 12/01/2014 04:37 AM, Masami Hiramatsu wrote:
>> (2014/11/29 1:01), Steve Capper wrote:
>>> On 27 November 2014 at 06:07, Masami Hiramatsu
>>> wrote:
(2014/11/27 3:59), Steve Capper wrote:
> The crash is extremely easy to reproduce.
>
>
On 12/02/2014 02:27 PM, William Cohen wrote:
> Hi Masami and Dave,
>
> I have applied the suggested patch above to my local kernel. However, I have
> noticed systemtap testsuite consistently getting panics when running both
> before AND after applying that patch to the kernel. Any thoughts on
On 12/01/2014 04:37 AM, Masami Hiramatsu wrote:
> (2014/11/29 1:01), Steve Capper wrote:
>> On 27 November 2014 at 06:07, Masami Hiramatsu
>> wrote:
>>> (2014/11/27 3:59), Steve Capper wrote:
The crash is extremely easy to reproduce.
I've not observed any missed events on a kprobe o
(2014/11/29 1:01), Steve Capper wrote:
> On 27 November 2014 at 06:07, Masami Hiramatsu
> wrote:
>> (2014/11/27 3:59), Steve Capper wrote:
>>> The crash is extremely easy to reproduce.
>>>
>>> I've not observed any missed events on a kprobe on an arm64 system
>>> that's still alive.
>>> My (limite
On 27 November 2014 at 06:07, Masami Hiramatsu
wrote:
> (2014/11/27 3:59), Steve Capper wrote:
>> The crash is extremely easy to reproduce.
>>
>> I've not observed any missed events on a kprobe on an arm64 system
>> that's still alive.
>> My (limited!) understanding is that this suggests there cou
(2014/11/27 3:59), Steve Capper wrote:
> The crash is extremely easy to reproduce.
>
> I've not observed any missed events on a kprobe on an arm64 system
> that's still alive.
> My (limited!) understanding is that this suggests there could be a
> problem with how missed events from a recursive cal
(2014/11/26 19:03), Steve Capper wrote:
> On Wed, Nov 26, 2014 at 05:33:05PM +0900, Masami Hiramatsu wrote:
>> (2014/11/21 0:02), Steve Capper wrote:
>>> On Tue, Nov 18, 2014 at 01:32:50AM -0500, David Long wrote:
From: "David A. Long"
This patchset is heavily based on Sandeepa Prab
On 26 November 2014 at 17:46, David Long wrote:
> On 11/26/14 05:03, Steve Capper wrote:
>>
>> On Wed, Nov 26, 2014 at 05:33:05PM +0900, Masami Hiramatsu wrote:
>>>
>>> (2014/11/21 0:02), Steve Capper wrote:
On Tue, Nov 18, 2014 at 01:32:50AM -0500, David Long wrote:
>
> From: "D
On 11/26/14 05:03, Steve Capper wrote:
On Wed, Nov 26, 2014 at 05:33:05PM +0900, Masami Hiramatsu wrote:
(2014/11/21 0:02), Steve Capper wrote:
On Tue, Nov 18, 2014 at 01:32:50AM -0500, David Long wrote:
From: "David A. Long"
This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes
On Wed, Nov 26, 2014 at 05:33:05PM +0900, Masami Hiramatsu wrote:
> (2014/11/21 0:02), Steve Capper wrote:
> > On Tue, Nov 18, 2014 at 01:32:50AM -0500, David Long wrote:
> >> From: "David A. Long"
> >>
> >> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes
> >> patches, first
>
(2014/11/21 0:02), Steve Capper wrote:
> On Tue, Nov 18, 2014 at 01:32:50AM -0500, David Long wrote:
>> From: "David A. Long"
>>
>> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
>> first
>> seen in October 2013. This version attempts to address concerns raised by
>>
On Tue, Nov 18, 2014 at 01:32:50AM -0500, David Long wrote:
> From: "David A. Long"
>
> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
> first
> seen in October 2013. This version attempts to address concerns raised by
> reviewers and also fixes problems discovered
From: "David A. Long"
This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
first
seen in October 2013. This version attempts to address concerns raised by
reviewers and also fixes problems discovered during testing, particularly during
SMP testing.
This patchset adds sup
30 matches
Mail list logo
