Discussion:
panic: vm_phys_free_pages: page 0x... has unexpected order 0
(too old to reply)
Andriy Gapon
2018-05-21 08:44:05 UTC
Permalink
FreeBSD 12.0-CURRENT amd64 r332472
Does this panic ring a bell to anyone?
Has it already been fixed?
Thank you!

panic: vm_phys_free_pages: page 0xfffff80cbfb71958 has unexpected order 0
cpuid = 3
time = 1526822662
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe017547c340
vpanic() at vpanic+0x18d/frame 0xfffffe017547c3a0
doadump() at doadump/frame 0xfffffe017547c420
vm_phys_free_pages() at vm_phys_free_pages+0x253/frame 0xfffffe017547c450
vm_page_free_phys_pglist() at vm_page_free_phys_pglist+0x37/frame 0xfffffe017547c470
vm_object_terminate() at vm_object_terminate+0x405/frame 0xfffffe017547c4d0
vm_object_deallocate() at vm_object_deallocate+0x45c/frame 0xfffffe017547c530
vm_map_process_deferred() at vm_map_process_deferred+0x99/frame 0xfffffe017547c560
vm_map_remove() at vm_map_remove+0xc6/frame 0xfffffe017547c590
exec_new_vmspace() at exec_new_vmspace+0x185/frame 0xfffffe017547c5f0
exec_elf64_imgact() at exec_elf64_imgact+0x907/frame 0xfffffe017547c6e0
kern_execve() at kern_execve+0x82c/frame 0xfffffe017547ca40
sys_execve() at sys_execve+0x4c/frame 0xfffffe017547cac0
amd64_syscall() at amd64_syscall+0x79b/frame 0xfffffe017547cbf0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe017547cbf0
--
Andriy Gapon
Andriy Gapon
2018-05-29 14:18:03 UTC
Permalink
[ping]
Post by Andriy Gapon
FreeBSD 12.0-CURRENT amd64 r332472
Does this panic ring a bell to anyone?
Has it already been fixed?
Thank you!
panic: vm_phys_free_pages: page 0xfffff80cbfb71958 has unexpected order 0
cpuid = 3
time = 1526822662
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe017547c340
vpanic() at vpanic+0x18d/frame 0xfffffe017547c3a0
doadump() at doadump/frame 0xfffffe017547c420
vm_phys_free_pages() at vm_phys_free_pages+0x253/frame 0xfffffe017547c450
vm_page_free_phys_pglist() at vm_page_free_phys_pglist+0x37/frame 0xfffffe017547c470
vm_object_terminate() at vm_object_terminate+0x405/frame 0xfffffe017547c4d0
vm_object_deallocate() at vm_object_deallocate+0x45c/frame 0xfffffe017547c530
vm_map_process_deferred() at vm_map_process_deferred+0x99/frame 0xfffffe017547c560
vm_map_remove() at vm_map_remove+0xc6/frame 0xfffffe017547c590
exec_new_vmspace() at exec_new_vmspace+0x185/frame 0xfffffe017547c5f0
exec_elf64_imgact() at exec_elf64_imgact+0x907/frame 0xfffffe017547c6e0
kern_execve() at kern_execve+0x82c/frame 0xfffffe017547ca40
sys_execve() at sys_execve+0x4c/frame 0xfffffe017547cac0
amd64_syscall() at amd64_syscall+0x79b/frame 0xfffffe017547cbf0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe017547cbf0
I am adding some more details.
There is certain similarity between this crash and the one reported in
https://lists.freebsd.org/pipermail/freebsd-current/2018-April/069246.html
For example, they have vm_object_terminate_pages() in common.

