Date:	Wed, 4 Jun 2008 16:52:39 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Stefan Assmann <sassmann@...e.de>
cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Olaf Dabrunz <od@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Jon Masters <jonathan@...masters.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] Boot IRQ quirks and rerouting

On Wed, 4 Jun 2008, Stefan Assmann wrote:

> You're right, that behavior is more appropriate for RT, where we see
> these boot interrupts because of the way interrupts are handled there.
> We're rewriting the patches to use a parameter like pci=ioapicreroute to
> trigger this only if the parameter is specified (for the mainstream
> kernel).

 Well, this is clear these chipsets are broken beyond imagination,
negating some 15 years of I/O APIC compatibility where masking an input in
its redirection table is expected not to have any side effects.  They
should have used a separate bit for the legacy INTx redirection.  That has
been fixed in hardware though and there is nothing we can do about it at
this stage.  Hire competent hardware designers the next time.

 However I do not feel adding a command line parameter for each of such
workarounds is the right way to do it.  We end up with an infinite number
of obscure options nobody or hardly anybody really understands.  We should
be removing them rather than adding new ones.

 What's the reasoning behind the option in this case?  As I understand 
there are two cases possible:

1. Secondary, etc. I/O APIC inputs are not masked under any circumstances.  
   No legacy INTx redirection happens, nothing to be done.

2. Secondary, etc. I/O APIC inputs are to be masked from time to time.  
   That would cause legacy INTx redirection for the affected chipsets in 
   situations where an interrupt arrives at a masked I/O APIC input.  This 
   interrupt is delivered to an input of the primary I/O APIC which cannot 
   be masked because of other devices wired to it.

   OK -- that means the interrupt is delivered anyway (and perhaps 
   discarded in the handler, but that does not matter here), so why to do
   the rerouting in the first place?  Because we could equally well keep 
   the original secondary, etc. I/O APIC input for the interrupt unmasked 
   (if an affected chipset is discovered) to the very same effect, yet 
   avoid all the hassle and unnecessary sharing.  It could be handled very 
   easily by selecting a different "interrupt controller" setup for the
   affected I/O APICs.

Either way I fail to see a reason not to this automatically -- I cannot
imagine a sane user to be able to decide whether to use the option or not
in this case.

 That's one.  Second -- I have had a look at the relevant chipset
documentation and I fail to see how INTx messages received over PCI
Express are actually converted to interrupt signals.  I gather they are
interpreted by the MCH and posted to the ICH "somehow".  What does that
"somehow" look like?  Does the MCH assert PIRQ lines of the ICH? -- but I
fail to see any available outputs in the MCH that could be used for this
purpose.  SERIRQ is obviously not used, because it is not implemented in
the MCH and PCI messages I am assuming are not used either as they are
edge-triggered and therefore preclude sharing and as such could be simply
masked out in the primary I/O APIC permanently.

 Knowing this could help understanding the problem better.

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists