linux-next: Tree for October 23 - Kernel

This is a discussion on linux-next: Tree for October 23 - Kernel ; When tracing is enabled, some arch have included on their but others like alpha or m68k don't. Build error on alpha: kernel/trace/trace.c: In function 'tracing_generic_entry_update': kernel/trace/trace.c:658: error: implicit declaration of function 'irqs_disabled_flags' kernel/trace/trace.c: In function 'tracing_cpumask_write': kernel/trace/trace.c:2145: error: implicit declaration ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 51

Thread: linux-next: Tree for October 23

  1. [PATCH] tracing: fix a build error on alpha and m68k

    When tracing is enabled, some arch have included
    on their but others like alpha or m68k don't.

    Build error on alpha:

    kernel/trace/trace.c: In function 'tracing_generic_entry_update':
    kernel/trace/trace.c:658: error: implicit declaration of function 'irqs_disabled_flags'
    kernel/trace/trace.c: In function 'tracing_cpumask_write':
    kernel/trace/trace.c:2145: error: implicit declaration of function 'raw_local_irq_disable'
    kernel/trace/trace.c:2162: error: implicit declaration of function 'raw_local_irq_enable'
    kernel/trace/trace.c: In function 'trace_die_handler':
    kernel/trace/trace.c:3039: error: 'DIE_OOPS' undeclared (first use in this function)

    Build error on m68k:
    http://kisskb.ellerman.id.au/kisskb/buildresult/50641/


    Include it on kernel/trace/trace.c

    Reported-by: Alexey Dobriyan
    Signed-off-by: Frederic Weisbecker
    ---
    diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
    index 78d5661..deb9684 100644
    --- a/kernel/trace/trace.c
    +++ b/kernel/trace/trace.c
    @@ -34,6 +34,7 @@

    #include
    #include
    +#include

    #include "trace.h"

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH] tracing: fix a build error on alpha and m68k

    On Thu, Oct 23, 2008 at 07:27:48PM +0200, Frederic Weisbecker wrote:
    > When tracing is enabled, some arch have included
    > on their but others like alpha or m68k don't.
    >
    > Build error on alpha:
    >
    > kernel/trace/trace.c: In function 'tracing_generic_entry_update':
    > kernel/trace/trace.c:658: error: implicit declaration of function 'irqs_disabled_flags'
    > kernel/trace/trace.c: In function 'tracing_cpumask_write':
    > kernel/trace/trace.c:2145: error: implicit declaration of function 'raw_local_irq_disable'
    > kernel/trace/trace.c:2162: error: implicit declaration of function 'raw_local_irq_enable'
    > kernel/trace/trace.c: In function 'trace_die_handler':
    > kernel/trace/trace.c:3039: error: 'DIE_OOPS' undeclared (first use in this function)
    >
    > Build error on m68k:
    > http://kisskb.ellerman.id.au/kisskb/buildresult/50641/
    >
    >
    > Include it on kernel/trace/trace.c
    >
    > Reported-by: Alexey Dobriyan
    > Signed-off-by: Frederic Weisbecker
    > ---
    > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
    > index 78d5661..deb9684 100644
    > --- a/kernel/trace/trace.c
    > +++ b/kernel/trace/trace.c
    > @@ -34,6 +34,7 @@
    >
    > #include
    > #include
    > +#include


    Sure, except it doesn't fix anything.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH] tracing: fix a build error on alpha and m68k


    * Frederic Weisbecker wrote:

    > When tracing is enabled, some arch have included
    > on their but others like alpha or m68k don't.
    >
    > Build error on alpha:
    >
    > kernel/trace/trace.c: In function 'tracing_generic_entry_update':
    > kernel/trace/trace.c:658: error: implicit declaration of function 'irqs_disabled_flags'
    > kernel/trace/trace.c: In function 'tracing_cpumask_write':
    > kernel/trace/trace.c:2145: error: implicit declaration of function 'raw_local_irq_disable'
    > kernel/trace/trace.c:2162: error: implicit declaration of function 'raw_local_irq_enable'
    > kernel/trace/trace.c: In function 'trace_die_handler':
    > kernel/trace/trace.c:3039: error: 'DIE_OOPS' undeclared (first use in this function)
    >
    > Build error on m68k:
    > http://kisskb.ellerman.id.au/kisskb/buildresult/50641/
    >
    >
    > Include it on kernel/trace/trace.c
    >
    > Reported-by: Alexey Dobriyan
    > Signed-off-by: Frederic Weisbecker
    > ---
    > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
    > index 78d5661..deb9684 100644
    > --- a/kernel/trace/trace.c
    > +++ b/kernel/trace/trace.c
    > @@ -34,6 +34,7 @@
    >
    > #include
    > #include
    > +#include
    >
    > #include "trace.h"


    applied to tip/tracing/urgent, thanks!

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH] tracing: fix a build error on alpha and m68k


    * Alexey Dobriyan wrote:

    > On Thu, Oct 23, 2008 at 07:27:48PM +0200, Frederic Weisbecker wrote:
    > > When tracing is enabled, some arch have included
    > > on their but others like alpha or m68k don't.
    > >
    > > Build error on alpha:
    > >
    > > kernel/trace/trace.c: In function 'tracing_generic_entry_update':
    > > kernel/trace/trace.c:658: error: implicit declaration of function 'irqs_disabled_flags'
    > > kernel/trace/trace.c: In function 'tracing_cpumask_write':
    > > kernel/trace/trace.c:2145: error: implicit declaration of function 'raw_local_irq_disable'
    > > kernel/trace/trace.c:2162: error: implicit declaration of function 'raw_local_irq_enable'
    > > kernel/trace/trace.c: In function 'trace_die_handler':
    > > kernel/trace/trace.c:3039: error: 'DIE_OOPS' undeclared (first use in this function)
    > >
    > > Build error on m68k:
    > > http://kisskb.ellerman.id.au/kisskb/buildresult/50641/
    > >
    > >
    > > Include it on kernel/trace/trace.c
    > >
    > > Reported-by: Alexey Dobriyan
    > > Signed-off-by: Frederic Weisbecker
    > > ---
    > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
    > > index 78d5661..deb9684 100644
    > > --- a/kernel/trace/trace.c
    > > +++ b/kernel/trace/trace.c
    > > @@ -34,6 +34,7 @@
    > >
    > > #include
    > > #include
    > > +#include

    >
    > Sure, except it doesn't fix anything.


    hm, zapped the commit then.

    the problem is most likely that none of these architectures is lockdep
    enabled, hence they have no irqtrace wrappers, hence not all of the
    tracers can be built on them?

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH] tracing: fix a build error on alpha and m68k


    * Frédéric Weisbecker wrote:

    > But they should be able to use the tracing for several other tracers.
    > One other problem is that you need CONFIG_TRACE_IRQFLAGS (is that a
    > lockdep or just trace feature?) to use any tracer since the
    > tracing_cpumask file is always created for all tracer. This file has
    > tracing_cpumask_write() as a write operation, and this func uses
    > raw_local_funcs....
    >
    > Perhaps we should disable the tracing_cpu_mask related things if
    > TRACE_IRQFLAGS in not configured?


    to answer the "is that a lockdep or just trace feature" question:

    trace-irqflags was first written by me for the (crude) ftrace-precursor
    latency tracer code in -rt, years ago. Then i reused it (and changed it
    alot) for upstream lockdep, two years ago. Then ftrace came in this year
    and reused it.

    so it's rather symbiotic ;-)

    So ... the tracers that rely on irqflags-tracing should definitely be
    limited to architectures that provide TRACE_IRQFLAGS. The core trace.c
    itself should probably not be restricted ... (and it should definitely
    build)

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH] tracing: fix a build error on alpha and m68k

    2008/10/23 Ingo Molnar :
    > to answer the "is that a lockdep or just trace feature" question:
    >
    > trace-irqflags was first written by me for the (crude) ftrace-precursor
    > latency tracer code in -rt, years ago. Then i reused it (and changed it
    > alot) for upstream lockdep, two years ago. Then ftrace came in this year
    > and reused it.
    >
    > so it's rather symbiotic ;-)
    >
    > So ... the tracers that rely on irqflags-tracing should definitely be
    > limited to architectures that provide TRACE_IRQFLAGS. The core trace.c
    > itself should probably not be restricted ... (and it should definitely
    > build)
    >
    > Ingo
    >


    Ok, so perhaps it needs a kind of disambiguation between CONFIG_TRACE_IRQFLAGS
    and CONFIG_TRACE_IRQFLAGS_SUPPORT

    So, if those arch may not support irqflags, I should forget about
    including linux/irqflags.h

    But to let the core trace.c to be built for other types of tracing,
    the best thing I see is to put some ifdef CONFIG_TRACE_IRQFLAGS on the
    tracing_cpumask functions and structure, and actually on the creation
    of this file.

    No bad feelings about this solution?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH] tracing: fix a build error on alpha and m68k


    On Thu, 23 Oct 2008, Alexey Dobriyan wrote:
    > >
    > > kernel/trace/trace.c: In function 'tracing_generic_entry_update':
    > > kernel/trace/trace.c:658: error: implicit declaration of function 'irqs_disabled_flags'


    This error concerns me more. We depend on this in the generic tracers.
    Should we just add a stub function here when TRACE_IRQFLAGS is not
    supported?

    -- Steve


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [PATCH] tracing: fix a build error on alpha and m68k


    On Thu, 23 Oct 2008, Fr?d?ric Weisbecker wrote:
    >
    > But to let the core trace.c to be built for other types of tracing,
    > the best thing I see is to put some ifdef CONFIG_TRACE_IRQFLAGS on the
    > tracing_cpumask functions and structure, and actually on the creation
    > of this file.


    Is there a reason that you use "raw_local_irq_disable" instead of
    local_irq_disable?

    -- Steve

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH] tracing: fix a build error on alpha and m68k

    2008/10/23 Steven Rostedt :
    >
    > On Thu, 23 Oct 2008, Fr?d?ric Weisbecker wrote:
    >>
    >> But to let the core trace.c to be built for other types of tracing,
    >> the best thing I see is to put some ifdef CONFIG_TRACE_IRQFLAGS on the
    >> tracing_cpumask functions and structure, and actually on the creation
    >> of this file.

    >
    > Is there a reason that you use "raw_local_irq_disable" instead of
    > local_irq_disable?



    I'm not using anything
    This is about the tracing_cpumask debugfs file implemented in trace.c
    It's tracing_cpumask_write function uses the raw_local functions, I
    guess because its locking doesn't need to be traced.
    And the problem here is that some archs don't implement raw_local
    functions and so trace.c doesn't compile with alpha or m68k.
    But actually this file is not needed for them.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH] tracing: fix a build error on alpha and m68k

    2008/10/23 Ingo Molnar :
    > hm, zapped the commit then.
    >
    > the problem is most likely that none of these architectures is lockdep
    > enabled, hence they have no irqtrace wrappers, hence not all of the
    > tracers can be built on them?
    >
    > Ingo
    >


    But they should be able to use the tracing for several other tracers.
    One other problem is that you need CONFIG_TRACE_IRQFLAGS (is that a
    lockdep or just trace feature?) to use any tracer since the
    tracing_cpumask file is always created for all tracer. This file has
    tracing_cpumask_write() as a write operation, and this func uses
    raw_local_funcs....

    Perhaps we should disable the tracing_cpu_mask related things if
    TRACE_IRQFLAGS in not configured?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH] tracing: fix a build error on alpha and m68k

    2008/10/23 Alexey Dobriyan :
    > On Thu, Oct 23, 2008 at 07:27:48PM +0200, Frederic Weisbecker wrote:
    >> When tracing is enabled, some arch have included
    >> on their but others like alpha or m68k don't.
    >>
    >> Build error on alpha:
    >>
    >> kernel/trace/trace.c: In function 'tracing_generic_entry_update':
    >> kernel/trace/trace.c:658: error: implicit declaration of function 'irqs_disabled_flags'
    >> kernel/trace/trace.c: In function 'tracing_cpumask_write':
    >> kernel/trace/trace.c:2145: error: implicit declaration of function 'raw_local_irq_disable'
    >> kernel/trace/trace.c:2162: error: implicit declaration of function 'raw_local_irq_enable'
    >> kernel/trace/trace.c: In function 'trace_die_handler':
    >> kernel/trace/trace.c:3039: error: 'DIE_OOPS' undeclared (first use in this function)
    >>
    >> Build error on m68k:
    >> http://kisskb.ellerman.id.au/kisskb/buildresult/50641/
    >>
    >>
    >> Include it on kernel/trace/trace.c
    >>
    >> Reported-by: Alexey Dobriyan
    >> Signed-off-by: Frederic Weisbecker
    >> ---
    >> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
    >> index 78d5661..deb9684 100644
    >> --- a/kernel/trace/trace.c
    >> +++ b/kernel/trace/trace.c
    >> @@ -34,6 +34,7 @@
    >>
    >> #include
    >> #include
    >> +#include

    >
    > Sure, except it doesn't fix anything.
    >


    Really? You mean only m68k or even on alpha?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [PATCH] tracing: fix a build error on alpha and m68k

    2008/10/23 Frederic Weisbecker :
    > When tracing is enabled, some arch have included
    > on their but others like alpha or m68k don't.
    >
    > Build error on alpha:
    >
    > kernel/trace/trace.c: In function 'tracing_generic_entry_update':
    > kernel/trace/trace.c:658: error: implicit declaration of function 'irqs_disabled_flags'
    > kernel/trace/trace.c: In function 'tracing_cpumask_write':
    > kernel/trace/trace.c:2145: error: implicit declaration of function 'raw_local_irq_disable'
    > kernel/trace/trace.c:2162: error: implicit declaration of function 'raw_local_irq_enable'
    > kernel/trace/trace.c: In function 'trace_die_handler':
    > kernel/trace/trace.c:3039: error: 'DIE_OOPS' undeclared (first use in this function)
    >
    > Build error on m68k:
    > http://kisskb.ellerman.id.au/kisskb/buildresult/50641/
    >
    >
    > Include it on kernel/trace/trace.c
    >
    > Reported-by: Alexey Dobriyan
    > Signed-off-by: Frederic Weisbecker
    > ---
    > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
    > index 78d5661..deb9684 100644
    > --- a/kernel/trace/trace.c
    > +++ b/kernel/trace/trace.c
    > @@ -34,6 +34,7 @@
    >
    > #include
    > #include
    > +#include
    >
    > #include "trace.h"
    >
    >


    And one other "reported by" for the m68k error:

    Reported-by: Geert Uytterhoeven
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: linux-next: Tree for October 23

    On Thu, 23 Oct 2008 21:36:37 +1100 Stephen Rothwell wrote:

    > Hi all,


    Building with CONFIG_INFINIBAND=m, kconfig allows CONFIG_NET_9P_RDMA=m,
    so one module wants symbols from the other (net/9p wants symbols from rmda_*).

    ERROR: "rdma_destroy_id" [net/9p/9pnet_rdma.ko] undefined!
    ERROR: "rdma_connect" [net/9p/9pnet_rdma.ko] undefined!
    ERROR: "rdma_create_id" [net/9p/9pnet_rdma.ko] undefined!
    ERROR: "rdma_create_qp" [net/9p/9pnet_rdma.ko] undefined!
    ERROR: "rdma_resolve_route" [net/9p/9pnet_rdma.ko] undefined!
    ERROR: "rdma_disconnect" [net/9p/9pnet_rdma.ko] undefined!
    ERROR: "rdma_resolve_addr" [net/9p/9pnet_rdma.ko] undefined!

    Is this supposed to be allowed/possible? Otherwise NET_9P_RDMA might
    have to depend on INFINBAND=y...

    ---
    ~Randy
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. [PATCH] coda: credentials error

    From: Randy Dunlap

    Needs a header file for credentials struct:

    linux-next-20081023/fs/coda/file.c:177: error: dereferencing pointer to incomplete type

    Signed-off-by: Randy Dunlap
    ---
    fs/coda/file.c | 1 +
    1 file changed, 1 insertion(+)

    --- linux-next-20081023.orig/fs/coda/file.c
    +++ linux-next-20081023/fs/coda/file.c
    @@ -13,6 +13,7 @@
    #include
    #include
    #include
    +#include
    #include
    #include
    #include
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. [PATCH] PCI hotplug printk format

    I made this patch for linux-next, but now mainline has this same code/warning.


    From: Randy Dunlap

    Fix printk format warning:

    linux-next-20081023/drivers/pci/hotplug/acpiphp_ibm.c:207: warning: format '%08lx' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int'

    Signed-off-by: Randy Dunlap
    ---
    drivers/pci/hotplug/acpiphp_ibm.c | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

    --- linux-next-20081023.orig/drivers/pci/hotplug/acpiphp_ibm.c
    +++ linux-next-20081023/drivers/pci/hotplug/acpiphp_ibm.c
    @@ -204,7 +204,7 @@ static int ibm_set_attention_status(stru
    err("APLS evaluation failed: 0x%08x\n", stat);
    return -ENODEV;
    } else if (!rc) {
    - err("APLS method failed: 0x%08lx\n", rc);
    + err("APLS method failed: 0x%08llx\n", rc);
    return -ERANGE;
    }
    return 0;
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. [PATCH] nfsctl: credentials error

    From: Randy Dunlap

    Needs headers help for current_cred:

    Adding only cred.h wasn't enough.

    linux-next-20081023/fs/nfsctl.c:45: error: implicit declaration of function 'current_cred'

    Signed-off-by: Randy Dunlap
    ---
    fs/nfsctl.c | 2 ++
    1 file changed, 2 insertions(+)

    --- linux-next-20081023.orig/fs/nfsctl.c
    +++ linux-next-20081023/fs/nfsctl.c
    @@ -10,6 +10,8 @@
    #include
    #include
    #include
    +#include
    +#include
    #include
    #include
    #include
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: linux-next: drivers/lguest/page_tables.c:1044: error: invalid initializer

    On Friday 24 October 2008 01:48:14 Alexey Dobriyan wrote:
    > On i386-smp-y-debug-y-preempt-n-paravirt-y-mem-01:
    >
    > drivers/lguest/page_tables.c: In function 'setup_pagetables':
    > drivers/lguest/page_tables.c:1044: error: invalid initializer


    This is the lguest PAE patches, which I've pushed back for the moment (even
    after this fix, it crashed my host and I haven't had time to figure out why).

    Thanks,
    Rusty.


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [PATCH] tracing: fix a build error on alpha and m68k

    Ingo Molnar wrote:
    > * Alexey Dobriyan wrote:
    >
    >> On Thu, Oct 23, 2008 at 07:27:48PM +0200, Frederic Weisbecker wrote:
    >>> When tracing is enabled, some arch have included
    >>> on their but others like alpha or m68k don't.
    >>>
    >>> Build error on alpha:
    >>>
    >>> kernel/trace/trace.c: In function 'tracing_generic_entry_update':
    >>> kernel/trace/trace.c:658: error: implicit declaration of function 'irqs_disabled_flags'
    >>> kernel/trace/trace.c: In function 'tracing_cpumask_write':
    >>> kernel/trace/trace.c:2145: error: implicit declaration of function 'raw_local_irq_disable'
    >>> kernel/trace/trace.c:2162: error: implicit declaration of function 'raw_local_irq_enable'
    >>> kernel/trace/trace.c: In function 'trace_die_handler':
    >>> kernel/trace/trace.c:3039: error: 'DIE_OOPS' undeclared (first use in this function)
    >>>
    >>> Build error on m68k:
    >>> http://kisskb.ellerman.id.au/kisskb/buildresult/50641/
    >>>
    >>>
    >>> Include it on kernel/trace/trace.c
    >>>
    >>> Reported-by: Alexey Dobriyan
    >>> Signed-off-by: Frederic Weisbecker
    >>> ---
    >>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
    >>> index 78d5661..deb9684 100644
    >>> --- a/kernel/trace/trace.c
    >>> +++ b/kernel/trace/trace.c
    >>> @@ -34,6 +34,7 @@
    >>>
    >>> #include
    >>> #include
    >>> +#include

    >> Sure, except it doesn't fix anything.

    >
    > hm, zapped the commit then.
    >
    > the problem is most likely that none of these architectures is lockdep
    > enabled, hence they have no irqtrace wrappers, hence not all of the
    > tracers can be built on them?
    >
    > Ingo
    >


    I just testes my patch by building with a cross compiler on Alpha.
    Before the patch:

    kernel/trace/trace.c: In function 'tracing_generic_entry_update':
    kernel/trace/trace.c:664: error: implicit declaration of function 'irqs_disabled_flags'
    kernel/trace/trace.c: In function 'tracing_cpumask_write':
    kernel/trace/trace.c:2150: error: implicit declaration of function 'raw_local_irq_disable'
    kernel/trace/trace.c:2167: error: implicit declaration of function 'raw_local_irq_enable'
    kernel/trace/trace.c: In function 'trace_die_handler':
    kernel/trace/trace.c:3044: error: 'DIE_OOPS' undeclared (first use in this function)
    kernel/trace/trace.c:3044: error: (Each undeclared identifier is reported only once
    kernel/trace/trace.c:3044: error: for each function it appears in.)

    After the patch:

    kernel/trace/trace.c: In function 'tracing_generic_entry_update':
    kernel/trace/trace.c:664: error: implicit declaration of function 'irqs_disabled_flags'
    kernel/trace/trace.c: In function 'trace_die_handler':
    kernel/trace/trace.c:3044: error: 'DIE_OOPS' undeclared (first use in this function)
    kernel/trace/trace.c:3044: error: (Each undeclared identifier is reported only once
    kernel/trace/trace.c:3044: error: for each function it appears in.)

    So the raw_local_irq_* functions are defined in linux/irqflags.h, even for arch that doesn't have CONFIG_TRACE_IRQFLAGS_SUPPORT. They just do a local_irq_save/restore.
    That's what we wanted. And we have to include it on trace.c for archs like alpha.

    So this patch fixes it.

    The DIE_OOPS should be fixed by a recent patch from Steven (ftrace: move nmi die handler to arch specific).

    The last issue is irqs_disabled_flags. But it's one other problem which is in discussion.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. [PATCH] ftrace: handle archs that do not support irqs_disabled_flags


    Some architectures do not support a way to read the irq flags that
    is set from "local_irq_save(flags)" to determine if interrupts were
    disabled or enabled. Ftrace uses this information to display to the user
    if the trace occurred with interrupts enabled or disabled.

    Besides the fact that those archs that do not support this will fail to
    compile, unless they fix it, we do not want to have the trace simply
    say interrupts were not disabled or they were enabled, without knowing
    the real answer.

    This patch adds a 'X' in the output to let the user know that the
    architecture they are running on does not support a way for the tracer
    to determine if interrupts were enabled or disabled. It also lets those
    same archs compile with tracing enabled.

    Signed-off-by: Steven Rostedt
    ---
    Documentation/ftrace.txt | 3 +++
    kernel/trace/trace.c | 7 ++++++-
    kernel/trace/trace.h | 20 +++++++++++---------
    3 files changed, 20 insertions(+), 10 deletions(-)

    Index: linux-tip.git/Documentation/ftrace.txt
    ================================================== =================
    --- linux-tip.git.orig/Documentation/ftrace.txt 2008-10-23 19:23:26.000000000 -0400
    +++ linux-tip.git/Documentation/ftrace.txt 2008-10-24 09:32:42.000000000 -0400
    @@ -291,6 +291,9 @@ explains which is which.
    CPU#: The CPU which the process was running on.

    irqs-off: 'd' interrupts are disabled. '.' otherwise.
    + Note: If the architecture does not support a way to
    + read the irq flags variable, an 'X' will always
    + be printed here.

    need-resched: 'N' task need_resched is set, '.' otherwise.

    Index: linux-tip.git/kernel/trace/trace.c
    ================================================== =================
    --- linux-tip.git.orig/kernel/trace/trace.c 2008-10-23 19:24:15.000000000 -0400
    +++ linux-tip.git/kernel/trace/trace.c 2008-10-24 09:31:17.000000000 -0400
    @@ -677,7 +677,11 @@ tracing_generic_entry_update(struct trac
    entry->preempt_count = pc & 0xff;
    entry->pid = (tsk) ? tsk->pid : 0;
    entry->flags =
    +#ifdef CONFIG_TRACE_IRQFLAGS_SUPPORT
    (irqs_disabled_flags(flags) ? TRACE_FLAG_IRQS_OFF : 0) |
    +#else
    + TRACE_FLAG_IRQS_NOSUPPORT |
    +#endif
    ((pc & HARDIRQ_MASK) ? TRACE_FLAG_HARDIRQ : 0) |
    ((pc & SOFTIRQ_MASK) ? TRACE_FLAG_SOFTIRQ : 0) |
    (need_resched() ? TRACE_FLAG_NEED_RESCHED : 0);
    @@ -1265,7 +1269,8 @@ lat_print_generic(struct trace_seq *s, s
    trace_seq_printf(s, "%8.8s-%-5d ", comm, entry->pid);
    trace_seq_printf(s, "%3d", cpu);
    trace_seq_printf(s, "%c%c",
    - (entry->flags & TRACE_FLAG_IRQS_OFF) ? 'd' : '.',
    + (entry->flags & TRACE_FLAG_IRQS_OFF) ? 'd' :
    + (entry->flags & TRACE_FLAG_IRQS_NOSUPPORT) ? 'X' : '.',
    ((entry->flags & TRACE_FLAG_NEED_RESCHED) ? 'N' : '.'));

    hardirq = entry->flags & TRACE_FLAG_HARDIRQ;
    Index: linux-tip.git/kernel/trace/trace.h
    ================================================== =================
    --- linux-tip.git.orig/kernel/trace/trace.h 2008-10-23 12:55:37.000000000 -0400
    +++ linux-tip.git/kernel/trace/trace.h 2008-10-24 09:27:10.000000000 -0400
    @@ -120,18 +120,20 @@ struct trace_boot {
    /*
    * trace_flag_type is an enumeration that holds different
    * states when a trace occurs. These are:
    - * IRQS_OFF - interrupts were disabled
    - * NEED_RESCED - reschedule is requested
    - * HARDIRQ - inside an interrupt handler
    - * SOFTIRQ - inside a softirq handler
    - * CONT - multiple entries hold the trace item
    + * IRQS_OFF - interrupts were disabled
    + * IRQS_NOSUPPORT - arch does not support irqs_disabled_flags
    + * NEED_RESCED - reschedule is requested
    + * HARDIRQ - inside an interrupt handler
    + * SOFTIRQ - inside a softirq handler
    + * CONT - multiple entries hold the trace item
    */
    enum trace_flag_type {
    TRACE_FLAG_IRQS_OFF = 0x01,
    - TRACE_FLAG_NEED_RESCHED = 0x02,
    - TRACE_FLAG_HARDIRQ = 0x04,
    - TRACE_FLAG_SOFTIRQ = 0x08,
    - TRACE_FLAG_CONT = 0x10,
    + TRACE_FLAG_IRQS_NOSUPPORT = 0x02,
    + TRACE_FLAG_NEED_RESCHED = 0x04,
    + TRACE_FLAG_HARDIRQ = 0x08,
    + TRACE_FLAG_SOFTIRQ = 0x10,
    + TRACE_FLAG_CONT = 0x20,
    };

    #define TRACE_BUF_SIZE 1024


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: [PATCH] ftrace: handle archs that do not support irqs_disabled_flags

    2008/10/24 Steven Rostedt :
    > This patch adds a 'X' in the output to let the user know that the
    > architecture they are running on does not support a way for the tracer
    > to determine if interrupts were enabled or disabled. It also lets those
    > same archs compile with tracing enabled.


    That's almost exactly what I thought to repair the warning caused by those
    FLAG_IRQS_NOSUPPORT archs

    So we have now all the three patches that correct the warning reported
    by Alexey in
    Linux-next: http://lkml.org/lkml/2008/10/23/145
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast