From: Jarek Poplawski <jarkao2@o2.pl>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
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>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
marcin.slusarz@gmail.com
Subject: [patch] genirq: temporary fix for level-triggered IRQ resend
Date: Wed, 8 Aug 2007 13:00:37 +0200 [thread overview]
Message-ID: <20070808110037.GB2426@ff.dom.local> (raw)
In-Reply-To: <20070731160008.GA7776@elte.hu>
Hi,
I see there is a bit of complaining on this original resend temporary
patch. But, since it seems to do a good job for some people, here is
my proposal to limit the 'range of fire' a little bit.
Marcin and Jean-Baptiste: try to test this with 2.6.23-rc2, please.
(Unless Ingo or Thomas have other plans with this problem?)
Thanks,
Jarek P.
-------->
Subject: [patch] genirq: temporary fix for level-triggered IRQ resend
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.
Marcin found that when he disables the irq line on the hardware level
(removing the delayed disable) the card is kept alive.
Thomas Gleixner prepared a testing patch which proved to fix hung ups
after limiting irqs resending to edge type only. Then Ingo Molnar's
version of this patch was applied to 2.6.23-rc2 kernel as a temporary
solution. Since, the problem is still diagnosed, but seems to affect
mainly X86_64 arch, here is a modified, but still temporary, version of
this solution, which should limit the range of warnings and changes in
interrupt handling to minimum.
Signed-off-by: Jarek Poplawski <jarkao2@o2.pl>
Cc: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Jean-Baptiste Vignaud <vignaud@xandmail.fr>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
---
diff -Nurp 2.6.23-rc2-/kernel/irq/resend.c 2.6.23-rc2/kernel/irq/resend.c
--- 2.6.23-rc2-/kernel/irq/resend.c 2007-08-08 11:48:15.000000000 +0200
+++ 2.6.23-rc2/kernel/irq/resend.c 2007-08-08 11:58:42.000000000 +0200
@@ -62,18 +62,19 @@ void check_irq_resend(struct irq_desc *d
*/
desc->chip->enable(irq);
+ if ((status & (IRQ_PENDING | IRQ_REPLAY)) == IRQ_PENDING) {
+ desc->status = (status & ~IRQ_PENDING) | IRQ_REPLAY;
+
+#ifdef CONFIG_X86_64
/*
* 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) {
- WARN_ON_ONCE(1);
- return;
- }
-
- if ((status & (IRQ_PENDING | IRQ_REPLAY)) == IRQ_PENDING) {
- desc->status = (status & ~IRQ_PENDING) | IRQ_REPLAY;
-
+ if (desc->handle_irq == handle_fasteoi_irq) {
+ WARN_ON_ONCE(1);
+ return;
+ }
+#endif
if (!desc->chip || !desc->chip->retrigger ||
!desc->chip->retrigger(irq)) {
#ifdef CONFIG_HARDIRQS_SW_RESEND
next prev parent reply other threads:[~2007-08-08 11:00 UTC|newest]
Thread overview: 69+ 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
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 [this message]
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
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=20070808110037.GB2426@ff.dom.local \
--to=jarkao2@o2.pl \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--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=tglx@linutronix.de \
--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
all inboxes | Powered by JetHome®