> There are more bugs, like in mm/swapfile.c:unuse_pte(), where a page
> struct ptr is used as an argument to MAP_NR. :(
> I tried to update the m68k kernel to 2.3.23 during the weekend and gave up
> because of the mess. Why the hell has pte_page() a different meaning now,
> but still the same name (without a single comment)?
> I'm wondering how that works at all... :(
Linus did communicate with the port maintainers to fix related problems
before the 2.3.24 release, below his email.
I haven't yet updated MIPS because > 2.3.9 are an unstable mess, I need
to fix that first.
Date: Wed, 20 Oct 1999 18:23:19 -0700 (PDT)
From: Linus Torvalds <firstname.lastname@example.org>
To: "David S. Miller" <email@example.com>, firstname.lastname@example.org,
Paul Mackerras <email@example.com>, Jes.Sorensen@cern.ch,
Subject: architecture bootup changes..
Just a heads-up that in order to avoid various nasty wrapping issues etc
with more than 1GB of memory on 32-bit machines (virtual address
wraparound) and in order to handle more than 4GB at all (physical address
wraparound), the bootup sequence memory management got changed the last
In most cases, it really shouldn't matter all that much, but generally the
architecture-specific "init_mem()" call needs some changes to inform the
new bootup memory allocator about what areas it can use, etc. And some
things are more "struct page *" based than based on virtual kernel
addresses, as the high memory support got cleaned up and better integrated
in the memory management.
In short, it mainly only impacts architecture initialization (although we
also added debugging code to catch "suspicious" use of IO pointers for the
IO access functions - that causes debugging messages for ISA drivers that
depend on old behaviour to be printed out, but they should work the same
way they did before).
So at some point it would be nice if you would take a look at your
respective architectures - see arch/i386/kernel/setup.c and the
"setup_arch()" function changes for memory handling in particular. For
most of you I would assume that this allows you to clean things up rather
than make things worse, but who knows..
I haven't released a real kernel with this yet, but it's in
on ftp.kernel.org in "testing" in case you want to sync up. No real hurry,
although it's obviously less embarrassing for me the quicker the
architectures catch up.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/