Date: Tue, 7 Jan 2003 22:24:49 -0800 From: steve@Watt.COM (Steve Watt) To: stable@freebsd.org Subject: panic: vm_map_fork: encountered a submap Message-ID: <200301080624.h086Oono004995@wattres.Watt.COM>
next in thread | raw e-mail | index | archive | help
OK, I guess I'm getting lucky (not) this week. After my ugly filesystem
panic a couple of days ago (lost six files -- backups? naah), I got a
vm_map_fork: encountered a submap
panic this evening.
The current process was sh. The trace looks like:
(kgdb) where
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc01f2e18 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
#2 0xc01f324c in poweroff_wait (junk=0xc037b3e0, howto=-855254336)
at /usr/src/sys/kern/kern_shutdown.c:595
#3 0xc02d3edc in vmspace_fork (vm1=0xccec2080) at /usr/src/sys/vm/vm_map.c:2421
#4 0xc02d103b in vm_fork (p1=0xcce3a000, p2=0xcd05dac0, flags=20)
at /usr/src/sys/vm/vm_glue.c:232
#5 0xc01ec357 in fork1 (p1=0xcce3a000, flags=20, procp=0xcd04bf30)
at /usr/src/sys/kern/kern_fork.c:488
#6 0xc01ebb0e in fork (p=0xcce3a000, uap=0xcd04bf80)
at /usr/src/sys/kern/kern_fork.c:100
#7 0xc031204d in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0,
tf_esi = 135041024, tf_ebp = -1077937600, tf_isp = -855326764, tf_ebx = 0,
tf_edx = 135030556, tf_ecx = 0, tf_eax = 2, tf_trapno = 12, tf_err = 2,
tf_eip = 134674540, tf_cs = 31, tf_eflags = 514, tf_esp = -1077937628, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1175
#8 0xc0305ff5 in Xint0x80_syscall ()
#9 0x804b91f in ?? ()
#10 0x804acc0 in ?? ()
#11 0x805288c in ?? ()
#12 0x80527f6 in ?? ()
#13 0x804813e in ?? ()
(kgdb) up
#1 0xc01f2e18 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
316 dumpsys();
(kgdb) up
#2 0xc01f324c in poweroff_wait (junk=0xc037b3e0, howto=-855254336)
at /usr/src/sys/kern/kern_shutdown.c:595
595 boot(bootopt);
(kgdb) up
#3 0xc02d3edc in vmspace_fork (vm1=0xccec2080) at /usr/src/sys/vm/vm_map.c:2421
2421 panic("vm_map_fork: encountered a submap");
(kgdb) list
2416
2417 old_entry = old_map->header.next;
2418
2419 while (old_entry != &old_map->header) {
2420 if (old_entry->eflags & MAP_ENTRY_IS_SUB_MAP)
2421 panic("vm_map_fork: encountered a submap");
2422
2423 switch (old_entry->inheritance) {
2424 case VM_INHERIT_NONE:
2425 break;
(kgdb) print vm1
$4 = (struct vmspace *) 0xc037b3e0
(kgdb) print *vm1
$1 = {vm_map = {header = {prev = 0x6d5f6d76, next = 0x665f7061, start = 980120175,
end = 1668179232, avail_ssize = 1953396079, object = {vm_object = 0x64657265,
sub_map = 0x64657265}, offset = 7020375650722668832, eflags = 112,
protection = 0 '\000', max_protection = 0 '\000', inheritance = 0 '\000',
wired_count = 0, lastr = 0}, lock = {lk_interlock = {lock_data = 0}, lk_flags = 0,
lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 24898, lk_prio = 8292,
lk_wmesg = 0x72746e65 <Address 0x72746e65 out of bounds>, lk_timo = 1953702009,
lk_lockholder = 796160609}, nentries = 543452773, size = 544370534,
system_map = 110 'n', infork = 101 'e', hint = 0x63617473, timestamp = 1852121195,
first_free = 0x797274, pmap = 0x0}, vm_pmap = {pm_pdir = 0x0, pm_pteobj = 0x0,
pm_pvlist = {tqh_first = 0x0, tqh_last = 0x0}, pm_count = 0, pm_active = 543449410,
pm_stats = {resident_count = 1667331187, wired_count = 1919361131},
pm_ptphint = 0x7320776f}, vm_refcnt = 1953653108,
vm_shm = 0x646e652f <Address 0x646e652f out of bounds>, vm_rssize = 544106784,
vm_swrss = 544695662, vm_tsize = 1667331187, vm_dsize = 1852121195,
vm_ssize = 7959156, vm_taddr = 0x0, vm_daddr = 0x0, vm_maxsaddr = 0x0,
vm_minsaddr = 0x0}
(kgdb) print old_entry
$2 = 0xc037b3e0
(kgdb) print *old_entry
$3 = {prev = 0x6d5f6d76, next = 0x665f7061, start = 980120175, end = 1668179232,
avail_ssize = 1953396079, object = {vm_object = 0x64657265, sub_map = 0x64657265},
offset = 7020375650722668832, eflags = 112, protection = 0 '\000',
max_protection = 0 '\000', inheritance = 0 '\000', wired_count = 0, lastr = 0}
(kgdb) print *(struct proc *)curproc
$6 = {p_procq = {tqe_next = 0xcd05bbe0, tqe_prev = 0xc0400de0}, p_list = {
le_next = 0xcd05bbe0, le_prev = 0xcd05dac8}, p_cred = 0xc138d3e0, p_fd = 0xc1134b00,
p_stats = 0xcd049cd0, p_limit = 0xc1445d00, p_upages_obj = 0xcd0171e0,
p_procsig = 0xc1535000, p_flag = 16388, p_stat = 2 '\002', p_pad1 = "\000\000",
p_pid = 56896, p_hash = {le_next = 0xcce3c220, le_prev = 0xc0b34d00}, p_pglist = {
le_next = 0xcd05dac0, le_prev = 0xcd05c0fc}, p_pptr = 0xcd05c0c0, p_sibling = {
le_next = 0x0, le_prev = 0xcd05c110}, p_children = {lh_first = 0xcd05dac0},
p_ithandle = {callout = 0xc382e4a8}, p_oppid = 0, p_dupfd = 0, p_vmspace = 0xccec2080,
p_estcpu = 36, p_cpticks = 0, p_pctcpu = 1093, p_wchan = 0x0, p_wmesg = 0x0,
p_swtime = 3, p_slptime = 0, p_realtimer = {it_interval = {tv_sec = 0, tv_usec = 0},
it_value = {tv_sec = 0, tv_usec = 0}}, p_runtime = 0, p_uu = 0, p_su = 0, p_iu = 0,
p_uticks = 0, p_sticks = 1410, p_iticks = 2, p_traceflag = 0, p_tracep = 0x0,
p_siglist = {__bits = {0, 0, 0, 0}}, p_textvp = 0xcca37740, p_lock = 1 '\001',
p_oncpu = 0 '\000', p_lastcpu = 0 '\000', p_rqindex = 12 '\f', p_locks = -269,
p_simple_locks = 0, p_stops = 0, p_stype = 0, p_step = 0 '\000',
p_pfsflags = 0 '\000', p_pad3 = "\000", p_retval = {0, 135030556}, p_sigiolst = {
slh_first = 0x0}, p_sigparent = 20, p_oldsigmask = {__bits = {0, 0, 0, 0}},
p_sig = 0, p_code = 0, p_klist = {slh_first = 0x0}, p_sigmask = {__bits = {0, 0, 0,
0}}, p_sigstk = {ss_sp = 0x0, ss_size = 0, ss_flags = 4}, p_priority = 54 '6',
p_usrpri = 54 '6', p_nice = 0 '\000',
p_comm = "sh\000n\000er\000\000\000\000\000\000\000\000\000", p_pgrp = 0xc1374ec0,
p_sysent = 0xc03aaa00, p_rtprio = {type = 1, prio = 0}, p_prison = 0x0,
p_args = 0xc15d9c80, p_addr = 0xcd049000, p_md = {md_regs = 0xcd04bfa8}, p_xstat = 0,
p_acflag = 0, p_ru = 0x0, p_nthreads = 0, p_aioinfo = 0x0, p_wakeup = 0,
p_peers = 0x0, p_leader = 0xcce3a000, p_asleep = {as_priority = 0, as_timo = 0},
p_emuldata = 0x0}
For some reason, I seem to be getting questionable data from
some of my debugging sessions (for example the *vm1 above is really
the panic string).
The machine was running a late November (about 21 Nov) -STABLE until the
softdeps panic on 4 Jan, at which point I did a refresh to -STABLE. Then
this panic tonight... guess I'm having a bad week.
I'm not seeing any recent changes to vm_map that could be causing
this, but I'm not that deeply into the VM subsystem. Clues?
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9"
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301080624.h086Oono004995>