Alan Cox wrote: >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. > >Alan >_______________________________________________ > > FWIW, I got this same panic a few days ago, running portinstall shortly after gnome2 had fillled my fd table for some unknown reason, on 5.1-RELEASE-p5. AdamReceived on Thu Sep 25 2003 - 21:18:04 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:23 UTC