Occasional panics with 2.1.0 on macOS 10.14.6

All your general support questions for OpenZFS on OS X.

Occasional panics with 2.1.0 on macOS 10.14.6

Postby al3x » Sun Sep 26, 2021 4:42 pm

Hi,

After upgrading from 1.9.4, I've been seeing occasional kernel panics. This is on macOS 10.14.6 with two single-drive pools - one with a Hitachi HUA721010KLA330 (1TB, encryption enabled) and one with a WDC WD120EMFZ-11A6JA0 (12TB, no encryption):

Code: Select all
Anonymous UUID:       CC2A3763-7885-CFEB-E89A-2FEF1E46AC37

Sat Sep 25 12:12:35 2021

*** Panic Report ***
panic(cpu 3 caller 0xffffff7fa1e1146e): timed out waiting for child callback, inchild: 1
Backtrace (CPU 3), Frame : Return Address
0xffffff9230241a20 : 0xffffff8020bad5cd mach_kernel : _handle_debugger_trap + 0x47d
0xffffff9230241a70 : 0xffffff8020ce9245 mach_kernel : _kdp_i386_trap + 0x155
0xffffff9230241ab0 : 0xffffff8020cda97a mach_kernel : _kernel_trap + 0x50a
0xffffff9230241b20 : 0xffffff8020b5a9d0 mach_kernel : _return_from_trap + 0xe0
0xffffff9230241b40 : 0xffffff8020bacfe7 mach_kernel : _panic_trap_to_debugger + 0x197
0xffffff9230241c60 : 0xffffff8020bace33 mach_kernel : _panic + 0x63
0xffffff9230241cd0 : 0xffffff7fa1e1146e org.openzfsonosx.zfs : _vmem_alloc_in_worker_thread + 0x25e
0xffffff9230241da0 : 0xffffff7fa1e10e8c org.openzfsonosx.zfs : _vmem_alloc + 0xcc
0xffffff9230241de0 : 0xffffff7fa1e0f9d5 org.openzfsonosx.zfs : _vmem_xalloc + 0xc15
0xffffff9230242050 : 0xffffff7fa1e11165 org.openzfsonosx.zfs : _wrapped_vmem_alloc + 0x2a5
0xffffff92302420e0 : 0xffffff7fa1e10ea5 org.openzfsonosx.zfs : _vmem_alloc + 0xe5
0xffffff9230242120 : 0xffffff7fa1dfef9f org.openzfsonosx.zfs : _kmem_slab_create + 0xaf
0xffffff92302421c0 : 0xffffff7fa1df7940 org.openzfsonosx.zfs : _kmem_slab_alloc + 0x70
0xffffff9230242200 : 0xffffff7fa1df7133 org.openzfsonosx.zfs : _kmem_cache_alloc + 0x393
0xffffff92302422b0 : 0xffffff7fa1e10f2f org.openzfsonosx.zfs : _wrapped_vmem_alloc + 0x6f
0xffffff9230242340 : 0xffffff7fa1e10ea5 org.openzfsonosx.zfs : _vmem_alloc + 0xe5
0xffffff9230242380 : 0xffffff7fa1e0f9d5 org.openzfsonosx.zfs : _vmem_xalloc + 0xc15
0xffffff92302425f0 : 0xffffff7fa1e11165 org.openzfsonosx.zfs : _wrapped_vmem_alloc + 0x2a5
0xffffff9230242680 : 0xffffff7fa1e10ea5 org.openzfsonosx.zfs : _vmem_alloc + 0xe5
0xffffff92302426c0 : 0xffffff7fa1dfef9f org.openzfsonosx.zfs : _kmem_slab_create + 0xaf
0xffffff9230242760 : 0xffffff7fa1df7940 org.openzfsonosx.zfs : _kmem_slab_alloc + 0x70
0xffffff92302427a0 : 0xffffff7fa1df7133 org.openzfsonosx.zfs : _kmem_cache_alloc + 0x393
0xffffff9230242850 : 0xffffff7fa1ae869c org.openzfsonosx.zfs : _dnode_create + 0x2c
0xffffff9230242890 : 0xffffff7fa1ae91e2 org.openzfsonosx.zfs : _dnode_hold_impl + 0x962
0xffffff9230242b40 : 0xffffff7fa1ae9d16 org.openzfsonosx.zfs : _dnode_hold + 0x36
0xffffff9230242b70 : 0xffffff7fa1abb9e0 org.openzfsonosx.zfs : _dmu_bonus_hold + 0x30
0xffffff9230242bc0 : 0xffffff7fa1b5723d org.openzfsonosx.zfs : _sa_buf_hold + 0x2d
0xffffff9230242bf0 : 0xffffff7fa1c47409 org.openzfsonosx.zfs : _zfs_zget_ext + 0x99
0xffffff9230242cb0 : 0xffffff7fa1c47367 org.openzfsonosx.zfs : _zfs_zget + 0x27
0xffffff9230242ce0 : 0xffffff7fa1bf1c27 org.openzfsonosx.zfs : _zfs_dirent_lock + 0x5e7
0xffffff9230242d90 : 0xffffff7fa1bf43bd org.openzfsonosx.zfs : _zfs_get_xattrdir + 0x7d
0xffffff9230242fa0 : 0xffffff7fa1c24494 org.openzfsonosx.zfs : _zfs_lookup + 0x154
0xffffff9230243010 : 0xffffff7fa1c4298b org.openzfsonosx.zfs : _zpl_xattr_get_dir + 0x6b
0xffffff9230243080 : 0xffffff7fa1c419b3 org.openzfsonosx.zfs : ___zpl_xattr_get + 0x93
0xffffff92302430d0 : 0xffffff7fa1c418d6 org.openzfsonosx.zfs : _zpl_xattr_get + 0x106
0xffffff9230243120 : 0xffffff7fa1c37f74 org.openzfsonosx.zfs : _zfs_vnop_getxattr + 0x314
0xffffff92302432c0 : 0xffffff8020e218e4 mach_kernel : _vn_getxattr + 0x424
0xffffff92302433e0 : 0xffffff8020dd3163 mach_kernel : _vfs_attr_pack + 0x1933
0xffffff92302436d0 : 0xffffff8020dd5e54 mach_kernel : _fgetattrlist + 0x8a4
0xffffff9230243cd0 : 0xffffff8020dd8702 mach_kernel : _getattrlist + 0x1a2
0xffffff9230243ee0 : 0xffffff8020dd85d0 mach_kernel : _getattrlist + 0x70
0xffffff9230243f40 : 0xffffff80211b847d mach_kernel : _unix_syscall64 + 0x27d
0xffffff9230243fa0 : 0xffffff8020b5b196 mach_kernel : _hndl_unix_scall64 + 0x16
      Kernel Extensions in backtrace:
         org.openzfsonosx.zfs(2.1)[26083354-1748-3F60-8513-8FEE5533AC8B]@0xffffff7fa1a80000->0xffffff7fa335efff
            dependency: com.apple.iokit.IOStorageFamily(2.1)[E28FB7B6-F78E-340D-91AC-7B78EC5F7D8D]@0xffffff7fa1a50000

