Message-ID: <4B80C699.1030302@zytor.com>
Date:	Sat, 20 Feb 2010 21:37:29 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
CC:	Suresh Siddha <suresh.b.siddha@...el.com>,
	"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
	"yinghai@...nel.org" <yinghai@...nel.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [patch 2/2] x86, irq: use 0x20 for the IRQ_MOVE_CLEANUP_VECTOR
 instead of 0x1f

On 02/20/2010 09:20 PM, Maciej W. Rozycki wrote:
> 
>  Correct, the problem only affected B1, B3 and B5 steppings of the P54C 
> Pentium processor.  These are probably extremely rare these days.  It was 
> fixed later on.
> 
>  But they can be run-time detected -- if we don't support them anymore 
> (assuming keeping them supported is too much of maintenance hassle; Linux 
> used to be proud to support hardware nobody else seemed to care of 
> anymore, so it's really disappointing to see it go), we should panic() on 
> bootstrap and print an appropriate message.  They are CPUID family 5, 
> model 2 and steppings 1, 2 and 4, respectively.
> 
>  Also the note in arch/x86/kernel/smp.c should be adjusted accordingly 
> stating that the erratum is no longer worked around (preferably stating 
> the last Linux version it was).
> 

My philosophy is generally that I'm happy to keep old hardware (that
actually exist in any kind of meaningful quantity) alive, but I'm not
willing to go through herculean efforts nor willing to make widely
available modern hardware suck over it.

It looks like this really isn't too hard to deal with, though.

>  I'm not sure how fatal for Linux the implications are though; even then 
> it looks to me the approach we took was an overkill.  It's enough to 
> guarantee that the APIC error interrupt, the APIC timer interrupt and 
> self-IPIs (do we use any at all though?) do not share their priority 
> level(s) with any external interrupt (but they can share the level with 
> one another).  We only use ever LINT0/1 interrupts as NMIs (for the NMI 
> watchdog and the system error, respectively), or ExtINT (in the case of 
> LINT0), so this erratum does not apply to them.

The APIC error is on vector 0xfe, the APIC timer is on vector 0xef, and
self IPI (vector 0xeb) we only use for MCA, which wouldn't be supported
on these processors.

However, these are mixed with externally-generated IPIs which will be
seen as serial interrupts: in particular 0xf0-0xfd are all different IPI
which share with the error vector 0xde, and 0xeb shares with 0xed is
used for "platform" IPIs.

It sounds like the right solution for supporting these processors would
be to reshuffle the special vectors so that we use one level (presumably
0xfx) for locally generated interrupts and one (presumably 0xex) for
external IPIs, and make sure that it is not possible for external
interrupts to get assigned to the local-only level.  The assignment of
external interrupts, which seems to be where focus has been in the past,
is actually irrelevant (but might still be good for performance, by
maximizing the number of interrupts that can be held in the LAPIC and
not bounced.)

Either way, this doesn't exactly sound too bad.  A bigger question is if
we want to do this globally or end up having different vector
assignments for these oddball CPUs.  Testing it, too, will be almost
impossible...

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
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