On Fri, Apr 17, 2009 at 03:06, Michael Schmitz
<schmitz@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Geert, Roman: does paging_init rely on part of the first memory chunk being
mapped in head.S, or just part of the chunk the kernel resides in? Could I
reorder the m68k_memory[] elements in setup.c to fix the ordering problems?
Should work. config_amiga() removes Zorro II memory chunks, and that's
just before
paging_init() is called. of course you cannot reorder the first chunk,
as that one is
already in use.
Found that out the hard way. So what's the fix for this? Does the first chunk
always have to be the one the kernel resides in?
What is the reason for dropping chunks that are residing below the fisrst one,
in paging_init ??
`git blame' tells you that code was added by
commit 12d810c1b8c2b913d48e629e2b5c01d105029839
Author: Roman Zippel <zippel@xxxxxxxxxxxxxx>
Date: Thu May 31 00:40:54 2007 -0700
m68k: discontinuous memory support
Probably discontigmem supports only increasing physical addresses of the
multiple memory chunks :-(
But the newer sparsemem generic model may support it, see
Documentation/memory-hotplug.txt.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
