DragonFlyBSD

I get this panic sometimes when using firefox. I don't have a determinate series of steps to get there, but I can get it on demand. For whatever reason, the Washington Post's site is a good way to get it, though of course not the only way (searching google images did it once for me too). Here's what I did today.

1. booted, opened firefox and browsed to http://www.washingtonpost.com/blogs/wonkblog/wp/2012/11/19/were-on-pace-for-4c-of-global-warming-heres-why-the-world-bank-is-terrified/
2. middle clicked a link to open the following url in a new tab: http://www.washingtonpost.com/blogs/wonkblog/post/faq-can-the-durban-climate-talks-avert-catastrophe/2011/12/09/gIQAADqzhO_blog.html
3. right clicked a link to open the following url in a new window: http://www.washingtonpost.com/blogs/wonkblog/wp/2012/11/30/graph-of-the-day-medicaid-medicare-patients-most-satisfied-with-health-costs/
4. clicked on the graph of satisfaction with costs paid for health care to expand it.
5. clicked the back button. I had enough time to move the mouse a few hundred pixels before everything froze. I hit ctrl-alt-esc to get a kernel dump.

Then I rebooted and started firefox again. It tried to load the same set of tabs and windows and the system froze again. I have another kernel dump for that panic.

Finally, I rebooted and set sysctl machdep.pmap_mmu_optimize: 1 -> 0
Then firefox succeeded in loading that set of pages. Then I opened several more tabs and windows of the Post's articles simultaneously to try to get the panic but could not.

This is a git pull from a couple of days ago:
DragonFly rex 3.3-DEVELOPMENT DragonFly v3.3.0.664.g75bea-DEVELOPMENT #0: Wed Nov 28 00:03:29 EST 2012 root@rex:/usr/obj/usr/src/sys/X86_64_GENERIC_DIAG x86_64

114 rex:~> diff u /usr/src/sys/config/X86_64_GENERIC{,_DIAG}
-- /usr/src/sys/config/X86_64_GENERIC 2012-11-27 21:08:40.709392000 -0500
++ /usr/src/sys/config/X86_64_GENERIC_DIAG 2012-11-27 21:16:35.182170000 -0500
@ -63,6 +63,8 @
options DDB
options DDB_TRACE
options INVARIANTS
# The DIAGNOSTIC option is used to enable extra debugging information
+options DIAGNOSTIC

#options       ACPI_DEBUG

I got these same panics from a git pull from Nov 4th last week, but wanted to try something newer before reporting.

I'm attaching the core.txt file from the latest panic. I can send the kern.x and vmcore.x if you want and can tell me a good place to upload them. I could put them on my panix account but I think I'd hit a download quota when you picked them up.

Every panic seems to happen during a syscall from Xorg:

