On 2012-12-12 14:04, Volodymyr Kostyrko wrote: > 04.12.2012 00:41, Konstantin Belousov: >> Please try the patch below. It might give an immediate relief, but still >> there are many offenders in the backtrace. > > I'm having almost the same issue and the patch doesn't work for me. ... Looking at the stack frame addresses, it seems some of them are mangled. Did you type this by hand? The differences between subsequent frames are a bit strange because of it (and because of awk's integer processing): _mtx_lock_flags 40 uma_zalloc_arg 80 malloc 48 zfs_kmem_alloc 20 vdev_mirror_io_start 100 zio_vdev_io_start -2270966072 zio_execute 2270966192 spa_load_verify_cb 64 traverse_visitbp 304 traverse_dnode -2129031145 traverse_visitbp 2129031529 traverse_visitbp 805306672 traverse_visitbp -805306064 traverse_visitbp 304 traverse_visitbp 304 traverse_visitbp 304 traverse_visitbp 304 traverse_dnode 80 traverse_visitbp 304 traverse_impl 176 traverse_pool 160 spa_load 280 spa_load 280 spa_load_best -560 spa_open_common 740 spa_open 20 dsl_dir_open_spa 360 dsl_dataset_hold 124 dsl_dataset_own 28 dmu_objset_own 40 zfsvfs_create 80 zfs_mount 560 vfs_donmount 624 kernel_mount 64 parse_mount 280 vfs_mountroot 616 start_init 108 fork_exit 40 fork_trampoline 0 The kernel stack is just 8,192 bytes; since you can see these routines are all consuming massive amounts of stack, and the calls are very deeply nested, it is almost inevitable that it would crash. Especially the recursive spa_load and traverse_visitbp calls are scary, because that can grow out of hand very quickly. It is probably tricky to remove the recursion...Received on Wed Dec 12 2012 - 18:35:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:33 UTC