Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Jun 2010 09:47:43 +0100
From:      Tom Evans <tevans.uk@googlemail.com>
To:        ben wilber <ben@desync.com>
Cc:        freebsd-current <freebsd-current@freebsd.org>, d@delphij.net
Subject:   Re: zfs panic
Message-ID:  <AANLkTil-uoCc8Pec3_4stUIYoFl9a0qpocTPAW76qGon@mail.gmail.com>
In-Reply-To: <20100623210133.GA10694@exodus.desync.com>
References:  <20100623164401.GA7914@exodus.desync.com> <4C2272E5.2090901@delphij.net> <20100623210133.GA10694@exodus.desync.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 23, 2010 at 10:01 PM, ben wilber <ben@desync.com> wrote:
> On Wed, Jun 23, 2010 at 01:47:33PM -0700, Xin LI wrote:
>> >
>> > panic: _sx_xlock_hard: recursed on non-recursive sx buf_hash_table.ht_=
locks[i].ht_lock @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/=
uts/c
>> > ommon/fs/zfs/arc.c:1626
>>
>> Any chance to obtain a backtrace for the panic?
>
> >From r209229:
>
> db:0:kdb.enter.default> =C2=A0bt
> Tracing pid 3233 tid 100396 td 0xffffff013600f000
> kdb_enter() at kdb_enter+0x3d
> panic() at panic+0x1c8
> _sx_xlock_hard() at _sx_xlock_hard+0x93
> _sx_xlock() at _sx_xlock+0xaa
> arc_buf_remove_ref() at arc_buf_remove_ref+0x7b
> dbuf_rele() at dbuf_rele+0x15d
> zfs_freebsd_reclaim() at zfs_freebsd_reclaim+0xe1
> VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xe8
> vgonel() at vgonel+0x186
> vnlru_free() at vnlru_free+0x2f4
> vfs_lowmem() at vfs_lowmem+0x31
> kmem_malloc() at kmem_malloc+0x12c
> page_alloc() at page_alloc+0x18
> keg_alloc_slab() at keg_alloc_slab+0xe6
> keg_fetch_slab() at keg_fetch_slab+0x18e
> zone_fetch_slab() at zone_fetch_slab+0x4f
> uma_zalloc_arg() at uma_zalloc_arg+0x56b
> arc_get_data_buf() at arc_get_data_buf+0xaa
> arc_read_nolock() at arc_read_nolock+0x1cb
> arc_read() at arc_read+0x71
> dbuf_read() at dbuf_read+0x4ea
> dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x119
> dmu_buf_hold_array() at dmu_buf_hold_array+0x57
> dmu_read_uio() at dmu_read_uio+0x3f
> zfs_freebsd_read() at zfs_freebsd_read+0x558
> VOP_READ_APV() at VOP_READ_APV+0xe2
> vn_read() at vn_read+0x1d0
> dofileread() at dofileread+0x97
> kern_preadv() at kern_preadv+0x6a
> pread() at pread+0x52
> syscallenter() at syscallenter+0x217
> syscall() at syscall+0x39
> Xfast_syscall() at Xfast_syscall+0xe1
> --- syscall (475, FreeBSD ELF64, pread), rip =3D 0x80100c14c, rsp =3D 0x7=
fffffbfeb48, rbp =3D 0x2 ---
>
> Thanks.

I notice the traceback is in the UMA zone allocaor. Did it used to be stabl=
e?
ZFS recently changed to using the UMA allocator, and I found this made
my system less reliable. Does disabling this help? Add this to
/boot/loader.conf:

vfs.zfs.zio.use_uma=3D0

Cheers

Tom



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTil-uoCc8Pec3_4stUIYoFl9a0qpocTPAW76qGon>