openzfsonosx / spl Goto Github PK
View Code? Open in Web Editor NEWSolaris Porting Layer for OpenZFS on OS X
Home Page: https://openzfsonosx.org/
License: Other
Solaris Porting Layer for OpenZFS on OS X
Home Page: https://openzfsonosx.org/
License: Other
What's your take on this?
Anonymous UUID: 46DA59B5-3F0A-217A-3DEA-DE9A80DC8B4F
Thu Nov 3 09:41:18 2016
*** Panic Report ***
panic(cpu 2 caller 0xffffff80003ed5fc): "Possible memory corruption: pmap_pv_remove(0xffffff8000a88f88,0xffffff9ca110b000,0x5f612c, 0x80000005f612c062, 0xfffffeb4e2cc4858): empty hash"@/Library/Caches/com.apple.xbs/Sources/xnu/xnu-3789.21.4/osfmk/i386/pmap_internal.h:844
Backtrace (CPU 2), Frame : Return Address
0xffffff97439cbb10 : 0xffffff80002f368c
0xffffff97439cbb90 : 0xffffff80003ed5fc
0xffffff97439cbc90 : 0xffffff80003edfca
0xffffff97439cbd00 : 0xffffff800037b0b8
0xffffff97439cbe40 : 0xffffff800037a9bc
0xffffff97439cbe70 : 0xffffff8000376523
0xffffff97439cbea0 : 0xffffff7f811e99a7
0xffffff97439cbec0 : 0xffffff7f811e6b9a
0xffffff97439cbf00 : 0xffffff7f811e25ee
0xffffff97439cbf30 : 0xffffff7f811eb5b5
0xffffff97439cbfb0 : 0xffffff80002a2af7
Kernel Extensions in backtrace:
net.lundman.spl(1.5.2)[F452C9FD-94A1-366D-BF2F-89BDDDA08364]@0xffffff7f811de000->0xffffff7f8121bfff
BSD process name corresponding to current thread: kernel_task
Boot args: -v slide=0 dart=0 darkwake=0
Mac OS version:
16B2657
Kernel version:
Darwin Kernel Version 16.1.0: Wed Oct 19 20:31:56 PDT 2016; root:xnu-3789.21.4~4/RELEASE_X86_64
Kernel UUID: 75CA1C4D-7BF4-321B-B544-D8F1B6D60EF8
__HIB text base: 0xffffff8000100000
System model name: iMac14,2 (Mac-27ADBB7B4CEE8E61)
System uptime in nanoseconds: 22146265828307
last loaded kext at 11233749707244: com.apple.filesystems.msdosfs 1.10 (addr 0xffffff7f838b2000, size 69632)
last unloaded kext at 13027166443534: com.parallels.kext.hypervisor 12.0.2 41353 (addr 0xffffff7f83845000, size 225280)
I'm compiling commit daaa4b4. I'm on OSX 10.9.2, Xcode 5.1.1, and have hit these unresolved symbols while making the project: (full log below)
For x86_64:
7 symbols not found in any library kext:
_kernel_memory_allocate
_kmem_free
_panicstr
_system_inshutdown
_vfs_context_current
_cache_purgevfs
_kernel_map
In addition, if I try to load the kext, I get this:
Loading ./kexts/spl.kext.
(kernel) kxld[net.lundman.spl]: The following symbols are unresolved for this kext:
(kernel) kxld[net.lundman.spl]: _kernel_memory_allocate
(kernel) kxld[net.lundman.spl]: _panicstr
(kernel) kxld[net.lundman.spl]: _system_inshutdown
(kernel) Can't load kext net.lundman.spl - link failed.
which seems related.
Full compile log:
$ make
/Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive
Making all in scripts
make[2]: Nothing to be done for `all'.
Making all in module
Making all in spl
Making all in KernelExports
depbase=`echo kextsymboltool.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
clang -DHAVE_CONFIG_H -include ../../../spl_config.h -Wall -Wshadow -Wstrict-prototypes -fno-strict-aliasing -g -O2 -MT kextsymboltool.o -MD -MP -MF $depbase.Tpo -c -o kextsymboltool.o kextsymboltool.c &&\
mv -f $depbase.Tpo $depbase.Po
/bin/sh ../../../libtool --tag=CC --silent --mode=link clang -Wall -Wshadow -Wstrict-prototypes -fno-strict-aliasing -g -O2 -lstdc++ -o kextsymboltool kextsymboltool.o
./kextsymboltool -arch x86_64 -import allsymbols -export zfs.exports -output KernelExports_64
./kextsymboltool -arch i386 -import allsymbols -export zfs.exports -output KernelExports_32
lipo -create KernelExports_32 KernelExports_64 -output KernelExports
clang -DHAVE_CONFIG_H -I. -I../.. -Wall -nostdinc -mkernel -fno-builtin-printf -D_KERNEL -DKERNEL -DKERNEL_PRIVATE -DDRIVER_PRIVATE -DAPPLE -DNeXT -I../../include -I/System/Library/Frameworks/Kernel.framework/Headers -I/System/Library/Frameworks/Kernel.framework/PrivateHeaders -g -O2 -MT spl-spl-condvar.o -MD -MP -MF .deps/spl-spl-condvar.Tpo -c -o spl-spl-condvar.o `test -f 'spl-condvar.c' || echo './'`spl-condvar.c
mv -f .deps/spl-spl-condvar.Tpo .deps/spl-spl-condvar.Po
clang -DHAVE_CONFIG_H -I. -I../.. -Wall -nostdinc -mkernel -fno-builtin-printf -D_KERNEL -DKERNEL -DKERNEL_PRIVATE -DDRIVER_PRIVATE -DAPPLE -DNeXT -I../../include -I/System/Library/Frameworks/Kernel.framework/Headers -I/System/Library/Frameworks/Kernel.framework/PrivateHeaders -g -O2 -MT spl-spl-kmem.o -MD -MP -MF .deps/spl-spl-kmem.Tpo -c -o spl-spl-kmem.o `test -f 'spl-kmem.c' || echo './'`spl-kmem.c
mv -f .deps/spl-spl-kmem.Tpo .deps/spl-spl-kmem.Po
clang -DHAVE_CONFIG_H -I. -I../.. -Wall -nostdinc -mkernel -fno-builtin-printf -D_KERNEL -DKERNEL -DKERNEL_PRIVATE -DDRIVER_PRIVATE -DAPPLE -DNeXT -I../../include -I/System/Library/Frameworks/Kernel.framework/Headers -I/System/Library/Frameworks/Kernel.framework/PrivateHeaders -g -O2 -MT spl-spl-thread.o -MD -MP -MF .deps/spl-spl-thread.Tpo -c -o spl-spl-thread.o `test -f 'spl-thread.c' || echo './'`spl-thread.c
mv -f .deps/spl-spl-thread.Tpo .deps/spl-spl-thread.Po
clang -DHAVE_CONFIG_H -I. -I../.. -Wall -nostdinc -mkernel -fno-builtin-printf -D_KERNEL -DKERNEL -DKERNEL_PRIVATE -DDRIVER_PRIVATE -DAPPLE -DNeXT -I../../include -I/System/Library/Frameworks/Kernel.framework/Headers -I/System/Library/Frameworks/Kernel.framework/PrivateHeaders -g -O2 -MT spl-spl-vnode.o -MD -MP -MF .deps/spl-spl-vnode.Tpo -c -o spl-spl-vnode.o `test -f 'spl-vnode.c' || echo './'`spl-vnode.c
spl-vnode.c:384:5: warning: implicit declaration of function 'cache_purgevfs' is invalid in C99 [-Wimplicit-function-declaration]
cache_purgevfs(mp);
^
1 warning generated.
mv -f .deps/spl-spl-vnode.Tpo .deps/spl-spl-vnode.Po
clang -DHAVE_CONFIG_H -I. -I../.. -Wall -nostdinc -mkernel -fno-builtin-printf -D_KERNEL -DKERNEL -DKERNEL_PRIVATE -DDRIVER_PRIVATE -DAPPLE -DNeXT -I../../include -I/System/Library/Frameworks/Kernel.framework/Headers -I/System/Library/Frameworks/Kernel.framework/PrivateHeaders -g -O2 -MT spl-spl-bmalloc.o -MD -MP -MF .deps/spl-spl-bmalloc.Tpo -c -o spl-spl-bmalloc.o `test -f 'spl-bmalloc.c' || echo './'`spl-bmalloc.c
mv -f .deps/spl-spl-bmalloc.Tpo .deps/spl-spl-bmalloc.Po
/bin/sh ../../libtool --tag=CC --mode=link clang -g -O2 -Xlinker -kext -nostdlib -lkmodc++ -lkmod -lcc_kext -o spl spl-spl-atomic.o spl-spl-condvar.o spl-spl-cred.o spl-spl-ddi.o spl-spl-err.o spl-spl-kmem.o spl-spl-kobj.o spl-spl-kstat.o spl-spl-list.o spl-spl-mutex.o spl-spl-osx.o spl-spl-proc.o spl-spl-rwlock.o spl-spl-taskq.o spl-spl-thread.o spl-spl-time.o spl-spl-vnode.o spl-spl-xdr.o spl-spl-bmalloc.o
libtool: link: clang -g -O2 -Wl,-kext -nostdlib -o spl spl-spl-atomic.o spl-spl-condvar.o spl-spl-cred.o spl-spl-ddi.o spl-spl-err.o spl-spl-kmem.o spl-spl-kobj.o spl-spl-kstat.o spl-spl-list.o spl-spl-mutex.o spl-spl-osx.o spl-spl-proc.o spl-spl-rwlock.o spl-spl-taskq.o spl-spl-thread.o spl-spl-time.o spl-spl-vnode.o spl-spl-xdr.o spl-spl-bmalloc.o -lkmodc++ -lkmod -lcc_kext
cp -f KernelExports/Info.plist spl.kext/Contents/PlugIns/KernelExports.kext/
cp -f KernelExports/version.plist spl.kext/Contents/PlugIns/KernelExports.kext/
mkdir -p KernelExports.kext/Contents/MacOS
cp -f KernelExports/KernelExports KernelExports.kext/Contents/MacOS/
cp -f KernelExports/Info.plist KernelExports.kext/Contents/
<key>OSBundleLibraries</key>
<dict>
<key>com.apple.kpi.bsd</key>
<string>13.1</string>
<key>com.apple.kpi.iokit</key>
<string>13.1</string>
<key>com.apple.kpi.libkern</key>
<string>13.1</string>
<key>com.apple.kpi.mach</key>
<string>13.1</string>
<key>net.lundman.kernel.dependencies</key>
<string>10.0</string>
</dict>
For x86_64:
7 symbols not found in any library kext:
_kernel_memory_allocate
_kmem_free
_panicstr
_system_inshutdown
_vfs_context_current
_cache_purgevfs
_kernel_map
Ignoring errors..
make[3]: Nothing to be done for `all-am'.
Making all in include
make[2]: Nothing to be done for `all'.
make[2]: Nothing to be done for `all-am'.
The target directory for installing the kext is hardcoded to /System/Library/Extensions in module/spl/Makefile.(am|in) . It should be configurable in configure, i.e. there should be a kind of "--sysprefix" which is prefixed to all target paths. The idea is to be able to install into a system root of a sstem X mounted elsewhere in system Y.
I tried to look into this, but I have honestly no clue how the autoconf / automake tools work.
Full log
I saw this error with Xcode 11, but now xcode-select is set to stable Xcode 10.3, but I was able to compile it this way before. Setting to Xcode 11 doesn't resolve this issue.
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer
ZFS 1.6.1 on
MacPro 4,1 (5,1 microcode)
Serial ATA Device: HL-DT-ST DVD-RW GH41N
Serial ATA Device: HL-DT-ST DVD-RW GH41N
Serial ATA Device: KINGSTON SKC300S37A240G, 240,06 GB
Serial ATA Device: ST4000VN008-2DR166, 4 TB
Serial ATA Device: ST3750528AS, 750,16 GB
Serial ATA Device: ST2000VN0001-1SF174, 2 TB
Serial ATA Device: ST4000VN008-2DR166, 4 TB
Serial ATA Device: ST4000VN008-2DR166, 4 TB
Serial ATA Device: MARVELL VIRTUALL
FireWire Device: built-in_hub, Up to 800 Mb/sec
FireWire Device: 2Big Quadra USB3, LaCie, Up to 800 Mb/sec
#diskutil list
(...)
/dev/disk1 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *4.0 TB disk1
1: ZFS Bay 4.0 TB disk1s1
2: 6A945A3B-1DD2-11B2-99A6-080020736631 8.4 MB disk1s9
(...)
/dev/disk5 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *4.0 TB disk5
1: ZFS Bay 4.0 TB disk5s1
2: 6A945A3B-1DD2-11B2-99A6-080020736631 8.4 MB disk5s9
/dev/disk6 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *4.0 TB disk6
1: ZFS Bay 4.0 TB disk6s1
2: 6A945A3B-1DD2-11B2-99A6-080020736631 8.4 MB disk6s9
/dev/disk7 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *4.0 TB disk7
1: ZFS Bay 4.0 TB disk7s1
2: 6A945A3B-1DD2-11B2-99A6-080020736631 8.4 MB disk7s9
/dev/disk8 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *16.0 TB disk8
1: ZFS LaCie 16.0 TB disk8s1
2: 6A945A3B-1DD2-11B2-99A6-080020736631 8.4 MB disk8s9
#zpool list -v
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
Bay 14,5T 8,25T 6,25T - 30% 56% 1.00x ONLINE -
raidz1 14,5T 8,25T 6,25T - 30% 56%
media-491D37F4-3E0B-0546-9F70-F280333CEEBF - - - - - -
media-FCBFF41B-8A47-E144-9580-C6FA25C1C5EB - - - - - -
media-449D7259-2A19-554F-A687-61586EEE3315 - - - - - -
media-CC987CBF-32F7-2F4C-B8EC-015DF07F04E9 - - - - - -
LaCie 14,5T 4,78T 9,72T - 22% 32% 1.00x ONLINE -
media-9FF995E9-9119-D347-BD9A-2E793ED849D4 14,5T 4,78T 9,72T - 22% 32%
Anonymous UUID: D6571C4C-AEDB-5206-0C3D-2024A488A16E
*** Panic Report ***
panic(cpu 4 caller 0xffffff80093cbe03): Kernel trap at 0xffffff7f89a8a32b, type 14=page fault, registers:
CR0: 0x000000008001003b, CR2: 0x0000000000000000, CR3: 0x000000000dd22000, CR4: 0x00000000000226e0
RAX: 0x0000000000000000, RBX: 0xffffff81fc3994b0, RCX: 0x0000000000000000, RDX: 0xffffff81fc3994d8
RSP: 0xffffff925bcebf40, RBP: 0xffffff925bcebfb0, RSI: 0x0000000000000021, RDI: 0xffffff81fc3994d8
R8: 0xffffff81f4ea0000, R9: 0xffffff8202210b78, R10: 0xffffff8202210b78, R11: 0x00002577b85785f5
R12: 0x0000000000000502, R13: 0xffffff8202210ee8, R14: 0xffffff81fc3994e8, R15: 0x0000257774706413
RFL: 0x0000000000010206, RIP: 0xffffff7f89a8a32b, CS: 0x0000000000000008, SS: 0x0000000000000000
Fault CR2: 0x0000000000000000, Error code: 0x0000000000000002, Fault CPU: 0x4, PL: 0
Backtrace (CPU 4), Frame : Return Address
0xffffff925bcebbd0 : 0xffffff80092d7b92
0xffffff925bcebc50 : 0xffffff80093cbe03
0xffffff925bcebe30 : 0xffffff80093e9ba3
0xffffff925bcebe50 : 0xffffff7f89a8a32b
0xffffff925bcebfb0 : 0xffffff80093c6537
Kernel Extensions in backtrace:
net.lundman.spl(1.6.1)[D59AEA5C-BB9B-3C36-9966-DE7F7C2D7A23]@0xffffff7f89a7c000->0xffffff7f8ac71fff
Mac OS version:
15G1421
Kernel version:
Darwin Kernel Version 15.6.0: Fri Feb 17 10:21:18 PST 2017; root:xnu-3248.60.11.4.1~1/RELEASE_X86_64
Kernel UUID: 9B4679AF-7EE6-3BCE-9DD7-C30975A80BB3
Kernel slide: 0x0000000009000000
Kernel text base: 0xffffff8009200000
__HIB text base: 0xffffff8009100000
System model name: MacPro5,1 (Mac-F221BEC8)
I have been noticing that my ZFS volume has become unresponsive somewhat and upon rebooting I received the following messages:
SPL: MMT it's been an hour since the last reap, vm_page_free_count == 12716231
SPL: reap thread, segkmem_total_mem_allocated delta 846462976 since 3596 seconds ago
I'm a little concerned because when I rebooted, I am still running into some hangs in the middle of copying some files. I'm using the most recent source from master at present.
Thoughts on some work to be done to the allocator as time arises:
My system crashed today with this error. Is it hardware or software related? What does it mean?
I'm running El Capitan. I compiled zfs and spl from source a while back.
Here follows the panic report:
Sun Jun 19 08:01:50 2016
*** Panic Report ***
panic(cpu 0 caller 0xffffff7fa02c03b5): "kernel heap corruption detected"@spl-kmem.c:880
Backtrace (CPU 0), Frame : Return Address
0xffffff9134d92d30 : 0xffffff801f4dab12 mach_kernel : _panic + 0xe2
0xffffff9134d92db0 : 0xffffff7fa02c03b5 Backtrace (CPU 0), Frame : Return Address
0xffffff9134d92590 : 0xffffff801f4db75d mach_kernel : _panic_display_hibb + 0x4bd
0xffffff9134d925c0 : 0xffffff801f4daa86 mach_kernel : _panic + 0x56
0xffffff9134d92640 : 0xffffff801f5ce5fa mach_kernel : _kernel_trap + 0x91a
0xffffff9134d92820 : 0xffffff801f5ec463 mach_kernel : _return_from_trap + 0xe3
0xffffff9134d92840 : 0xffffff801f5d4ae0 mach_kernel : _print_uuid_info + 0x710
0xffffff9134d92960 : 0xffffff801f5d4171 mach_kernel : _panic_print_symbol_name + 0x81
0xffffff9134d92990 : 0xffffff801f5d3c52 mach_kernel : _panic_i386_backtrace + 0x312
0xffffff9134d92cf0 : 0xffffff801f5d33db mach_kernel : _Debugger + 0xeb
0xffffff9134d92d30 : 0xffffff801f4dab12 mach_kernel : _panic + 0xe2
0xffffff9134d92db0 : 0xffffff7fa02c03b5 Backtrace (CPU 0), Frame : Return Address
0xffffff9134d91df0 : 0xffffff801f4db75d mach_kernel : _panic_display_hibb + 0x4bd
0xffffff9134d91e20 : 0xffffff801f4daa86 mach_kernel : _panic + 0x56
0xffffff9134d91ea0 : 0xffffff801f5ce5fa mach_kernel : _kernel_trap + 0x91a
0xffffff9134d92080 : 0xffffff801f5ec463 mach_kernel : _return_from_trap + 0xe3
0xffffff9134d920a0 : 0xffffff801f5d4ae0 mach_kernel : _print_uuid_info + 0x710
0xffffff9134d921c0 : 0xffffff801f5d4171 mach_kernel : _panic_print_symbol_name + 0x81
0xffffff9134d921f0 : 0xffffff801f5d3c52 mach_kernel : _panic_i386_backtrace + 0x312
0xffffff9134d92550 : 0xffffff801f5d33db mach_kernel : _Debugger + 0xeb
0xffffff9134d92590 : 0xffffff801f4db75d mach_kernel : _panic_display_hibb + 0x4bd
0xffffff9134d925c0 : 0xffffff801f4daa86 mach_kernel : _panic + 0x56
0xffffff9134d92640 : 0xffffff801f5ce5fa mach_kernel : _kernel_trap + 0x91a
0xffffff9134d92820 : 0xffffff801f5ec463 mach_kernel : _return_from_trap + 0xe3
0xffffff9134d92840 : 0xffffff801f5d4ae0 mach_kernel : _print_uuid_info + 0x710
0xffffff9134d92960 : 0xffffff801f5d4171 mach_kernel : _panic_print_symbol_name + 0x81
0xffffff9134d92990 : 0xffffff801f5d3c52 mach_kernel : _panic_i386_backtrace + 0x312
0xffffff9134d92cf0 : 0xffffff801f5d33db mach_kernel : _Debugger + 0xeb
0xffffff9134d92d30 : 0xffffff801f4dab12 mach_kernel : _panic + 0xe2
0xffffff9134d92db0 : 0xffffff7fa02c03b5 Backtrace (CPU 0), Frame : Return Address
0xffffff9134d91650 : 0xffffff801f4db75d mach_kernel : _panic_display_hibb + 0x4bd
0xffffff9134d91680 : 0xffffff801f4daa86 mach_kernel : _panic + 0x56
0xffffff9134d91700 : 0xffffff801f5ce5fa mach_kernel : _kernel_trap + 0x91a
0xffffff9134d918e0 : 0xffffff801f5ec463 mach_kernel : _return_from_trap + 0xe3
0xffffff9134d91900 : 0xffffff801f5d4ae0 mach_kernel : _print_uuid_info + 0x710
0xffffff9134d91a20 : 0xffffff801f5d4171 mach_kernel : _panic_print_symbol_name + 0x81
0xffffff9134d91a50 : 0xffffff801f5d3c52 mach_kernel : _panic_i386_backtrace + 0x312
0xffffff9134d91db0 : 0xffffff801f5d33db mach_kernel : _Debugger + 0xeb
0xffffff9134d91df0 : 0xffffff801f4db75d mach_kernel : _panic_display_hibb + 0x4bd
0xffffff9134d91e20 : 0xffffff801f4daa86 mach_kernel : _panic + 0x56
0xffffff9134d91ea0 : 0xffffff801f5ce5fa mach_kernel : _kernel_trap + 0x91a
0xffffff9134d92080 : 0xffffff801f5ec463 mach_kernel : _return_from_trap + 0xe3
0xffffff9134d920a0 : 0xffffff801f5d4ae0 mach_kernel : _print_uuid_info + 0x710
0xffffff9134d921c0 : 0xffffff801f5d4171 mach_kernel : _panic_print_symbol_name + 0x81
0xffffff9134d921f0 : 0xffffff801f5d3c52 mach_kernel : _panic_i386_backtrace + 0x312
0xffffff9134d92550 : 0xffffff801f5d33db mach_kernel : _Debugger + 0xeb
0xffffff9134d92590 : 0xffffff801f4db75d mach_kernel : _panic_display_hibb + 0x4bd
0xffffff9134d925c0 : 0xffffff801f4daa86 mach_kernel : _panic + 0x56
0xffffff9134d92640 : 0xffffff801f5ce5fa mach_kernel : _kernel_trap + 0x91a
0xffffff9134d92820 : 0xffffff801f5ec463 mach_kernel : _return_from_trap + 0xe3
0xffffff9134d92840 : 0xffffff801f5d4ae0 mach_kernel : _print_uuid_info + 0x710
0xffffff9134d92960 : 0xffffff801f5d4171 mach_kernel : _panic_print_symbol_name + 0x81
0xffffff9134d92990 : 0xffffff801f5d3c52 mach_kernel : _panic_i386_backtrace + 0x312
0xffffff9134d92cf0 : 0xffffff801f5d33db mach_kernel : _Debugger + 0xeb
0xffffff9134d92d30 : 0xffffff801f4dab12 mach_kernel : _panic + 0xe2
0xffffff9134d92db0 : 0xffffff7fa02c03b5 Backtrace (CPU 0), Frame : Return Address
0xffffff9134d90eb0 : 0xffffff801f4db75d mach_kernel : _panic_display_hibb + 0x4bd
0xffffff9134d90ee0 : 0xffffff801f4daa86 mach_kernel : _panic + 0x56
0xffffff9134d90f60 : 0xffffff801f5ce5fa mach_kernel : _kernel_trap + 0x91a
0xffffff9134d91140 : 0xffffff801f5ec463 mach_kernel : _return_from_trap + 0xe3
0xffffff9134d91160 : 0xffffff801f5d4ae0 mach_kernel : _print_uuid_info + 0x710
0xffffff9134d91280 : 0xffffff801f5d4171 mach_kernel : _panic_print_symbol_name + 0x81
0xffffff9134d912b0 : 0xffffff801f5d3c52 mach_kernel : _panic_i386_backtrace + 0x312
0xffffff9134d91610 : 0xffffff801f5d33db mach_kernel : _Debugger + 0xeb
0xffffff9134d91650 : 0xffffff801f4db75d mach_kernel : _panic_display_hibb + 0x4bd
0xffffff9134d91680 : 0xffffff801f4daa86 mach_kernel : _panic + 0x56
0xffffff9134d91700 : 0xffffff801f5ce5fa mach_kernel : _kernel_trap + 0x91a
0xffffff9134d918e0 : 0xffffff801f5ec463 mach_kernel : _return_from_trap + 0xe3
0xffffff9134d91900 : 0xffffff801f5d4ae0 mach_kernel : _print_uuid_info + 0x710
0xffffff9134d91a20 : 0xffffff801f5d4171 mach_kernel : _panic_print_symbol_name + 0x81
0xffffff9134d91a50 : 0xffffff801f5d3c52 mach_kernel : _panic_i386_backtrace + 0x312
0xffffff9134d91db0 : 0xffffff801f5d33db mach_kernel : _Debugger + 0xeb
0xffffff9134d91df0 : 0xffffff801f4db75d mach_kernel : _panic_display_hibb + 0x4bd
0xffffff9134d91e20 : 0xffffff801f4daa86 mach_kernel : _panic + 0x56
0xffffff9134d91ea0 : 0xffffff801f5ce5fa mach_kernel : _kernel_trap + 0x91a
0xffffff9134d92080 : 0xffffff801f5ec463 mach_kernel : _return_from_trap + 0xe3
0xffffff9134d920a0 : 0xffffff801f5d4ae0 mach_kernel : _print_uuid_info + 0x710
0xffffff9134d921c0 : 0xffffff801f5d4171 mach_kernel : _panic_print_symbol_name + 0x81
0xffffff9134d921f0 : 0xffffff801f5d3c52 mach_kernel : _panic_i386_backtrace + 0x312
0xffffff9134d92550 : 0xffffff801f5d33db mach_kernel : _Debugger + 0xeb
0xffffff9134d92590 : 0xffffff801f4db75d mach_kernel : _panic_display_hibb + 0x4bd
0xffffff9134d925c0 : 0xffffff801f4daa86 mach_kernel : _panic + 0x56
0xffffff9134d92640 : 0xffffff801f5ce5fa mach_kernel : _kernel_trap + 0x91a
0xffffff9134d92820 : 0xffffff801f5ec463 mach_kernel : _return_from_trap + 0xe3
0xffffff9134d92840 : 0xffffff801f5d4ae0 mach_kernel : _print_uuid_info + 0x710
0xffffff9134d92960 : 0xffffff801f5d4171 mach_kernel : _panic_print_symbol_name + 0x81
0xffffff9134d92990 : 0xffffff801f5d3c52 mach_kernel : _panic_i386_backtrace + 0x312
0xffffff9134d92cf0 : 0xffffff801f5d33db mach_kernel : _Debugger + 0xeb
0xffffff9134d92d30 : 0xffffff801f4dab12 mach_kernel : _panic + 0xe2
0xffffff9134d92db0 : 0xffffff7fa02c03b5 Backtrace (CPU 0), Frame : Return Address
0xffffff9134d90710 : 0xffffff801f4db75d mach_kernel : _panic_display_hibb + 0x4bd
0xffffff9134d90740 : 0xffffff801f4daa86 mach_kernel : _panic + 0x56
0xffffff9134d907c0 : 0xffffff801f5ce5fa mach_kernel : _kernel_trap + 0x91a
0xffffff9134d909a0 : 0xffffff801f5ec463 mach_kernel : _return_from_trap + 0xe3
0xffffff9134d909c0 : 0xffffff801f5d4ae0 mach_kernel : _print_uuid_info + 0x710
0xffffff9134d90ae0 : 0xffffff801f5d4171 mach_kernel : _panic_print_symbol_name + 0x81
0xffffff9134d90b10 : 0xffffff801f5d3c52 mach_kernel : _panic_i386_backtrace + 0x312
0xffffff9134d90e70 : 0xffffff801f5d33db mach_kernel : _Debugger + 0xeb
0xffffff9134d90eb0 : 0xffffff801f4db75d mach_kernel : _panic_display_hibb + 0x4bd
0xffffff9134d90ee0 : 0xffffff801f4daa86 mach_kernel : _panic + 0x56
0xffffff9134d90f60 : 0xffffff801f5ce5fa mach_kernel : _kernel_trap + 0x91a
0xffffff9134d91140 : 0xffffff801f5ec463 mach_kernel : _return_from_trap + 0xe3
0xffffff9134d91160 : 0xffffff801f5d4ae0 mach_kernel : _print_uuid_info + 0x710
0xffffff9134d91280 : 0xffffff801f5d4171 mach_kernel : _panic_print_symbol_name + 0x81
0xffffff9134d912b0 : 0xffffff801f5d3c52 mach_kernel : _panic_i386_backtrace + 0x312
0xffffff9134d91610 : 0xffffff801f5d33db mach_kernel : _Debugger + 0xeb
0xffffff9134d91650 : 0xffffff801f4db75d mach_kernel : _panic_display_hibb + 0x4bd
0xffffff9134d91680 : 0xffffff801f4daa86 mach_kernel : _panic + 0x56
0xffffff9134d91700 : 0xffffff801f5ce5fa mach_kernel : _kernel_trap + 0x91a
0xffffff9134d918e0 : 0xffffff801f5ec463 mach_kernel : _return_from_trap + 0xe3
0xffffff9134d91900 : 0xffffff801f5d4ae0 mach_kernel : _print_uuid_info + 0x710
0xffffff9134d91a20 : 0xff
a pull request in a couple min,
then a pull request to make the zfs side compile and work
Rather than impact master I thought the best approach would be to maintain my own branch from which I can pull from master and cherry pick back to master so I don't annoy Guru's at work.
Issuing a simple
# zpool create -f BOOM pool-image.bin
We eventually end up in spa_create()
dmu_tx_commit(tx);
spa->spa_sync_on = B_TRUE;
txg_sync_start(spa->spa_dsl_pool);
/*
* We explicitly wait for the first transaction to complete so that our
* bean counters are appropriately updated.
*/
txg_wait_synced(spa->spa_dsl_pool, txg);
But unfortunately, we never come back from txg_wait_synced
.
Log output
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: +spa_create
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] vnode_open('/Users/lundman/poo
l-image.bin')
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] read 8192 bytes (0)
Mar 6 21:32:49 --- last message repeated 2 times ---
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] wrote 8192 bytes (0)
Mar 6 21:32:49 --- last message repeated 2 times ---
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] read 114688 bytes (0)
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] wrote 114688 bytes (0)
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] wrote 8192 bytes (0)
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] wrote 131072 bytes (0)
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] wrote 114688 bytes (0)
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] wrote 8192 bytes (0)
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] wrote 131072 bytes (0)
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] wrote 114688 bytes (0)
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] wrote 8192 bytes (0)
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] wrote 131072 bytes (0)
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] wrote 114688 bytes (0)
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] wrote 8192 bytes (0)
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [spl] wrote 131072 bytes (0)
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: pool 0xffffff8006537400
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: txg=4 quiesce_txg=0 sync_txg=4
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: broadcasting sync more tx_synced=0 w
aiting=4 dp=0xffffff8006537400
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [zio] sync thread running
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [tgx] waiting on thread 0xffffff8006
53766c: time 0
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: txg=4 quiesce_txg=5 sync_txg=4
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: quiesce done, handing off txg 4
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [tgx] waiting on thread 0xffffff8006537668: time 0
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [tgx] finished waiting on thread 0xffffff800653766c
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: txg=4 quiesce_txg=5 sync_txg=4
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [tgx] finished waiting on thread 0xffffff8006537668
Mar 6 21:32:48 lundmans-Mac-Pro kernel[0]: [tgx] waiting on thread 0xffffff8006537668: time 0
Looking at zio.c
it is fairly busy as well, creating zios and running through them. Actual IO to the image file happens, so we are creating a pool.
Eventually, zio_done()
get called a final time but bail out here;
if (zio_wait_for_children(zio, ZIO_CHILD_VDEV, ZIO_WAIT_DONE) ||
zio_wait_for_children(zio, ZIO_CHILD_GANG, ZIO_WAIT_DONE) ||
zio_wait_for_children(zio, ZIO_CHILD_DDT, ZIO_WAIT_DONE) ||
zio_wait_for_children(zio, ZIO_CHILD_LOGICAL, ZIO_WAIT_DONE))
return (ZIO_PIPELINE_STOP);
because ZIO_CHILD_LOGICAL
is still true. It is my guess that because this logical task is never "complete" the system fails to return.
It is also stuck in a busy loop at this point, the loadavg hits about 6, and 99% in sys.
Commenting out txg_wait_synced()
makes "zpool create" complete and return to the shell, but any command run will eventually call txg and hang.
During compilation, I get the following error:
llvm-gcc -DHAVE_CONFIG_H -include ../../spl_config.h -Wall -Wshadow -Wstrict-prototypes -fno-strict-aliasing -Wall -nostdinc -mkernel -fno-builtin-printf -D_KERNEL -DKERNEL -DKERNEL_PRIVATE -DDRIVER_PRIVATE -DAPPLE -DNeXT -I../../include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Kernel.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Kernel.framework/PrivateHeaders -Wall -Wshadow -Wstrict-prototypes -fno-strict-aliasing -MT spl-spl-osx.o -MD -MP -MF .deps/spl-spl-osx.Tpo -c -o spl-spl-osx.o test -f 'spl-osx.c' || echo './'
spl-osx.c
spl-osx.c:318:27: warning: implicit declaration of function 'stac' is invalid in C99 [-Wimplicit-function-declaration]
if (spl_cpufeature_smap) stac();
^
spl-osx.c:328:27: warning: implicit declaration of function 'clac' is invalid in C99 [-Wimplicit-function-declaration]
if (spl_cpufeature_smap) clac();
^
spl-osx.c:382:18: error: use of undeclared identifier 'CR4_SMAP'
if (get_cr4() & CR4_SMAP)
^
2 warnings and 1 error generated.
make[4]: *** [spl-spl-osx.o] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Any ideas as to what it is I am missing?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.