Bug #2466
Updated by tuxillo over 10 years ago
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 ?? ()