Theo de Raadt wrote: > > Can you try this with -current? > > > I tried with current but it froze on bootup after loading the Intel MTRR. Vijay is having the same problem though and he said that current did not solve the problem.
Im very suspicious of the following piece of code in arch/i386/i386/pmap.c, function pmap_page_remove_86: 3052 #if defined(MULTIPROCESSOR) 3053 /* 3054 * Always shoot down the other pmap's 3055 * self-mapping of the PTP. 3056 */ 3057 pmap_tlb_shootdown(pve->pv_pmap, 3058 ((vaddr_t)PTE_BASE) + pve->pv_ptp->offset, 3059 opte, &cpumask); 3060 #endif To start with, I cant even find this function except in the arch/alpha section. Also, I tried following the trace through each function and I cant figure out how many of these functions are calling eachother. pmap_page_remove_86(d0d31420,c0,e9b57e2c,d04adeb9,e99f) at pmap_page_remove_86+0x125 uvm_vnp_terminate(d8034e04,0,0,0,0,14,0,d7e95004) at uvm_vnpterminate+0x36b uvm_attach(d8034e04,0,2,0,d7f38378) at uvn_attach+0x2d1 uvm_unmap_detach(d7e959a4,0,d7f3841c,1) at uvm_unmap_detach+-x76 uvmspace_free(d7f38378,6,d08120e0) at uvmspace_free+0x10d uvm_exit(d7fbb868,14,8,286) at uvm_exit+0x13 reaper(d80df430) at reaper+0x9a Bad frame pointer: 0xd0933eb8 Another question, whats with the uvn_attach versus uvm_attach above? Vijay also claimed that it was much easier for him to reproduce the problem. Im guessing that this is because he has a slower processor as well as half the amount of memory as I do. That makes it easier for him to bog down the processors, and cause virtual memory swaps if either of those are linked with the problem. Thanks
