[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.050 / U:5.712 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site