clang compiled kernel panic when mounting zfs root on i386
Dimitry Andric
dim at FreeBSD.org
Wed Dec 12 19:35:44 UTC 2012
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...
More information about the freebsd-current
mailing list