(kgdb) bt
#0 __curthread () at ./machine/pcpu.h:230
#1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:361
#2 0xffffffff80b67942 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:441
#3 0xffffffff80b67ead in vpanic (fmt=<optimized out>, ap=0xfffffe017547c3e0) at
/usr/src/sys/kern/kern_shutdown.c:837
#4 0xffffffff80b67c30 in kassert_panic (fmt=0xffffffff812d06bd
"vm_phys_free_pages: page %p has unexpected order %d") at
/usr/src/sys/kern/kern_shutdown.c:723
#5 0xffffffff80eae4e3 in vm_phys_free_pages (m=0xfffff80cbfb71958, order=0) at
/usr/src/sys/vm/vm_phys.c:922
#6 0xffffffff80ea6687 in vm_page_free_phys_pglist (tq=<optimized out>) at
/usr/src/sys/vm/vm_page.c:3286
#7 0xffffffff80e9e185 in vm_object_terminate_pages (object=<optimized out>) at
/usr/src/sys/vm/vm_object.c:792
#8 vm_object_terminate (object=0xfffff8036a7cc700) at
/usr/src/sys/vm/vm_object.c:861
#9 0xffffffff80e9d1dc in vm_object_deallocate (object=0xfffff8036a7cc700) at
/usr/src/sys/vm/vm_object.c:684
#10 0xffffffff80e923d9 in vm_map_entry_deallocate (system_map=<error reading
variable: Cannot access memory at address 0x0>, entry=<optimized out>) at
/usr/src/sys/vm/vm_map.c:2997
#11 vm_map_process_deferred () at /usr/src/sys/vm/vm_map.c:541
#12 0xffffffff80e974b6 in _vm_map_unlock (map=<optimized out>, file=<optimized
out>, line=3189) at /usr/src/sys/vm/vm_map.c:554
#13 vm_map_remove (map=<optimized out>, start=4096, end=140737488355328) at
/usr/src/sys/vm/vm_map.c:3189
#14 0xffffffff80b215a5 in exec_new_vmspace (imgp=0xfffffe017547c8b0,
sv=<optimized out>) at /usr/src/sys/kern/kern_exec.c:1099
#15 0xffffffff80af7d37 in exec_elf64_imgact (imgp=<optimized out>) at
/usr/src/sys/kern/imgact_elf.c:922
#16 0xffffffff80b2018c in do_execve (td=<optimized out>, args=<optimized out>,
mac_p=<optimized out>) at /usr/src/sys/kern/kern_exec.c:606
#17 kern_execve (td=<optimized out>, args=<optimized out>, mac_p=<optimized
out>) at /usr/src/sys/kern/kern_exec.c:351
#18 0xffffffff80b1f61c in sys_execve (td=0xfffff803e08cf000,
uap=0xfffff803e08cf3c0) at /usr/src/sys/kern/kern_exec.c:225
#19 0xffffffff810270ab in syscallenter (td=0xfffff803e08cf000) at
/usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:134
#20 amd64_syscall (td=0xfffff803e08cf000, traced=0) at
/usr/src/sys/amd64/amd64/trap.c:936
#21 <signal handler called>
#22 0x00000008003ddd9a in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffffffe6c8

(kgdb) fr 8
#8 vm_object_terminate (object=0xfffff8036a7cc700) at
/usr/src/sys/vm/vm_object.c:861
861 vm_object_terminate_pages(object);

(kgdb) p *object
$1 = {
lock = {
lock_object = {
lo_name = 0xffffffff81202c27 "vm object",
lo_flags = 627245056,
lo_data = 0,
lo_witness = 0xfffff80cffd6a700
},
rw_lock = 18446735294268764160
},
object_list = {
tqe_next = 0xfffff8036a7cc800,
tqe_prev = 0xfffff8036a7cc620
},
shadow_head = {
lh_first = 0x0
},
shadow_list = {
le_next = 0xfffff803705a7a00,
le_prev = 0xfffff805b994d830
},
memq = {
tqh_first = 0xfffff80cbfb71958,
tqh_last = 0xfffff80cbfb71900
},
rtree = {
rt_root = 18446735295662474800
},
size = 1561,
domain = {
dr_policy = 0x0,
dr_iterator = 0
},
generation = 1,
ref_count = 0,
shadow_count = 0,
memattr = 6 '\006',
type = 0 '\000',
flags = 12296,
pg_color = 1809,
paging_in_progress = 0,
resident_page_count = 5,
backing_object = 0x0,
backing_object_offset = 0,
pager_object_list = {
tqe_next = 0x0,
tqe_prev = 0x0
},
rvq = {
lh_first = 0xfffff80cad51cc40
},
handle = 0x0,
un_pager = {
vnp = {
vnp_size = 5,
writemappings = 0
},
devp = {
devp_pglist = {
tqh_first = 0x5,
tqh_last = 0x0
},
ops = 0x0,
dev = 0x0
},
sgp = {
sgp_pglist = {
tqh_first = 0x5,
tqh_last = 0x0
}
},
swp = {
swp_tmpfs = 0x5,
swp_blks = {
pt_root = 0
}
}
},
cred = 0xfffff80c131d0500,
charge = 6393856,
umtx_data = 0x0
}

