linux-next: Tree for October 23 - Kernel

This is a discussion on linux-next: Tree for October 23 - Kernel ; On Thursday, October 23, 2008 6:14 pm Randy Dunlap wrote: > I made this patch for linux-next, but now mainline has this same > code/warning. > > > From: Randy Dunlap Thanks Randy, I've queued it up. Jesse -- To ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 51 of 51

Thread: linux-next: Tree for October 23

  1. Re: [PATCH] PCI hotplug printk format

    On Thursday, October 23, 2008 6:14 pm Randy Dunlap wrote:
    > I made this patch for linux-next, but now mainline has this same
    > code/warning.
    >
    >
    > From: Randy Dunlap


    Thanks Randy, I've queued it up.

    Jesse
    --
    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] PCI hotplug printk format

    On Thursday, October 23, 2008 6:14 pm Randy Dunlap wrote:
    > 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


    Spoke too soon, this one was already merged.

    Jesse
    --
    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] ftrace: handle archs that do not support irqs_disabled_flags

    On Fri, 24 Oct 2008, Steven Rostedt wrote:
    > 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.


    Both alpha

    #define irqs_disabled() (getipl() == IPL_MAX)

    and m68k

    static inline int irqs_disabled(void)
    {
    unsigned long flags;
    local_save_flags(flags);
    return flags & ~ALLOWINT;
    }

    do have irqs_disabled(), but they don't have irqs_disabled_flags().

    M68knommu has both, but they don't check the same thing:

    #define irqs_disabled() \
    ({ \
    unsigned long flags; \
    local_save_flags(flags); \
    ((flags & 0x0700) == 0x0700); \
    })

    static inline int irqs_disabled_flags(unsigned long flags)
    {
    if (flags & 0x0700)
    return 0;
    else
    return 1;
    }

    Is there a semantic difference between them (except that the latter takes the
    flags as a parameter)?

    Or can we just extract the core logic of irqs_disabled() into
    irqs_disabled_flags()?

    Gr{oetje,eeting}s,

    Geert

    --
    Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

    In personal conversations with technical people, I call myself a hacker. But
    when I'm talking to journalists I just say "programmer" or something like that.
    -- Linus Torvalds
    --
    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: [ofa-general] Re: linux-next: Tree for October 23

    Randy Dunlap wrote:
    > 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!
    > ...
    > Is this supposed to be allowed/possible? Otherwise NET_9P_RDMA might have to depend on INFINBAND=y...

    No, there's no need to config INFINIBAND at built it. What's the value
    of CONFIG_INFINIBAND_ADDR_TRANS ?

    Or.


    --
    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] ftrace: handle archs that do not support irqs_disabled_flags

    Hi Geert,

    Geert Uytterhoeven wrote:
    > On Fri, 24 Oct 2008, Steven Rostedt wrote:
    >> 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.

    >
    > Both alpha
    >
    > #define irqs_disabled() (getipl() == IPL_MAX)
    >
    > and m68k
    >
    > static inline int irqs_disabled(void)
    > {
    > unsigned long flags;
    > local_save_flags(flags);
    > return flags & ~ALLOWINT;
    > }
    >
    > do have irqs_disabled(), but they don't have irqs_disabled_flags().
    >
    > M68knommu has both, but they don't check the same thing:
    >
    > #define irqs_disabled() \
    > ({ \
    > unsigned long flags; \
    > local_save_flags(flags); \
    > ((flags & 0x0700) == 0x0700); \
    > })
    >
    > static inline int irqs_disabled_flags(unsigned long flags)
    > {
    > if (flags & 0x0700)
    > return 0;
    > else
    > return 1;
    > }
    >
    > Is there a semantic difference between them (except that the latter takes the
    > flags as a parameter)?


    No...


    > Or can we just extract the core logic of irqs_disabled() into
    > irqs_disabled_flags()?


    Yep, could certainly do that. I'll put a patch together.

    Regards
    Greg



    ------------------------------------------------------------------------
    Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
    Secure Computing Corporation PHONE: +61 7 3435 2888
    825 Stanley St, FAX: +61 7 3891 3630
    Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
    --
    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

    On Thu, Oct 23, 2008 at 08:34:33PM +0400, 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'


    FYI, this error still exists in mainline (7f82f000ed030d1108b4de47d9e2d556092980c6).
    --
    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

    2008/10/30 Alexey Dobriyan :
    > On Thu, Oct 23, 2008 at 08:34:33PM +0400, 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'

    >
    > FYI, this error still exists in mainline (7f82f000ed030d1108b4de47d9e2d556092980c6).
    >


    Thanks.

    Yes Steven sent a patch to correct it: http://lkml.org/lkml/2008/10/24/205
    But it has not been applied yet (still 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/

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


    * Frédéric Weisbecker wrote:

    > 2008/10/30 Alexey Dobriyan :
    > > On Thu, Oct 23, 2008 at 08:34:33PM +0400, 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'

    > >
    > > FYI, this error still exists in mainline (7f82f000ed030d1108b4de47d9e2d556092980c6).
    > >

    >
    > Thanks.
    >
    > Yes Steven sent a patch to correct it: http://lkml.org/lkml/2008/10/24/205
    > But it has not been applied yet (still in discussion?).


    i've just applied it to tip/tracing/urgent - should get to Linus
    tomorrow-ish.

    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/

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

    On Fri, 31 Oct 2008, Alexey Dobriyan wrote:
    > On Thu, Oct 23, 2008 at 08:34:33PM +0400, 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'

    >
    > FYI, this error still exists in mainline (7f82f000ed030d1108b4de47d9e2d556092980c6).


    Now it hit mainline (I can't be bothered to develop _new_ code to fix things in
    -next ;-), I'm implementing irqs_disabled_flags() for m68k. Stay tuned...

    Gr{oetje,eeting}s,

    Geert

    --
    Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

    In personal conversations with technical people, I call myself a hacker. But
    when I'm talking to journalists I just say "programmer" or something like that.
    -- Linus Torvalds
    --
    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


    * Geert Uytterhoeven wrote:

    > On Fri, 31 Oct 2008, Alexey Dobriyan wrote:
    > > On Thu, Oct 23, 2008 at 08:34:33PM +0400, 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'

    > >
    > > FYI, this error still exists in mainline (7f82f000ed030d1108b4de47d9e2d556092980c6).

    >
    > Now it hit mainline (I can't be bothered to develop _new_ code to
    > fix things in -next ;-), I'm implementing irqs_disabled_flags() for
    > m68k. Stay tuned...


    this (now mainline) commit should have fixed it:

    9244489: ftrace: handle archs that do not support irqs_disabled_flags

    can you still see problems?

    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/

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

    On Fri, 31 Oct 2008, Ingo Molnar wrote:
    > * Geert Uytterhoeven wrote:
    > > On Fri, 31 Oct 2008, Alexey Dobriyan wrote:
    > > > On Thu, Oct 23, 2008 at 08:34:33PM +0400, 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'
    > > >
    > > > FYI, this error still exists in mainline (7f82f000ed030d1108b4de47d9e2d556092980c6).

    > >
    > > Now it hit mainline (I can't be bothered to develop _new_ code to
    > > fix things in -next ;-), I'm implementing irqs_disabled_flags() for
    > > m68k. Stay tuned...

    >
    > this (now mainline) commit should have fixed it:
    >
    > 9244489: ftrace: handle archs that do not support irqs_disabled_flags
    >
    > can you still see problems?


    Yes, the "undefined reference to `save_stack_trace'", as already pointed out
    by Al. I'm trying his fix now...

    Gr{oetje,eeting}s,

    Geert

    --
    Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

    In personal conversations with technical people, I call myself a hacker. But
    when I'm talking to journalists I just say "programmer" or something like that.
    -- Linus Torvalds
    --
    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 3 of 3 FirstFirst 1 2 3