Re: i386 very early memory detection cleanup patch breaks the build

[James Bottomley]

On Sat, 2004-03-13 at 17:29, H. Peter Anvin wrote:
> Actually, I just meant changing:
> 
> -obj-$(CONFIG_X86_SMP)		+= smp.o smpboot.o trampoline.o
> +obj-$(CONFIG_X86_SMP)		+= smp.o smpboot.o
> +obj-$(CONFIG_SMP)		+= trampoline.o
> 
> ... which is more like what the original code is doing, minus VISWS.

No, that looks more magical and even worse.  The idea of the subarch
code is to separate out pieces of i386/kernel that need to be added in
separately.  Having trampoline depend on CONFIG_X86_TRAMPOLINE which
then depends on (X86_SMP) || (VOYAGER && SMP) expresses exactly what's
going on.  The above code is begging for someone to try to "correct" it.

> Nope.  It shouldn't be using the boot page tables after paging_init, and 
> even so, the "new" boot page tables look just like the "old" ones except 
> there might be more of them, so there are two resaons that shouldn't be 
> happening.  I'd have been less surprised if you'd seen a problem with 
> boot_ioremap(), although even that shouldn't really be different...
> 
> My main guess would be a porting problem (_end -> init_pg_tables_end) in 
> discontig.c, which I believe Voyager uses, right?

Actually, no, it's not a discontig mem subarch.  It has a different SMP
setup (VICs instead of APICs...and the failing beast is the QIC which
uses cache line interference to transmit cross processor interrupts
using the last page of physical memory).

> I don't have access to any real subarchitectures (I have a visws now, 
> but I haven't actually been able to run it yet), so the discontig stuff 
> didn't get tested; on the other hand the change in there was quite trivial.
> 
> Sorry for not being able to be more helpful, but I'm surrounded by boxes 
> and this is the last weekend I have to pack before I move houses...

That's OK.  Subarch boot sequences are one of the most fragile things in
the kernel.  I suspect the ioremap problem is probably a manifestation
of something happening earlier ... I'll see if I can find it.

James


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