On Sun, Aug 14, 2005 at 07:57:53PM -0700, James Cleverdon wrote: > On Thursday 04 August 2005 02:22 am, Andi Kleen wrote: > > On Thu, Aug 04, 2005 at 12:05:50AM -0700, James Cleverdon wrote: > > > diff -pruN 2.6.12.3/arch/i386/kernel/acpi/boot.c > > > n12.3/arch/i386/kernel/acpi/boot.c --- > > > 2.6.12.3/arch/i386/kernel/acpi/boot.c 2005-07-15 14:18:57.000000000 > > > -0700 +++ n12.3/arch/i386/kernel/acpi/boot.c 2005-08-04 > > > 00:01:10.199710211 -0700 @@ -42,6 +42,7 @@ > > > static inline void acpi_madt_oem_check(char *oem_id, char > > > *oem_table_id) { } extern void __init clustered_apic_check(void); > > > static inline int ioapic_setup_disabled(void) { return 0; } > > > +extern int gsi_irq_sharing(int gsi); > > > #include <asm/proto.h> > > > > > > #else /* X86 */ > > > @@ -51,6 +52,9 @@ static inline int ioapic_setup_disabled( > > > #include <mach_mpparse.h> > > > #endif /* CONFIG_X86_LOCAL_APIC */ > > > > > > +static inline int gsi_irq_sharing(int gsi) { return gsi; } > > > > Why is this different for i386/x86-64? It shouldn't. > > True. Have added code for i386. Unfortunately, I didn't see one file > that is shared by both architectures and which is included when > building with I/O APIC support. So, I duplicated the function into > io_apic.c
That needs to be cleaned up before merge. This code is already ugly and I don't want the cruft accumulating here. > > As a unrelated note we really need to get rid of this whole ifdef > > block. > > > > > +++ n12.3/arch/x86_64/Kconfig 2005-08-03 21:31:07.487451167 -0700 > > > @@ -280,13 +280,13 @@ config HAVE_DEC_LOCK > > > default y > > > > > > config NR_CPUS > > > - int "Maximum number of CPUs (2-256)" > > > - range 2 256 > > > + int "Maximum number of CPUs (2-255)" > > > + range 2 255 > > > depends on SMP > > > - default "8" > > > + default "16" > > > > Don't change the default please. > > > > > +static int next_irq = 16; > > > > Won't this need a lock for hotplug later? > > That's what I thought originally, but maybe not. We initialize all RTEs > and assign IRQs+vectors fairly early in boot, plus store the results in > arrays. Thereafter the functions just return the preallocated values. I was thinking of IO-APIC hotplug here. IIRC the ia64 folks have it already and I'm sure someone will turn up with a patch for i386/x86-64 soon. For devices it should be ok, you're right. Ok I guess they can change it in that patch then. Perhaps just add a comment. > > > have a different trigger mode + * than PCI. > > > + */ > > > > Can we perhaps force such sharing early temporarily even when the > > table is not filled up? This way we would get better test coverage > > of all of this. > > > > That would be later disabled of course. > > Suppose I added a static counter and pretended that every third > non-legacy IRQ needed to be shared? Can you drop into the sharing path unconditionally? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/