Re: [PATCH] 2.6.0-test4 Fix mpparse properly

[Andrew de Quincey <adq_dvb-fmPXVN3awWJAJAzL26g0SA@public.gmane.org>]

On Monday 08 Sep 2003 3:49 pm, Andi Kleen wrote:
> On Mon, Sep 08, 2003 at 11:02:46AM +0100, Andrew de Quincey wrote:
> > On Monday 08 Sep 2003 3:25 am, Andi Kleen wrote:
> > > On Sun, 7 Sep 2003 21:30:40 +0100
> > >
> > > Andrew de Quincey <adq_dvb-fmPXVN3awWJAJAzL26g0SA@public.gmane.org> wrote:
> > > > --- linux-2.6.0-test4.null_crs/arch/i386/kernel/mpparse.c	2003-09-06
> > > > 00:23:10.000000000 +0100 +++
> > > > linux-2.6.0-test4.es7000fix/arch/i386/kernel/mpparse.c	2003-09-07
> > > > 15:53:41.369717552 +0100 @@ -1129,8 +1129,10 @@
> > > >  			continue;
> > > >  		ioapic_pin = irq - mp_ioapic_routing[ioapic].irq_start;
> > > >
> > > > +#ifdef CONFIG_X86_ES7000
> > > >  		if (!ioapic && (irq < 16))
> > > >  			irq += 16;
> > > > +#endif
> > >
> > > That won't work for an "generic" subarch kernel that supports the
> > > ES7000 and other boxes too. You should test es7000_plat instead (that's
> > > currently a static in the es7000 code, needs to be unstatic'ed).
> >
> > Hmm, yeah, thats a good point. However, I don't think checking for
> > es7000_plat will work. The file defining it is only included if es7000 is
> > targetted as a platform directly.  Theres no code which checks for an
> > es7000 platform by looking at the hardware or anything; it just sets the
> > variable if the es7000 architecture is targetted...
> >
> > Any ideas?
>
> In the 2.4 UL kernel there was an automatic check using an MP table.
> So it's certainly possible.

Are MP tables being replaced by ACPI? I dont think my (nforce2) board has MP 
tables at all, relying entirely on ACPI for APIC/IO-APIC config.

> But I guess for 2.6 it is reasonable if it only works when apic=es7000
> is specified.

Hmm, not keen on that.. don't like it if it means it'll probably fail to start 
on the ES7000 unless that parameter is specified.

> Actually I notice now that nobody hooked up the ES7000 into
> the generic arch yet so it won't work even with that. Still it would
> be better if the variable was tested, then whoever hooks it up
> later cannot fail into the trap of forgetting it.
>
> Only trap is that es7000_plat is currently in an es7000 specific file only.
> It should be probably in an general file to avoid an #ifdef maze.

Yeah. OK, for the moment, I'll move the variable somewhere sensible and test 
it. Whoever hooks up the ES7000 can set it appropriately.. perhaps using DMI 
to test the machine type.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf