From: James Bottomley <James.Bottomley@steeleye.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andrew Morton <akpm@osdl.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: i386 very early memory detection cleanup patch breaks the build
Date: 13 Mar 2004 17:38:13 -0500 [thread overview]
Message-ID: <1079217494.2512.48.camel@mulgrave> (raw)
In-Reply-To: <40538B39.90803@zytor.com>
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
next prev parent reply other threads:[~2004-03-13 22:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-13 17:15 i386 very early memory detection cleanup patch breaks the build James Bottomley
2004-03-13 19:48 ` James Bottomley
2004-03-13 21:43 ` H. Peter Anvin
2004-03-13 22:10 ` James Bottomley
2004-03-13 22:29 ` H. Peter Anvin
2004-03-13 22:38 ` James Bottomley [this message]
2004-03-14 2:05 ` James Bottomley
2004-03-14 2:16 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1079217494.2512.48.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=akpm@osdl.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox