Hi! On Mon, 8 Jun 2009 09:46:52 -0600, "Dunphy, Bill" wrote: > Greetings, > > I'm attempting to get NILFS up and running on a Marvell DB-88F6281-BP-A > (ARM) and have experienced a consistent hang during data transfer. This > target board is running a 2.6.22.18 kernel and I've tested it against > NILFS versions 2.0.12, 2.0.14 and the latest git pull (6/4/09). I've > eliminated the garbage collector and and have enabled full debugging for > log capture. The failure is not immediate or at a fixed point - > typically in the 1-2GB neighborhood of writing variably sized files. > This same exercise (a simple recursive local copy) works flawlessly on > my host Ubuntu i86 machine as well as on the target with an ext3 file > system. > > Is there a specific kernel feature that I might be missing and need to > enable? A kernel version sensitivity? Is this log information > something you would be interested in seeing? If so, how verbose would > you like it or better still, how would you like me to collect it?
Thanks for reporting. What will happen if you trigger SysRq when you meet the hang? # echo t > /proc/sysrq-trigger I don't know whether the arm kernel codes is supporting sysrq, but we may get the stack dump of the nilfs task hung at some lock. If it works, it would help us to narrow down the problem. Also, you can know the progress of segment writer by specifying the following debug options, # echo "-vvv segment -vv seginfo" > /proc/fs/nilfs2/debug_option This feature is only available on the nilfs2 out-of-tree module built with CONFIG_NILFS_DEBUG=y option. Could you try either of these? Thanks in advance, Ryusuke Konishi _______________________________________________ users mailing list [email protected] https://www.nilfs.org/mailman/listinfo/users