BSD process name corresponding to current thread: bzfilelist
Boot args: keepsyms=1 serverperfmode=1 vm_compressor=2 -wegnoegpu

Mac OS version:
18G9323

Kernel version:
Darwin Kernel Version 18.7.0: Tue Jun 22 19:37:08 PDT 2021; root:xnu-4903.278.70~1/RELEASE_X86_64
Kernel UUID: 041B6A6D-CD16-36FA-88B9-E32FF46EF89F
Kernel slide:     0x0000000020800000
Kernel text base: 0xffffff8020a00000
__HIB  text base: 0xffffff8020900000
System model name: iMac13,2 (Mac-FC02E91DDD3FA6A4)

System uptime in nanoseconds: 244175331746431

EOF


This has occurred with some background I/O load (Transmission, SyncThing, Backblaze, etc), but nothing too heavy. Please let me know if there's any additional troubleshooting that I should do.
al3x
 
Posts: 1
Joined: Sun Sep 26, 2021 4:22 pm

Re: Occasional panics with 2.1.0 on macOS 10.14.6

Postby lundman » Mon Oct 04, 2021 7:54 pm

Ah hmm probably related to the new thread_callout function to avoid stack overflow.
User avatar
lundman
 
Posts: 1335
Joined: Thu Mar 06, 2014 2:05 pm
Location: Tokyo, Japan


Return to General Help

Who is online

Users browsing this forum: Google [Bot] and 30 guests