[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4897021D.7040708@sgi.com>
Date: Mon, 04 Aug 2008 06:20:29 -0700
From: Mike Travis <travis@....com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: Yinghai Lu <yhlu.kernel@...il.com>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Alan Mayer <ajm@....com>
Subject: Re: [PATCH] x86: 64bit support more than 256 irq v2
Eric W. Biederman wrote:
> "Yinghai Lu" <yhlu.kernel@...il.com> writes:
>
>> On Fri, Aug 1, 2008 at 7:02 PM, Yinghai Lu <yhlu.kernel@...il.com> wrote:
>>> Dhaval Giani got:
>>> kernel BUG at arch/x86/kernel/io_apic_64.c:357!
>>> invalid opcode: 0000 [1] SMP
>>> CPU 24
>>> ...
>>>
>>> his system (x3950) has 8 ioapic, irq > 256
>>>
>>> caused by
>>> commit 9b7dc567d03d74a1fbae84e88949b6a60d922d82
>>> Author: Thomas Gleixner <tglx@...utronix.de>
>>> Date: Fri May 2 20:10:09 2008 +0200
>>>
>>> x86: unify interrupt vector defines
>>>
>>> The interrupt vector defines are copied 4 times around with minimal
>>> differences. Move them all into asm-x86/irq_vectors.h
>>>
>>> because 64bit allow same vector for different cpu to serve different irq
>>>
>>> need to create that array dynamically later
>>>
>>> v2: change NR_IRQS to 1024
>>>
>>> Signed-off-by: Yinghai Lu <yhlu.kernel@...il.com>
>>> Tested-by: Dhaval Giani <dhaval@...ux.vnet.ibm.com>
>> this is for
>> http://bugzilla.kernel.org/show_bug.cgi?id=11201
>>
>> but need SGI guys to verify in their system. they like to have NR_IRQS to be 224
>
> There was a patch that came out a while ago that set NR_IRQS as NR_IOAPICS*32 from
> SGI. Where that got to I don't recall.
>
> Eric
That was from Alan ... I'll Cc: him. Here's an early copy (not sure if
this was the final one though.)
>From: Alan Mayer <ajm@....com>
Subject: [PATCH] x86_64: resize NR_IRQS for large machines
On machines with very large numbers of cpus, tables that are dimensioned
by NR_IRQS get very large, especially the irq_desc table. They are also
very sparsely used. When the cpu count is > MAX_IO_APICS, use MAX_IO_APICS
to set NR_IRQS, otherwise use NR_CPUS.
Reviewed-by: Christoph Lameter <clameter@....com>
Signed-off-by: Alan Mayer <ajm@....com>
Index: v2.6.25-rc6/include/asm-x86/irq_64.h
===================================================================
--- v2.6.25-rc6.orig/include/asm-x86/irq_64.h 2008-03-19 16:52:52.000000000 -0500
+++ v2.6.25-rc6/include/asm-x86/irq_64.h 2008-03-20 16:46:51.000000000 -0500
@@ -10,6 +10,10 @@
* <tomsoft@...ormatik.tu-chemnitz.de>
*/
+#if !defined(MAX_IO_APICS)
+#include <asm/apicdef.h>
+#endif
+
#define TIMER_IRQ 0
/*
@@ -31,7 +35,11 @@
#define FIRST_SYSTEM_VECTOR 0xef /* duplicated in hw_irq.h */
-#define NR_IRQS (NR_VECTORS + (32 *NR_CPUS))
+#if NR_CPUS < MAX_IO_APICS
+#define NR_IRQS (NR_VECTORS + (32 * NR_CPUS))
+#else
+#define NR_IRQS (NR_VECTORS + (32 * MAX_IO_APICS))
+#endif
#define NR_IRQ_VECTORS NR_IRQS
static __inline__ int irq_canonicalize(int irq)
Index: v2.6.25-rc6/include/linux/kernel_stat.h
===================================================================
--- v2.6.25-rc6.orig/include/linux/kernel_stat.h 2008-03-19 16:53:00.000000000 -0500
+++ v2.6.25-rc6/include/linux/kernel_stat.h 2008-03-20 11:12:27.000000000 -0500
@@ -1,11 +1,11 @@
#ifndef _LINUX_KERNEL_STAT_H
#define _LINUX_KERNEL_STAT_H
-#include <asm/irq.h>
#include <linux/smp.h>
#include <linux/threads.h>
#include <linux/percpu.h>
#include <linux/cpumask.h>
+#include <asm/irq.h>
#include <asm/cputime.h>
/*
--
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