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 :-)
Not likely, since there is a stack limit MAXSSIZ is 8MB. Below it is all mmap space.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.
-- Ragge