Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD 7 and current issues

Mouse skrev den 2015-08-17 15:36:
0x84058d38: pmap_enter+0x241(0x816ed2d0,0x40005000,0x1370000,0x5,0x20)
0x84058d88: uvm_fault_internal+0xb9b(0x81663d40,0x40004000,0x1,0)
However, we can see that pmap_enter tries tries to map in space at
0x40005000, which means that it needs to map virtually the whole P1
pte space, which is the problem.
Eight megabytes of system space?  Strikes me as a lot, for a VAX.  (Is
system space even eight megabytes big?)
System space is based on physical memory size + other stuff.
All physical memory is directly mapped to the first part of system space.
This is done early in the boot process.  Here is also the user page table
size included at a total of 1GB which takes 8MB of kernel virtual memory.

Or is the VAX pmap in question maybe trying to be prepared for the
rtVAX case and demanding physically contiguous pages?
No, but since the system page table must reside in physical memory it
is allocated at boot.  8MB takes 64k of physical memory which is quite
much on a vax as you know :-)

So the interesting thing is why this specific address is mapped.
mmap'ed space should go just below the stack, and not in the bottom
of P1.
What makes you think it's mmapped?  I'm wondering if this could be a
misfire somewhere in the `extend the stack' code, trying to extend the
stack through all of P1 space.
Not likely, since there is a stack limit MAXSSIZ is 8MB. Below it is all mmap space.

-- Ragge

Home | Main Index | Thread Index | Old Index