public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Jarek Poplawski <jarkao2@o2.pl>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Stable Team <stable@kernel.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Jean-Baptiste Vignaud <vignaud@xandmail.fr>,
	"marcin.slusarz" <marcin.slusarz@gmail.com>
Subject: Re: [patch 3/3] genirq: mark io_apic level interrupts to avoid resend
Date: Mon, 13 Aug 2007 14:07:15 +0200	[thread overview]
Message-ID: <1187006835.12828.112.camel@chaos> (raw)
In-Reply-To: <20070813112821.GA2863@ff.dom.local>

On Mon, 2007-08-13 at 13:28 +0200, Jarek Poplawski wrote:
> Maybe I miss something, but:
> - why it's not done in other places with handle_level_irq or

I removed the PENDING bit magic in handle_level_irq, which was put there
by a mismerge.

> handle_fasteoi_irq. Are we sure they can never get IRQ_PENDING flag
> or we take the risk?

handle_fasteoi_irq is special. It is used by ioapic and weird Powerpc
hardware. We marked the ioapic level interrupts IRQ_LEVEL, so we wont
get a resend on them (see kernel/irq/resend.c)

> - what about e.g. handle_simple_irq: do we think it needs resending
> or simply going to wait for good bug reports?

Oops. I missed that one. I'll have a look at that as well.

> - is this .status cleared enough on free_irq or during request_irq?

AFAICT, there is no danger.

> BTW, of course something like this set of patches was needed here,
> but I still think this shouldn't be done this way: the bug wasn't
> diagnosed nor tested enough, some chips are suspected, and
> nevertheless the change is done for everybody, whithout any
> possibility to set this back for people who had no problems with
> 2.6.21 and 2.6.22 (at least for some transition time). 

It is quite clear what happened:

1. The retrigger/resend mechanism was never meant to be used for level
type interrupts and it makes absolutely no sense. When a level type
interrupt is masked while active it is resent by hardware on unmask when
it is still active. The resend / retrigger mechanism is only useful for
edge type interrupts, because we would lose an interrupt when we mask it
delayed without triggering a resend on unmask.

2. I found a box similar to Marcins which gets confused when level type
interrupts are resent.

> Maybe some
> other chips get confused now, and we get some notice of this maybe
> only in 2.6.25, if we'are lucky enough to have somebody like Marcin
> around to do the next git bisection?

There is nothing to confuse anymore. The resend for level type
interrupts is not happening, which is the same behavior as we had before
the delayed disable. The edge type interrupts resend is there since we
did the big genirq changes (2.6.18) and it was tested on various boxen
(including the above one) quite extensive.

The delayed disable was added later and unfortunately introduced the
problems we've seen.

	tglx



  reply	other threads:[~2007-08-13 14:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-12 15:46 [patch 0/3] [patch 0/3] genirq: Suppress resend of level interrupts Thomas Gleixner
2007-08-12 15:46 ` [patch 1/3] genirq: cleanup mismerge artifact Thomas Gleixner
2007-08-12 15:46 ` [patch 2/3] genirq: suppress resend of level interrupts Thomas Gleixner
2007-08-12 15:46 ` [patch 3/3] genirq: mark io_apic level interrupts to avoid resend Thomas Gleixner
2007-08-13 11:28   ` Jarek Poplawski
2007-08-13 12:07     ` Thomas Gleixner [this message]
2007-08-13 13:53       ` Jarek Poplawski
2007-08-13 14:16         ` Jarek Poplawski
2007-08-13 16:30         ` Thomas Gleixner
2007-08-14  7:12           ` Jarek Poplawski
2007-08-14  8:10             ` Thomas Gleixner
2007-08-14  9:23               ` Jarek Poplawski
2007-08-13 19:07         ` Benjamin Herrenschmidt
2007-08-14  8:01           ` Jarek Poplawski
2007-08-13 18:42       ` Benjamin Herrenschmidt
2007-08-14  7:08 ` [patch 0/3] [patch 0/3] genirq: Suppress resend of level interrupts Marcin Ślusarz

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=1187006835.12828.112.camel@chaos \
    --to=tglx@linutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=jarkao2@o2.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcin.slusarz@gmail.com \
    --cc=mingo@elte.hu \
    --cc=stable@kernel.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