Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

On 29 October 2016 at 11:23, John Stultz wrote: > On Thu, Oct 27, 2016 at 12:32 AM, Baolin Wang wrote: >> On 18 October 2016 at 14:47, Baolin Wang wrote: >>> From the trace log, we can find out the 'Binder:3292_2' process

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

On 29 October 2016 at 11:23, John Stultz wrote: > On Thu, Oct 27, 2016 at 12:32 AM, Baolin Wang wrote: >> On 18 October 2016 at 14:47, Baolin Wang wrote: >>> From the trace log, we can find out the 'Binder:3292_2' process >>> set one alarm timer which resumes the system. >>> >>> Signed-off-by:

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

On Thu, Oct 27, 2016 at 12:32 AM, Baolin Wang wrote: > On 18 October 2016 at 14:47, Baolin Wang wrote: >> From the trace log, we can find out the 'Binder:3292_2' process >> set one alarm timer which resumes the system. >> >> Signed-off-by: Baolin

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

On Thu, Oct 27, 2016 at 12:32 AM, Baolin Wang wrote: > On 18 October 2016 at 14:47, Baolin Wang wrote: >> From the trace log, we can find out the 'Binder:3292_2' process >> set one alarm timer which resumes the system. >> >> Signed-off-by: Baolin Wang >> Acked-by: Steven Rostedt >> --- >>

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

Hi, On 18 October 2016 at 14:47, Baolin Wang wrote: > For system debugging, we sometimes want to know who sets one > alarm timer, the time of the timer, when the timer started and > fired and so on. Thus adding tracepoints can help us trace the > alarmtimer information. >

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

Hi, On 18 October 2016 at 14:47, Baolin Wang wrote: > For system debugging, we sometimes want to know who sets one > alarm timer, the time of the timer, when the timer started and > fired and so on. Thus adding tracepoints can help us trace the > alarmtimer information. > > For example, when we

[PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

For system debugging, we sometimes want to know who sets one alarm timer, the time of the timer, when the timer started and fired and so on. Thus adding tracepoints can help us trace the alarmtimer information. For example, when we debug the system supend/resume, if the system is always resumed

[PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

For system debugging, we sometimes want to know who sets one alarm timer, the time of the timer, when the timer started and fired and so on. Thus adding tracepoints can help us trace the alarmtimer information. For example, when we debug the system supend/resume, if the system is always resumed

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

Hi Thomas, On 8 September 2016 at 00:03, Thomas Gleixner wrote: > On Tue, 6 Sep 2016, John Stultz wrote: >> > Changes since v3: >> > - Fix the build error on S390. >> >> Since the original change is already applied to tip/timers/core, can >> you provide an incremental patch

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

Hi Thomas, On 8 September 2016 at 00:03, Thomas Gleixner wrote: > On Tue, 6 Sep 2016, John Stultz wrote: >> > Changes since v3: >> > - Fix the build error on S390. >> >> Since the original change is already applied to tip/timers/core, can >> you provide an incremental patch (a patch against

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

On Tue, 6 Sep 2016, John Stultz wrote: > > Changes since v3: > > - Fix the build error on S390. > > Since the original change is already applied to tip/timers/core, can > you provide an incremental patch (a patch against tip/timers/core) > that fixes the issue, rather then resending the entire

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

On Tue, 6 Sep 2016, John Stultz wrote: > > Changes since v3: > > - Fix the build error on S390. > > Since the original change is already applied to tip/timers/core, can > you provide an incremental patch (a patch against tip/timers/core) > that fixes the issue, rather then resending the entire

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

Hi John, On 7 September 2016 at 14:17, John Stultz wrote: > On Tue, Sep 6, 2016 at 11:06 PM, Baolin Wang wrote: >> For system debugging, we sometimes want to know who sets one >> alarm timer, the time of the timer, when the timer started and >>

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

Hi John, On 7 September 2016 at 14:17, John Stultz wrote: > On Tue, Sep 6, 2016 at 11:06 PM, Baolin Wang wrote: >> For system debugging, we sometimes want to know who sets one >> alarm timer, the time of the timer, when the timer started and >> fired and so on. Thus adding tracepoints can help

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

On Tue, Sep 6, 2016 at 11:06 PM, Baolin Wang wrote: > For system debugging, we sometimes want to know who sets one > alarm timer, the time of the timer, when the timer started and > fired and so on. Thus adding tracepoints can help us trace the > alarmtimer information. >

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

On Tue, Sep 6, 2016 at 11:06 PM, Baolin Wang wrote: > For system debugging, we sometimes want to know who sets one > alarm timer, the time of the timer, when the timer started and > fired and so on. Thus adding tracepoints can help us trace the > alarmtimer information. > > For example, when we

[PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

For system debugging, we sometimes want to know who sets one alarm timer, the time of the timer, when the timer started and fired and so on. Thus adding tracepoints can help us trace the alarmtimer information. For example, when we debug the system supend/resume, if the system is always resumed

[PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

For system debugging, we sometimes want to know who sets one alarm timer, the time of the timer, when the timer started and fired and so on. Thus adding tracepoints can help us trace the alarmtimer information. For example, when we debug the system supend/resume, if the system is always resumed