On Thu, Sep 25, 2003 at 11:15:57AM -0400, Robert Watson wrote: > ... > #6 0xc049f355 in vm_fault (map=0xc6fc1700, vaddr=0, fault_type=1 '\001', > fault_flags=0) at /usr/src/sys/vm/vm_fault.c:219 > #7 0xc04eddd9 in trap_pfault (frame=0xdd699b18, usermode=0, eva=0) > at /usr/src/sys/i386/i386/trap.c:709 > #8 0xc04eda50 in trap (frame= > {tf_fs = -1070333928, tf_es = -1067384816, tf_ds = 16, tf_edi = 0, > tf_esi = -1068054086, tf_ebp = -580281484, tf_isp = -580281532, tf_ebx = > 441, tf_edx = -968258896, tf_ecx = 0, tf_eax = -968258896, tf_trapno = 12, > tf_err = 0, tf_eip = -1070325008, tf_cs = 8, tf_eflags = 66178, tf_esp = > 0, tf_ss = -1068146900}) > at /usr/src/sys/i386/i386/trap.c:418 > #9 0xc04dd9e8 in calltrap () at {standard input}:102 > #10 0xc04adbde in vm_page_sleep_if_busy (m=0x1b9, also_m_busy=1, msg=0x0) > at /usr/src/sys/vm/vm_page.c:441 > #11 0xc04abcfb in vm_object_split (entry=0xc6eea8ac) > at /usr/src/sys/vm/vm_object.c:1226 > ... Based upon the above information, it looks like vm_object_split() followed a bogus vm page pointer. This is in frequently executed code. So, I would hypothesize a race condition or transient hardware error is responsible. When my recent amd64 and i386 pmap changes are replicated on all platforms that will enable me to introduce additional assertions on the vm object locking. That may reveal some unsynchronized vm object accesses that could lead to the above problem. AlanReceived on Thu Sep 25 2003 - 20:54:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:23 UTC