From: "H. Peter Anvin" <hpa@zytor.com>
To: James Bottomley <James.Bottomley@SteelEye.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: Sat, 13 Mar 2004 14:29:13 -0800 [thread overview]
Message-ID: <40538B39.90803@zytor.com> (raw)
In-Reply-To: <1079215809.2513.39.camel@mulgrave>
James Bottomley wrote:
>
>>I removed it because I removed the VISWS dependency, thus making it
>>redundant. What you seem to be saying is that the dependency should
>>have been on SMP not X86_SMP; if that's the issue then please make it so.
>>
>>I think you just needed to apply your own rule to the above statement.
>
> If you mean the dependency should be
>
> depends X86_SMP || (VOYAGER && SMP)
>
> Then yes, I'm happy with that.
>
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.
> I'm still debugging the boot time failure. As far as I can tell it
> looks like ioremap is failing (this is after paging_init); does this
> trigger any associations?
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?
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...
-hpa
next prev parent reply other threads:[~2004-03-13 22:29 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 [this message]
2004-03-13 22:38 ` James Bottomley
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=40538B39.90803@zytor.com \
--to=hpa@zytor.com \
--cc=James.Bottomley@SteelEye.com \
--cc=akpm@osdl.org \
--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