13 Aug, 2007

1 commit


09 Aug, 2007

1 commit


02 Aug, 2007

1 commit

  • Marcin Slusarz reported a ne2k-pci "hung network interface" regression.

    delayed disable relies on the ability to re-trigger the interrupt in the
    case that a real interrupt happens after the software disable was set.
    In this case we actually disable the interrupt on the hardware level
    _after_ it occurred.

    On enable_irq, we need to re-trigger the interrupt. On i386 this relies
    on a hardware resend mechanism (send_IPI_self()).

    Actually we only need the resend for edge type interrupts. Level type
    interrupts come back once enable_irq() re-enables the interrupt line.

    I assume that the interrupt in question is level triggered because it is
    shared and above the legacy irqs 0-15:

    17: 12 IO-APIC-fasteoi eth1, eth0

    Looking into the IO_APIC code, the resend via send_IPI_self() happens
    unconditionally. So the resend is done for level and edge interrupts.
    This makes the problem more mysterious.

    The code in question lib8390.c does

    disable_irq();
    fiddle_with_the_network_card_hardware()
    enable_irq();

    The fiddle_with_the_network_card_hardware() might cause interrupts,
    which are cleared in the same code path again,

    Marcin found that when he disables the irq line on the hardware level
    (removing the delayed disable) the card is kept alive.

    So the difference is that we can get a resend on enable_irq, when an
    interrupt happens during the time, where we are in the disabled region.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     

07 Oct, 2006

1 commit


17 Sep, 2006

1 commit

  • Fix a bug where the IRQ_PENDING flag is never cleared and the ISR is called
    endlessly without an actual interrupt.

    Signed-off-by: Imre Deak
    Acked-by: Thomas Gleixner
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Imre Deak
     

30 Jun, 2006

2 commits