The patch you point to will maybe solve some initrd problems,
but I think it's treating a symptom rather than the cause. There
is other code, both generic and MIPS-specific (the APRP stuff),
that assumes that max_pfn is meaningful. Either we have to hunt
down and kill those instances (not really hard, but requiring several
maintainers working in concert) or we see to it that MIPS provides
a usable value. A value of 0 causes the system to treat the beginning
of kseg0 as "out of band" memory, which may work some of the time
for MIPSxxR2 processors, where the cacheable execption vector
base is set up to be beyond the kernel image, but for older processors
where the vectors are at the beginning of kseg0...
Regards,
Kevin K.
Geert Uytterhoeven wrote:
On Tue, 1 Apr 2008, Kevin D. Kissell wrote:
Once upon a time, the global max_pfn value was set up as part of
bootmem_init(), but this seems to have been dropped in favor of
establishing max_low_pfn, I suppose to be clear that it's the max
non-highmem PFN. However, the global max_pfn gets used in
the MIPS APRP support code, and also in places like
block/blk-settings.c. Is the use of max_pfn supposed to be
deprecated, such that we consider blk-settings.c to be broken
and change arch/mips/kernel/vpe.c to use max_low_pfn, or
ought we assign max_pfn = max_low_pfn in bootmem_init()?
I noticed this too when investigating why initrds no longer worked on
m68k (Fix in http://lkml.org/lkml/2007/12/23/36, still not in mainline).
Apparently a value of max_pfn = 0 is OK, as several architectures
(including MIPS and m68k) don't touch it?
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