(kgdb) fr 5
#5 0xffffffff80eae4e3 in vm_phys_free_pages (m=0xfffff80cbfb71958, order=0) at
/usr/src/sys/vm/vm_phys.c:922
922 KASSERT(m->order == VM_NFREEORDER,
(kgdb) p *m
$2 = {
plinks = {
q = {
tqe_next = 0xfffff80cfa917ae8,
tqe_prev = 0xfffff80cfa816fb8
},
s = {
ss = {
sle_next = 0xfffff80cfa917ae8
},
pv = 0xfffff80cfa816fb8
},
memguard = {
p = 18446735333359975144,
v = 18446735333358923704
}
},
listq = {
tqe_next = 0xfffff80cbfb71820,
tqe_prev = 0xfffff80cfa816fc8
},
object = 0x0,
pindex = 1548,
phys_addr = 12144705536,
md = {
pv_list = {
tqh_first = 0x0,
tqh_last = 0xfffff80cbfb71990
},
pv_gen = 65204,
pat_mode = 6
},
wire_count = 0,
busy_lock = 1,
hold_count = 0,
flags = 0,
aflags = 0 '\000',
oflags = 0 '\000',
queue = 255 '\377',
psind = 0 '\000',
segind = 5 '\005',
order = 0 '\000',
pool = 0 '\000',
act_count = 5 '\005',
valid = 0 '\000',
dirty = 0 '\000'
}
--
Andriy Gapon
Jonathan T. Looney
2018-05-31 02:04:13 UTC
Permalink
Post by Andriy Gapon
[ping]
Post by Andriy Gapon
FreeBSD 12.0-CURRENT amd64 r332472
Does this panic ring a bell to anyone?
Has it already been fixed?
Thank you!
Is there any chance that r333703 fixes this problem for you? It fixes a
race that can manifest itself in other ways. I'm honestly not sure whether
it could also cause this problem.

Jonathan
Andriy Gapon
2018-05-31 07:10:40 UTC
Permalink
Post by Andriy Gapon
[ping]
Post by Andriy Gapon
FreeBSD 12.0-CURRENT amd64 r332472
Does this panic ring a bell to anyone?
Has it already been fixed?
Thank you!
Is there any chance that r333703 fixes this problem for you? It fixes a race
that can manifest itself in other ways. I'm honestly not sure whether it could
also cause this problem.
Thank you for the suggestion.
I guess it's worth trying that fix.
I'll report back in a while.
--
Andriy Gapon
Mark Johnston
2018-05-31 11:04:40 UTC
Permalink
Post by Andriy Gapon
Post by Andriy Gapon
[ping]
Post by Andriy Gapon
FreeBSD 12.0-CURRENT amd64 r332472
Does this panic ring a bell to anyone?
Has it already been fixed?
Thank you!
Is there any chance that r333703 fixes this problem for you? It fixes a race
that can manifest itself in other ways. I'm honestly not sure whether it could
also cause this problem.
Thank you for the suggestion.
I guess it's worth trying that fix.
I'll report back in a while.
r333703 fixes a bug in r332974, while the problem was reported on
r332472, so it won't address the crash.

Loading...