[PATCH 1/3] HPET: Convert WARN_ON to WARN_ON_ONCE - Kernel

This is a discussion on [PATCH 1/3] HPET: Convert WARN_ON to WARN_ON_ONCE - Kernel ; It is possible to flood the console with call traces if the WARN_ON condition is true because of the frequency with which this function is called. Signed-off-by: Matt Fleming --- arch/x86/kernel/hpet.c | 2 +- 1 files changed, 1 insertions(+), 1 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: [PATCH 1/3] HPET: Convert WARN_ON to WARN_ON_ONCE

  1. [PATCH 1/3] HPET: Convert WARN_ON to WARN_ON_ONCE

    It is possible to flood the console with call traces if the WARN_ON
    condition is true because of the frequency with which this function is
    called.

    Signed-off-by: Matt Fleming
    ---
    arch/x86/kernel/hpet.c | 2 +-
    1 files changed, 1 insertions(+), 1 deletions(-)

    diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
    index 77017e8..f10f946 100644
    --- a/arch/x86/kernel/hpet.c
    +++ b/arch/x86/kernel/hpet.c
    @@ -322,7 +322,7 @@ static int hpet_next_event(unsigned long delta,
    * what we wrote hit the chip before we compare it to the
    * counter.
    */
    - WARN_ON((u32)hpet_readl(HPET_T0_CMP) != cnt);
    + WARN_ON_ONCE((u32)hpet_readl(HPET_T0_CMP) != cnt);

    return (s32)((u32)hpet_readl(HPET_COUNTER) - cnt) >= 0 ? -ETIME : 0;
    }
    --
    1.5.6.4

    --
    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. [PATCH 2/3] HPET: Enter hpet_interrupt_handler with interrupts disabled

    Some functions that may be called from this handler require that
    interrupts are disabled.

    Signed-off-by: Matt Fleming
    ---
    arch/x86/kernel/hpet.c | 3 ++-
    1 files changed, 2 insertions(+), 1 deletions(-)

    diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
    index f10f946..c28fff2 100644
    --- a/arch/x86/kernel/hpet.c
    +++ b/arch/x86/kernel/hpet.c
    @@ -445,7 +445,8 @@ static int hpet_setup_irq(struct hpet_dev *dev)
    {

    if (request_irq(dev->irq, hpet_interrupt_handler,
    - IRQF_SHARED|IRQF_NOBALANCING, dev->name, dev))
    + IRQF_DISABLED|IRQF_SHARED|IRQF_NOBALANCING,
    + dev->name, dev))
    return -1;

    disable_irq(dev->irq);
    --
    1.5.6.4

    --
    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 2/3] HPET: Enter hpet_interrupt_handler with interrupts disabled

    On Sun, Nov 2, 2008 at 4:04 PM, Matt Fleming wrote:
    > Some functions that may be called from this handler require that
    > interrupts are disabled.
    >
    > Signed-off-by: Matt Fleming
    > ---
    > arch/x86/kernel/hpet.c | 3 ++-
    > 1 files changed, 2 insertions(+), 1 deletions(-)
    >
    > diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
    > index f10f946..c28fff2 100644
    > --- a/arch/x86/kernel/hpet.c
    > +++ b/arch/x86/kernel/hpet.c
    > @@ -445,7 +445,8 @@ static int hpet_setup_irq(struct hpet_dev *dev)
    > {
    >
    > if (request_irq(dev->irq, hpet_interrupt_handler,
    > - IRQF_SHARED|IRQF_NOBALANCING, dev->name, dev))
    > + IRQF_DISABLED|IRQF_SHARED|IRQF_NOBALANCING,
    > + dev->name, dev))


    Combining IRQF_DISABLED and IRQF_SHARED does not reliably disable
    interrupts in the handler. Perhaps IRQF_SHARED should be removed at
    the same time?

    > return -1;
    >
    > disable_irq(dev->irq);
    > --
    > 1.5.6.4
    >
    > --
    > 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/
    >

    --
    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 3/3] HPET: Read from HPET_Tn_CMP() not HPET_T0_CMP

    2008/11/2 Matt Fleming :
    > In hpet_next_event() we check that the value we just wrote to
    > HPET_Tn_CMP(timer) has reached the chip. Currently, we're checking that
    > the value we wrote to HPET_Tn_CMP(timer) is in HPET_T0_CMP, which, if
    > timer is anything other than timer 0, is likely to fail.
    >


    Any comments on this set of patches?
    --
    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 3/3] HPET: Read from HPET_Tn_CMP() not HPET_T0_CMP

    Matt,

    On Sun, 9 Nov 2008, Matt Fleming wrote:

    > 2008/11/2 Matt Fleming :
    > > In hpet_next_event() we check that the value we just wrote to
    > > HPET_Tn_CMP(timer) has reached the chip. Currently, we're checking that
    > > the value we wrote to HPET_Tn_CMP(timer) is in HPET_T0_CMP, which, if
    > > timer is anything other than timer 0, is likely to fail.
    > >

    >
    > Any comments on this set of patches?


    good catch. Applied to tip timers/hpet and scheduled for linus.

    Thanks,

    tglx
    --
    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 2/3] HPET: Enter hpet_interrupt_handler with interrupts disabled

    At Sun, 2 Nov 2008 22:23:13 +0000,
    Matt Fleming wrote:
    >
    > 2008/11/2 Will Newton :
    > >
    > > Combining IRQF_DISABLED and IRQF_SHARED does not reliably disable
    > > interrupts in the handler. Perhaps IRQF_SHARED should be removed at
    > > the same time?
    > >

    >
    > I didn't know that. Under what conditions is it unreliable?


    The kernel checks IRQF_DISABLED bit of only the first handler
    even if multiple handlers are assigned to a single IRQ line.
    Thus, if another handler without IRQF_DISABLED has been already
    registered before yours, your IRQF_DISABLED is ignored.

    See kernel/irq/handle.c.


    Takashi
    --
    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