[lkml]   [2008]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[BUG] unsolicited IRQ disabling at the IO-APIC leading to eth0 freezes
    WAS: net: tx timeouts with skge, 8139too, dmfe drivers/NICs

    Hi all,

    I am observing rare freezes(blocking) of eth0 with:

    NETDEV WATCHDOG: eth0: transmit timed out

    in dmesg output.

    The problem has been already described in a previous message:

    with some additional observations, as described in:

    Recently I found that the IRQ# used by the driver/NIC has been
    somehow disabled/masked at the IO-APIC, blocking the interrupts to
    the driver irq_handler, so the messages: NETDEV WATCHDOG....



    in the dev->tx_timeout() method restores the working state of eth0,
    (at least for skge), so the interface now works posting (sometimes)

    NETDEV WATCHDOG: eth0: transmit timed out

    messages in the log.

    If I EXPORT_SYMBOL(irq_desc) (from kernel/irq/handle.c)
    I am able to restore the working state of the eth0 interface with

    (irq_desc + irq#)->chip->enable(irq#)


    (irq_desc + irq#)->chip->unmask(irq#)

    (properly locked), instead of disable/enable_irq(irq#),

    Just for info the driver irq_handler always return IRQ_HANDLED and never
    (verified) IRQ_NONE, so the irq# is not disabled due to unhandled irqs -
    yes the driver declares IRQF_SHARED, but is the only one on this irq#
    (as viewed in /proc/interrupts).

    The system is runing kernel- (AMD64 X2) on Asus A7V Deluxe

    Am I observing IRQ locking/rice condition OUT of net driver?

    All suggestions for further investigation are wellcome.

    Marin Mitov

     \ /
      Last update: 2008-03-25 16:17    [W:0.021 / U:0.180 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site