Hi Doug,
I commented out the other virt_to_phys/phys_to_virt to be safe. I was
able to boot OK with those 2 macros replaced but got the same behavior
as before (the oops from echo m > /proc/sysrq-trigger).
I also tried using the PFN_TO_NID from the 2.4 source but when I tried
that I was unable to boot (forget exactly what the error was at the moment).
Ahh. How did the macro __virt_to_phys in arch/arm/kernel/head.S at
line 43 get implemented?
When I straight swapped memory.h from the 2.4-ts-11 into this kernel I
ran into problems assembling head.S, and a couple of other unsigned
long declarations that the assembler didn't like. I ended up changing
the unsigned long declarations s.t. they were compatible with the newer
assembler, and removing the TASK_SIZE_26 definition. The #ifndef
__ASSEMBLY__ entry on line 144 in memory.h prevents the __virt_to_phys
macro from being used in assembly, so I wonder if the macro has been
re-coded in 2.4's assembly sources.
When you tried your changes did you update discontig.c appropriately
in arch/arm/mm?
I did not make any changes to discontig.c however when I tried the
PFN_TO_NID from 2.4 I changed NODES_SHIFT from 6 down to 4
which would cause MAX_NUMNODES to be 16 (which seems correct
given the hacked PFN_TO_NID code). However as I said that one didn't
boot.
I don't think that's right. The mapping in PFN_TO_NID (line 232 in
memory.h) maps page frame numbers 0xe0, 0xe1, 0xe4, 0xe5 to 16,17,18
and 19 respectfully. This means that we'll need at least 20 nodes, as
the upper 32MiB are located as 4 8MiB pages at 0xe0, e1, e4 and e5 on
my TS7400. I'm not sure about the other TS boards - furthermore, I'm
not sure why in the future we won't be able to specify a mapping onto
say 8 nodes for 64MiB memory, omitting the ones that aren't present on
a particular board.
We're getting close...
Yes we are! I plan on digging into this some more this weekend. I want
to understand exactly what the problem is that causes the oops from
show_mem and also the problem you saw when accessing large amounts
of memory.
I found that the oops was being thrown inside of the do loop inside
of show_mem in arch/arm/mm/init.c . It is likely one of the functions
(macros?) PageReserved, PageSwapCache, PageSlab or page_count - I
haven't identified which one yet. My best guess is that the page table
is screwed up - but I don't know enough about the structures yet.
If I remember correctly you said if you access more than 48M you got a
panic. Was that one big mmap of 48M or a bunch of little ones? Were
you calling mlock on it?
Yes. I compiled up memtester-4.0.6 from
http://pyropus.ca/software/memtester/ - and whenever I specified tests
around the maximum memory of the system I ran into that oops, invoked
from the oom-killer process. When I placed a return statement at the
front of show_mem in arch/arm/mm/init.c I no longer received the oops -
everything seemed ok. However, I think the oops is likely because of a
screwed up set of page tables rather than a bug with show_mem - I may
be wrong about this though!
Cheers,
-Brett
__._,_.___
![]()
SPONSORED LINKS
__,_._,___
|
|