Frank Rowand writes:
> On 04/20/17 09:51, Tyrel Datwyler wrote:
>> On 04/19/2017 09:43 PM, Frank Rowand wrote:
...
>>> Which ends up being this code:
>>>
>>>of_platform_default_populate_init()
>>> of_platform_default_populate()
>>> of_platform_populate()
>>> [[ of_f
On 04/20/17 09:51, Tyrel Datwyler wrote:
> On 04/19/2017 09:43 PM, Frank Rowand wrote:
>
< snip >
>> The call stack could easily be post-processed, for example using addr2line.
>> Here is the call stack for when the refcount incremented to 23 from 22 (or
>> more accurately, to 22 from 21):
>>
>
On 04/19/2017 09:43 PM, Frank Rowand wrote:
>> Something else to keep in mind is that while pr_debugs could be used to
>> provide feedback on the reference counts and of_reconfig events they
>> don't in anyway tell us where they are happening in the kernel. The
>
> Yes, that is critical informa
On Wed, 19 Apr 2017 22:24:58 -0700
Tyrel Datwyler wrote:
> On 04/19/2017 07:33 PM, Steven Rostedt wrote:
> > On Wed, 19 Apr 2017 16:27:10 -0700
> > Tyrel Datwyler wrote:
> >
> >> # echo stacktrace > /sys/kernel/debug/tracing/trace_options
> >> # cat trace | grep -A6 "/pci@8002018"
>
On 04/19/17 19:37, Frank Rowand wrote:
> On 04/19/17 11:45, Tyrel Datwyler wrote:
>> On 04/18/2017 07:49 PM, Steven Rostedt wrote:
>>> On Tue, 18 Apr 2017 18:42:32 -0700
>>> Frank Rowand wrote:
>>>
And of course the other issue with using tracepoints is the extra space
required to hold t
On 04/19/2017 07:33 PM, Steven Rostedt wrote:
> On Wed, 19 Apr 2017 16:27:10 -0700
> Tyrel Datwyler wrote:
>
>> # echo stacktrace > /sys/kernel/debug/tracing/trace_options
>> # cat trace | grep -A6 "/pci@8002018"
>
> Just to let you know that there is now stacktrace event triggers, where
On 04/19/17 21:43, Frank Rowand wrote:
> On 04/19/17 16:27, Tyrel Datwyler wrote:
>> On 04/18/2017 06:31 PM, Michael Ellerman wrote:
< snip >
>>
>> To get that same info as far as I know is to add a dump_stack() after
>> each pr_debug.
>
> Here is a patch that I have used. It is not as user fri
On 04/19/17 19:33, Steven Rostedt wrote:
> On Wed, 19 Apr 2017 16:27:10 -0700
> Tyrel Datwyler wrote:
>
>> # echo stacktrace > /sys/kernel/debug/tracing/trace_options
>> # cat trace | grep -A6 "/pci@8002018"
>
> Just to let you know that there is now stacktrace event triggers, where
> yo
On 04/19/17 16:27, Tyrel Datwyler wrote:
> On 04/18/2017 06:31 PM, Michael Ellerman wrote:
>> Frank Rowand writes:
>>
>>> On 04/17/17 17:32, Tyrel Datwyler wrote:
This patch introduces event tracepoints for tracking a device_nodes
reference cycle as well as reconfig notifications generat
On 04/19/17 11:45, Tyrel Datwyler wrote:
> On 04/18/2017 07:49 PM, Steven Rostedt wrote:
>> On Tue, 18 Apr 2017 18:42:32 -0700
>> Frank Rowand wrote:
>>
>>> And of course the other issue with using tracepoints is the extra space
>>> required to hold the tracepoint info. With the pr_debug() approa
On Wed, 19 Apr 2017 16:27:10 -0700
Tyrel Datwyler wrote:
> # echo stacktrace > /sys/kernel/debug/tracing/trace_options
> # cat trace | grep -A6 "/pci@8002018"
Just to let you know that there is now stacktrace event triggers, where
you don't need to stacktrace all events, you can pick and
On 04/18/2017 06:31 PM, Michael Ellerman wrote:
> Frank Rowand writes:
>
>> On 04/17/17 17:32, Tyrel Datwyler wrote:
>>> This patch introduces event tracepoints for tracking a device_nodes
>>> reference cycle as well as reconfig notifications generated in response
>>> to node/property manipulatio
On 04/19/2017 03:13 AM, Michael Ellerman wrote:
> Oliver O'Halloran writes:
>
>> On Wed, Apr 19, 2017 at 2:46 AM, Rob Herring wrote:
>>> On Mon, Apr 17, 2017 at 7:32 PM, Tyrel Datwyler
>>> wrote:
This patch introduces event tracepoints for tracking a device_nodes
reference cycle as we
On 04/18/2017 07:49 PM, Steven Rostedt wrote:
> On Tue, 18 Apr 2017 18:42:32 -0700
> Frank Rowand wrote:
>
>> And of course the other issue with using tracepoints is the extra space
>> required to hold the tracepoint info. With the pr_debug() approach, the
>> space usage can be easily removed fo
On 04/18/2017 07:31 PM, Frank Rowand wrote:
> On 04/18/17 18:31, Michael Ellerman wrote:
>> Frank Rowand writes:
>>
>>> On 04/17/17 17:32, Tyrel Datwyler wrote:
This patch introduces event tracepoints for tracking a device_nodes
reference cycle as well as reconfig notifications generated
On 04/17/17 17:32, Tyrel Datwyler wrote:
> This patch introduces event tracepoints for tracking a device_nodes
> reference cycle as well as reconfig notifications generated in response
> to node/property manipulations.
>
> With the recent upstreaming of the refcount API several device_node
> under
Oliver O'Halloran writes:
> On Wed, Apr 19, 2017 at 2:46 AM, Rob Herring wrote:
>> On Mon, Apr 17, 2017 at 7:32 PM, Tyrel Datwyler
>> wrote:
>>> This patch introduces event tracepoints for tracking a device_nodes
>>> reference cycle as well as reconfig notifications generated in response
>>> to
On 04/18/17 19:46, Steven Rostedt wrote:
> On Tue, 18 Apr 2017 17:07:17 -0700
> Frank Rowand wrote:
>
>
>> As far as I know, there is no easy way to combine trace data and printk()
>> style data to create a single chronology of events. If some of the
>> information needed to debug an issue is t
On Tue, 18 Apr 2017 18:42:32 -0700
Frank Rowand wrote:
> And of course the other issue with using tracepoints is the extra space
> required to hold the tracepoint info. With the pr_debug() approach, the
> space usage can be easily removed for a production kernel via a config
> option.
Now if yo
On Tue, 18 Apr 2017 17:07:17 -0700
Frank Rowand wrote:
> As far as I know, there is no easy way to combine trace data and printk()
> style data to create a single chronology of events. If some of the
> information needed to debug an issue is trace data and some is printk()
> style data then it
On 04/18/17 18:31, Michael Ellerman wrote:
> Frank Rowand writes:
>
>> On 04/17/17 17:32, Tyrel Datwyler wrote:
>>> This patch introduces event tracepoints for tracking a device_nodes
>>> reference cycle as well as reconfig notifications generated in response
>>> to node/property manipulations.
>
On Wed, Apr 19, 2017 at 2:46 AM, Rob Herring wrote:
> On Mon, Apr 17, 2017 at 7:32 PM, Tyrel Datwyler
> wrote:
>> This patch introduces event tracepoints for tracking a device_nodes
>> reference cycle as well as reconfig notifications generated in response
>> to node/property manipulations.
>>
>>
On 04/18/17 17:07, Frank Rowand wrote:
> On 04/17/17 17:32, Tyrel Datwyler wrote:
>> This patch introduces event tracepoints for tracking a device_nodes
>> reference cycle as well as reconfig notifications generated in response
>> to node/property manipulations.
>>
>> With the recent upstreaming of
Frank Rowand writes:
> On 04/17/17 17:32, Tyrel Datwyler wrote:
>> This patch introduces event tracepoints for tracking a device_nodes
>> reference cycle as well as reconfig notifications generated in response
>> to node/property manipulations.
>>
>> With the recent upstreaming of the refcount A
On 04/17/17 17:32, Tyrel Datwyler wrote:
> This patch introduces event tracepoints for tracking a device_nodes
> reference cycle as well as reconfig notifications generated in response
> to node/property manipulations.
>
> With the recent upstreaming of the refcount API several device_node
> under
On Mon, Apr 17, 2017 at 7:32 PM, Tyrel Datwyler
wrote:
> This patch introduces event tracepoints for tracking a device_nodes
> reference cycle as well as reconfig notifications generated in response
> to node/property manipulations.
>
> With the recent upstreaming of the refcount API several devic
FYI, this patch was meant to be sent as an RFC. Looks like the RFC tag
got lost in my last spin.
On 04/17/2017 05:32 PM, Tyrel Datwyler wrote:
> This patch introduces event tracepoints for tracking a device_nodes
> reference cycle as well as reconfig notifications generated in response
> to node/p
This patch introduces event tracepoints for tracking a device_nodes
reference cycle as well as reconfig notifications generated in response
to node/property manipulations.
With the recent upstreaming of the refcount API several device_node
underflows and leaks have come to my attention in the pser
28 matches
Mail list logo