#12 0xffffffff8052ef3f in sys_shmdt (uap=0xffffffe064dfeb48) at /usr/src/sys/kern/sysv_shm.c:240
240 error = shm_delete_mapping(p->p_vmspace, shmmap_s);
(kgdb) p *p
$1 = {p_list = {le_next = 0xffffffe03046e180, le_prev = 0xffffffe030474080}, p_ucred = 0xffffffe06520c120, p_fd = 0xffffffe004d7d7a0, p_fdtol = 0x0, p_limit = 0xffffffe004cd25d0,
p_stats = 0x0, p_mqueue_cnt = 0, p_pad0 = 0x0, p_sigacts = 0xffffffe0304b0500, p_flags = 16640, p_stat = SACTIVE, p_pad1 = "\000\000", p_pid = 977, p_hash = {le_next = 0x0,
le_prev = 0xffffffe013fe5e88}, p_pglist = {le_next = 0x0, le_prev = 0xffffffe0415a8370}, p_pptr = 0xffffffe03046e180, p_sibling = {le_next = 0x0, le_prev = 0xffffffe030474108},
p_children = {lh_first = 0x0}, p_ithandle = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0xffffffff824ad490}}, c_time = 35248, c_arg = 0xffffffe030473180,
c_func = 0xffffffff8050ed86 <realitexpire>, c_flags = 30, c_gd = 0xffffffff824fd000}, p_varsymset = {vx_queue = {tqh_first = 0x0, tqh_last = 0xffffffe030473258}, vx_setsize = 0,
vx_lock = {lk_spinlock = {counta = 0, countb = 0}, lk_flags = 0, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 0, lk_unused1 = 0, lk_wmesg = 0xffffffff80950361 "vx",
lk_timo = 0, lk_lockholder = 0xffffffffffffffff}}, p_iosdata = {iorbytes = 0, iowbytes = 0, lastticks = 0}, p_oppid = 0, p_vmspace = 0xffffffe013f55700, p_swtime = 151,
p_realtimer = {it_interval = {tv_sec = 0, tv_usec = 20000}, it_value = {tv_sec = 366, tv_usec = 256891}}, p_timer = {{it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {
tv_sec = 0, tv_usec = 0}}, {it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 0, tv_usec = 0}}, {it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 0,
tv_usec = 0}}}, p_traceflag = 0, p_tracenode = 0x0, p_siglist = {__bits = {0, 0, 0, 0}}, p_textvp = 0xffffffe06457d1a0, p_textnch = {ncp = 0xffffffe0415a9710,
mount = 0xffffffe064545100}, p_stops = 0, p_stype = 0, p_step = 0 '\000', p_pfsflags = 0 '\000', p_pad2 = "\000", p_sigiolst = {slh_first = 0xffffffe013e0ef80},
p_sigparent = 20, p_klist = {slh_first = 0x0}, p_start = {tv_sec = 1354387232, tv_usec = 415111}, p_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0,
tv_usec = 0}, ru_maxrss = 103080, ru_ixrss = 277552, ru_idrss = 13692, ru_isrss = 15232, ru_minflt = 0, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0,
ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, p_cru = {ru_utime = {tv_sec = 0, tv_usec = 46853}, ru_stime = {tv_sec = 0, tv_usec = 31306},
ru_maxrss = 4100, ru_ixrss = 3060, ru_idrss = 164, ru_isrss = 512, ru_minflt = 6326, ru_majflt = 8, ru_nswap = 0, ru_inblock = 68, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0,
ru_nsignals = 0, ru_nvcsw = 48, ru_nivcsw = 0}, p_dsched_priv1 = 0xffffffe03074ace8, p_comm = "Xorg\000\000r\000\000\000\000\000\000\000\000\000", p_pad3 = 0 '\000',
p_nice = 0 '\000', p_pad4 = 0 '\000', p_osrel = 300301, p_pgrp = 0xffffffe0415a8360, p_sysent = 0xffffffff80ce6f80, p_prof = {pr_base = 0x0, pr_size = 0, pr_off = 0, pr_scale = 0,
pr_addr = 0, pr_ticks = 0}, p_rtprio = {type = 1, prio = 0}, p_args = 0xffffffe04162bdd8, p_xstat = 0, p_ionice = 0, p_dsched_priv2 = 0x0, p_acflag = 0, p_lock = 0,
p_nthreads = 1, p_nstopped = 0, p_lasttid = 0, p_lwp_tree = {rbh_root = 0xffffffe013f5bd80, rbh_inprog = 0x0, rbh_spin = {counta = 0, countb = 0}}, p_aioinfo = 0x0, p_wakeup = 0,
p_peers = 0x0, p_leader = 0xffffffe030473180, p_emuldata = 0x0, p_usched = 0xffffffff80c84520, p_vkernel = 0x0, p_numposixlocks = 0, p_userret = 0, p_spin = {counta = 0,
countb = 0}, p_token = {t_count = 0, t_ref = 0x0, t_collisions = 141, t_desc = 0xffffffff80981177 "proc"}, p_sem_undo = 0x0}

The value of pmap->pm_stats.resident_count varies with each panic. I've seen values of 3, twenty something, and 11.
pmap->pm_stats.wired_count has been zero each time.

Here's the stack trace in kgdb:

#0 _get_mycpu () at ./machine/thread.h:69
#1 md_dumpsys (di=<optimized out>) at /usr/src/sys/platform/pc64/x86_64/dump_machdep.c:265
#2 0xffffffff804f0872 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:913
#3 0xffffffff804f0ed6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:373
#4 0xffffffff804f118d in panic (fmt=0xffffffff808ebf40 "assertion \"%s\" failed in %s at %s:%u") at /usr/src/sys/kern/kern_shutdown.c:819
#5 0xffffffff808cec0b in pmap_release (pmap=<optimized out>) at /usr/src/sys/platform/pc64/x86_64/pmap.c:1907
#6 0xffffffff808d06dd in pmap_object_free (object=0xffffffe0655b6000) at /usr/src/sys/platform/pc64/x86_64/pmap.c:4609
#7 0xffffffff8071ab6b in vm_object_terminate (object=0xffffffe0655b6000) at /usr/src/sys/vm/vm_object.c:932
#8 0xffffffff8071c56f in vm_object_deallocate_locked (object=0xffffffe0655b6000) at /usr/src/sys/vm/vm_object.c:847
#9 0xffffffff8071c88b in vm_object_deallocate (object=0xffffffe0655b6000) at /usr/src/sys/vm/vm_object.c:640
#10 0xffffffff8052ed1d in shm_deallocate_segment (shmseg=0xffffffe0414a0000) at /usr/src/sys/kern/sysv_shm.c:179
#11 0xffffffff8052ede8 in shm_delete_mapping (vm=<optimized out>, shmmap_s=0xffffffe0652eb010) at /usr/src/sys/kern/sysv_shm.c:205
#12 0xffffffff8052ef3f in sys_shmdt (uap=0xffffffe064dfeb48) at /usr/src/sys/kern/sysv_shm.c:240
#13 0xffffffff808a81fe in syscall2 (frame=0xffffffe064dfebf8) at /usr/src/sys/platform/pc64/x86_64/trap.c:1244
#14 0xffffffff80891a0b in Xfast_syscall () at /usr/src/sys/platform/pc64/x86_64/exception.S:323
#15 0x000000000000002b in ?? ()