On Sat, Jan 07, 2012 at 11:30:59AM +0000, Stuart Henderson wrote: > Can anyone suggest reasons for a firewall doing this? Happened a few > times to this machine, first on i386 GENERIC from May 3, now on Dec 9th.
> panic: pmap_remove_ptes: unmanaged page marked PG_PVLIST, va = 0x56c5000, pa > = 0xfffff000 > Starting stack trace... > panic(d08d41b8,dc249e18,d08d7440,dc249e18,d14f944c) at panic+0x6a > panic(d08d7440,56c5000,fffff000,56cd000,0) at panic+0x6a > pmap_remove_ptes(d6d35ab0,d14f944c,ffc15b14,56c5000,56cd000) at > pmap_remove_ptes+0x159 > pmap_do_remove(d6d35ab0,56c5000,56cd000,0,2) at pmap_do_remove+0xeb > pmap_remove(d6d35ab0,56c5000,56cd000,d03e64f0,d0add9f4) at pmap_remove+0x27 > uvm_unmap_remove(d6a73928,1000,cfbfe000,dc249f3c,0) at uvm_unmap_remove+0x167 > uvmspace_free(d6a73928,1,1,dc249f6c,d0203151) at uvmspace_free+0xe0 > uvm_exit(d6a4bc28,d09b95a8,4,d08b076e,0) at uvm_exit+0x15 > reaper(d6d3ad70) at reaper+0x8a > Bad frame pointer: 0xd0b93e68 > End of stack trace. > syncing disks... 3 1 done The panic means the page is marked as being a managed page, but the management info was missing. A managed page can be shared across multiple processes and may require multiple processes to be notified on changes (like when the page is being paged-out to disk, the processes need to have that page removed from their pmap). Is the machine still in ddb? If it is, can you do show page /f 0xd14f944c (the address is the second argument to pmap_remove_ptes). (Since these bits are pmap internal bits, I don't think the recent bugfix in pmemrange will have any effect on this bug.) -- Ariane
