Bug 192825
| Summary: | Continual Core Dumps vm_page_unwire: wire count is zero | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Michelle Sullivan <michelle> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed Overcome By Events | ||
| Severity: | Affects Many People | CC: | cryptogodfatherva45, easyworknet288, markj, nicolas.masse |
| Priority: | Normal | Flags: | cryptogodfatherva45:
maintainer-feedback+
|
| Version: | 9.2-RELEASE | ||
| Hardware: | i386 | ||
| OS: | Any | ||
| URL: | http://www.mhix.org/FreeBSDCores/92-i386/Tue.Aug.19.11.34.18.CEST.2014/ | ||
|
Description
Michelle Sullivan
2014-08-19 09:59:35 UTC
Lots more cores in the same place (URL) and in the i386 directory. Issue appears to be limited to i386 platform with ZFS/ARC when physical memory exhaustion occurs. Panics are very very common when (for example) checking out the ports tree onto a ZFS FS (eg using poudriere)... Remove all swap devices and no panics occur. Checking to see if the same occurs on 9.3 soon (I have had many panics on 9.3 i386, but until now no dumpdev configured) I have the same issue here on FreeBSD-9.3. And I'm working on a physical machine, not a Virtual one.
Stacktrace :
#0 doadump (textdump=16192120) at ../../../kern/kern_shutdown.c:277
#1 0xffffffff802e8d5c in db_fncall_generic (addr=-2142138064, rv=0xffffff8000f71218, nargs=0, args=0xffffff8000f711c0) at ../../../ddb/db_command.c:573
#2 0xffffffff802e8c65 in db_fncall (dummy1=-549739621760, dummy2=0, dummy3=-549739621568, dummy4=0xffffff8000f71290 "<o\211\200����\204\034�\200����")
at ../../../ddb/db_command.c:625
#3 0xffffffff802e8899 in db_command (last_cmdp=0xffffffff80bf0d20, cmd_table=0x0, dopager=0) at ../../../ddb/db_command.c:449
#4 0xffffffff802e8a69 in db_command_script (command=0xffffffff80bf1c85 "call doadump()") at ../../../ddb/db_command.c:520
#5 0xffffffff802edefe in db_script_exec (scriptname=0xffffffff80896f3c "kdb.enter.default", warnifnotfound=0) at ../../../ddb/db_script.c:302
#6 0xffffffff802edfc5 in db_script_kdbenter (eventname=0xffffffff808e23a2 "panic") at ../../../ddb/db_script.c:325
#7 0xffffffff802eb80b in db_trap (type=3, code=0) at ../../../ddb/db_main.c:230
#8 0xffffffff8055d56b in kdb_trap (type=3, code=0, tf=0xffffff8000f71770) at ../../../kern/subr_kdb.c:651
#9 0xffffffff80804b72 in trap (frame=0xffffff8000f71770) at ../../../amd64/amd64/trap.c:572
#10 0xffffffff807e7083 in calltrap () at ../../../amd64/amd64/exception.S:232
#11 0xffffffff8055cfd5 in breakpoint () at cpufunc.h:63
#12 0xffffffff8055cfc2 in kdb_enter (why=0xffffffff808e23a2 "panic", msg=0xffffffff808e23a2 "panic") at ../../../kern/subr_kdb.c:440
#13 0xffffffff8051a181 in panic (fmt=0xffffffff8092caa0 "vm_page_unwire: page %p's wire count is zero") at ../../../kern/kern_shutdown.c:736
#14 0xffffffff807d0836 in vm_page_unwire (m=0xfffffe00d91e90c8, activate=1) at ../../../vm/vm_page.c:2219
#15 0xffffffff807b8822 in vm_fault_unwire (map=0xfffffe0076ddb4b0, start=34366525440, end=34366529536, fictitious=0) at ../../../vm/vm_fault.c:1242
#16 0xffffffff807c18e9 in vm_map_entry_unwire (map=0xfffffe0076ddb4b0, entry=0xfffffe008d434600) at ../../../vm/vm_map.c:2754
#17 0xffffffff807c1e44 in vm_map_delete (map=0xfffffe0076ddb4b0, start=34366525440, end=34366529536) at ../../../vm/vm_map.c:2916
#18 0xffffffff807c5a9c in sys_munmap (td=0xfffffe0076d29490, uap=0xffffff8000f71bc0) at ../../../vm/vm_mmap.c:613
#19 0xffffffff8080626c in syscallenter (td=0xfffffe0076d29490, sa=0xffffff8000f71bb0) at subr_syscall.c:133
#20 0xffffffff80805d79 in amd64_syscall (td=0xfffffe0076d29490, traced=0) at ../../../amd64/amd64/trap.c:979
#21 0xffffffff807e7367 in Xfast_syscall () at ../../../amd64/amd64/exception.S:391
#22 0x00000008011ec16c in ?? ()
FYI :
(kgdb) f 14
#14 0xffffffff807d0836 in vm_page_unwire (m=0xfffffe00d91e90c8, activate=1) at ../../../vm/vm_page.c:2219
2219 ../../../vm/vm_page.c: No such file or directory.
in ../../../vm/vm_page.c
(kgdb) p *m
$1 = {
pageq = {
tqe_next = 0xfffffe00d91a4608,
tqe_prev = 0xfffffe00d91a3618
},
listq = {
tqe_next = 0x0,
tqe_prev = 0xfffffe0004cfc6a0
},
left = 0x0,
right = 0x0,
object = 0xfffffe0004cfc658,
pindex = 0,
phys_addr = 3352719360,
md = {
pv_list = {
tqh_first = 0xfffffe0004d86040,
tqh_last = 0xfffffe0004d86048
},
pat_mode = 6
},
queue = 1 '\001',
segind = 2 '\002',
hold_count = 0,
order = 13 '\r',
pool = 0 '\0',
cow = 0,
wire_count = 0,
aflags = 3 '\003',
flags = 0 '\0',
oflags = 0,
act_count = 5 '\005',
busy = 0 '\0',
valid = 255 '�',
dirty = 255 '�'
}
Nicolas: Single or multiple CPU? Multiple (one quadcore-cpu to be exact) Probably not going to help you then, but I have found that switching to a single CPU stops the panics. From my investigations the ARC/metadata will blow out the kmem until it's exhausted on multiple CPUs (ignoring the *_max settings).. switching to a single CPU and this still happens but resets itself after a while to the *_max limits ... HI I'm sorry that this didn't get any attention when it was submitted. The panicking code has changed substantially since 9.2. Please re-open if this bug still occurs on supported FreeBSD versions. |
