From: Thomas Gleixner <tglx@linutronix.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Marcin ??lusarz <marcin.slusarz@gmail.com>,
Jarek Poplawski <jarkao2@o2.pl>,
Jean-Baptiste Vignaud <vignaud@xandmail.fr>,
linux-kernel <linux-kernel@vger.kernel.org>,
shemminger <shemminger@linux-foundation.org>,
linux-net <linux-net@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: 2.6.20->2.6.21 - networking dies after random time
Date: Wed, 25 Jul 2007 02:19:31 +0200 [thread overview]
Message-ID: <1185322771.4175.102.camel@chaos> (raw)
In-Reply-To: <20070724200431.GA22190@elte.hu>
On Tue, 2007-07-24 at 22:04 +0200, Ingo Molnar wrote:
> Marcin, could you try the patch below too? [without having any other
> patch applied.] It basically turns the critical section into an irqs-off
> critical section and thus checks whether your problem is related to that
> particular area of code.
>
I read back on this thread and I think the problem is somewhere else:
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.
No idea how this affects the network card, as the code there must be
able to handle interrupts, which are not originated from the card due to
interrupt sharing.
Marcin, can you please try the patch below ? It's just a debugging aid
to gather some more data about that problem.
If the patch fixes the problem, then we should try to disable the resend
mechanism for not edge type irq lines on the irq_chip level (i.e. the
IOAPIC code)
Thanks,
tglx
--- linux-2.6.orig/kernel/irq/resend.c
+++ linux-2.6/kernel/irq/resend.c
@@ -62,6 +62,15 @@ void check_irq_resend(struct irq_desc *desc, unsigned int irq)
*/
desc->chip->enable(irq);
+ /*
+ * Temporary hack to figure out more about the problem, which
+ * is causing the ancient network cards to die.
+ */
+ if (desc->handle_irq != handle_edge_irq) {
+ printk(KERN_DEBUG "Skip resend for irq %u\n", irq);
+ return;
+ }
+
if ((status & (IRQ_PENDING | IRQ_REPLAY)) == IRQ_PENDING) {
desc->status = (status & ~IRQ_PENDING) | IRQ_REPLAY;
next prev parent reply other threads:[~2007-07-25 0:19 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-29 8:50 2.6.20->2.6.21 - networking dies after random time Jean-Baptiste Vignaud
2007-06-29 15:07 ` Jarek Poplawski
2007-07-23 5:44 ` Marcin Ślusarz
2007-07-23 8:53 ` Jarek Poplawski
2007-07-24 7:18 ` Jarek Poplawski
2007-07-24 8:05 ` Ingo Molnar
2007-07-24 9:42 ` Ingo Molnar
2007-07-24 19:30 ` Linus Torvalds
2007-07-24 20:04 ` Ingo Molnar
2007-07-25 0:19 ` Thomas Gleixner [this message]
2007-07-25 7:23 ` Jarek Poplawski
2007-07-25 13:57 ` Jarek Poplawski
2007-07-25 14:46 ` Alan Cox
2007-07-26 12:44 ` [PATCH][netdrvr] lib8390: comment on locking by Alan Cox " Jarek Poplawski
2007-07-26 12:47 ` Alan Cox
2007-07-30 19:47 ` Jeff Garzik
2007-07-30 8:46 ` Ingo Molnar
2007-07-30 13:05 ` Alan Cox
2007-07-26 7:16 ` Marcin Ślusarz
2007-07-26 8:13 ` Jarek Poplawski
2007-07-26 8:10 ` Thomas Gleixner
2007-07-26 8:31 ` Ingo Molnar
2007-07-26 8:55 ` Jarek Poplawski
2007-07-26 9:12 ` Ingo Molnar
2007-07-30 7:29 ` Marcin Ślusarz
2007-07-30 8:49 ` Ingo Molnar
2007-08-01 7:24 ` Marcin Ślusarz
2007-08-01 7:27 ` Ingo Molnar
2007-08-06 6:58 ` Marcin Ślusarz
2007-07-31 13:20 ` Jarek Poplawski
2007-08-06 7:00 ` Marcin Ślusarz
2007-08-06 7:03 ` Ingo Molnar
2007-08-06 17:43 ` Chuck Ebbert
2007-08-06 19:08 ` Ingo Molnar
2007-08-09 14:50 ` [RFC] " Jarek Poplawski
[not found] ` <p738x8kg0dp.fsf@bingen.suse.de>
2007-08-09 15:30 ` Jarek Poplawski
2007-08-07 10:09 ` Jarek Poplawski
2007-08-07 7:46 ` Marcin Ślusarz
2007-08-07 8:23 ` Jarek Poplawski
[not found] ` <4bacf17f0708070237w19d184b3p7f74b53612edb9a6@mail.gmail.com>
2007-08-07 9:52 ` Jarek Poplawski
2007-08-07 12:13 ` Jarek Poplawski
2007-08-07 12:55 ` Jarek Poplawski
2007-08-08 11:11 ` Marcin Ślusarz
2007-08-08 11:09 ` Marcin Ślusarz
2007-08-08 11:42 ` Jarek Poplawski
2007-08-08 11:53 ` Jarek Poplawski
2007-08-09 9:19 ` [patch (testing)] " Jarek Poplawski
[not found] ` <4bacf17f0708092333n17e0ba19jf2c769531610868d@mail.gmail.com>
2007-08-10 7:10 ` Jarek Poplawski
2007-08-10 10:43 ` Marcin Ślusarz
2007-08-10 11:37 ` Jarek Poplawski
2007-07-31 15:58 ` [patch] genirq: temporary fix for level-triggered IRQ resend Ingo Molnar
2007-07-31 16:00 ` Ingo Molnar
2007-08-08 11:00 ` Jarek Poplawski
2007-08-02 17:03 ` Gabriel C
2007-08-02 20:11 ` Ingo Molnar
2007-08-03 6:07 ` [patch] genirq: fix simple and fasteoi irq handlers Jarek Poplawski
2007-08-03 8:04 ` Ingo Molnar
2007-08-03 8:46 ` Ingo Molnar
2007-08-03 9:10 ` Jarek Poplawski
2007-08-03 11:57 ` Marcin Ślusarz
2007-08-03 12:26 ` Jarek Poplawski
2007-08-06 7:05 ` Marcin Ślusarz
2007-08-06 6:07 ` [patch (take 2)] " Jarek Poplawski
2007-08-06 6:14 ` Ingo Molnar
2007-08-06 7:07 ` Marcin Ślusarz
2007-08-06 7:19 ` Jarek Poplawski
2007-07-26 9:11 ` 2.6.20->2.6.21 - networking dies after random time Jarek Poplawski
2007-07-26 8:19 ` Jarek Poplawski
2007-07-26 8:16 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2007-08-08 8:59 Jean-Baptiste Vignaud
2007-08-08 9:30 ` Jarek Poplawski
2007-08-08 12:16 ` Jarek Poplawski
2007-08-07 17:16 Jean-Baptiste Vignaud
2007-08-08 7:21 ` Jarek Poplawski
2007-08-08 7:36 ` Jarek Poplawski
2007-08-07 9:21 Jean-Baptiste Vignaud
2007-08-07 9:44 ` Jarek Poplawski
2007-08-07 8:10 Jean-Baptiste Vignaud
2007-08-07 9:05 ` Jarek Poplawski
2007-08-06 20:42 Jean-Baptiste Vignaud
2007-08-06 21:19 ` Chuck Ebbert
2007-08-07 7:26 ` Jarek Poplawski
2007-08-06 21:30 ` Al Boldi
2007-08-06 19:36 Jean-Baptiste Vignaud
2007-06-26 14:24 Jean-Baptiste Vignaud
2007-06-27 10:17 ` Jarek Poplawski
[not found] <4bacf17f0706161435g1bb7c08bpd427901f64d57fa@mail.gmail.com>
2007-06-18 11:08 ` Jarek Poplawski
2007-06-18 15:10 ` Stephen Hemminger
2007-06-19 5:27 ` Jarek Poplawski
2007-06-19 5:50 ` Jarek Poplawski
2007-06-22 8:56 ` Marcin Ślusarz
2007-06-22 13:32 ` Jarek Poplawski
[not found] ` <4bacf17f0706252310w155fc4d7v1bf12319a650559a@mail.gmail.com>
2007-06-26 8:08 ` Jarek Poplawski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1185322771.4175.102.camel@chaos \
--to=tglx@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=jarkao2@o2.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
--cc=marcin.slusarz@gmail.com \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.org \
--cc=torvalds@linux-foundation.org \
--cc=vignaud@xandmail.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).