panic: detach with active requests on 10.1-RC3
Guido Falsi
madpilot at FreeBSD.org
Fri Oct 24 16:10:24 UTC 2014
Hi,
I already sent this to freebsd-fs at .
I'm making some experiments with 10.1-RC3 on alix boards as hardware
using NanoBSD.
By mounting and umounting UFS filesystems I have seen umount constantly
hanging hard in a deadlock. I have tested on two boards with two
distinct compactflash disks with same results. This was not happening
with 10.0-RELEASE.
I have build a 10.1-RC3 kernel with full debugging and caused the
problem to happen, I got this:
root at qtest:~ [0]# umount /cfg
panic: detach with active requests
KDB: stack backtrace:
db_trace_self_wrapper(c0968053,c08ea7f0,c2d48800,c23d6bc8,c0536a16,...)
at db_trace_self_wrapper+0x2d/frame 0xc23d6b98
kdb_backtrace(c09639e1,c09fa7e8,c095761d,c23d6c54,c095761d,...) at
kdb_backtrace+0x30/frame 0xc23d6c00
vpanic(c09fa682,100,c095761d,c23d6c54,c23d6c54,...) at vpanic+0x80/frame
0xc23d6c24
kassert_panic(c095761d,c09575b3,c2d7acc0,4c7,c2d7acc0,...) at
kassert_panic+0xe9/frame 0xc23d6c48
g_detach(c2d7acc0,4,c095725c,1c2,c09c8d5c,...) at g_detach+0x1d3/frame
0xc23d6c64
g_wither_washer(c09f7df4,0,c0956544,124,0,...) at
g_wither_washer+0x109/frame 0xc23d6c90
g_run_events(0,c23d6d08,c095d42a,3dc,0,...) at g_run_events+0x40/frame
0xc23d6ccc
fork_exit(c05c4e60,0,c23d6d08) at fork_exit+0x7f/frame 0xc23d6cf4
fork_trampoline() at fork_trampoline+0x8/frame 0xc23d6cf4
--- trap 0, eip = 0, esp = 0xc23d6d40, ebp = 0 ---
KDB: enter: panic
[ thread pid 12 tid 100006 ]
Stopped at kdb_enter+0x3d: movl $0,kdb_why
db>
The machine is sitting there, I am connected with serial console, anyone
willing to help me debug this further? I really know very little about
kernel debugging. If necessary I can also make myself available via IRC
or Jabber.
It looks like this has some similarities with what was reported here:
https://lists.freebsd.org/pipermail/freebsd-fs/2014-September/020035.html
I also tested with head (including r272130) and it does deadlock the same.
Maybe the slower media is exposing some problem which does not show up
with faster disks?
Thanks in advance!
--
Guido Falsi <madpilot at FreeBSD.org>
More information about the freebsd-stable
mailing list