Giter Club home page Giter Club logo

spl's People

Contributors

bcantrill avatar behlendorf avatar bjokash avatar brendonhumphrey avatar cbreak-black avatar chrisrd avatar dajhorn avatar datacore-tlaurent avatar dechamps avatar dehacked avatar evansus avatar gunnarbeutner avatar ilovezfs avatar jengelh avatar jmovs avatar lundman avatar maxximino avatar nedbass avatar nkhare avatar prakashsurya avatar prat0088 avatar rottegift avatar ryao avatar wca avatar yshui avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

spl's Issues

spl printf's still cause _puts() missing symbol

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.

Panic in OSX10.11.6

my Rig:

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%

Panic :

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)

Create pool stops in txg_wait_synced

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.

"kernel heap corruption detected"@spl-kmem.c:880

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

Future allocator enhancements

Thoughts on some work to be done to the allocator as time arises:

  • Rename in such a way as to fit seamlessly into the SPL
  • Remove osif, code directly for in kernel use. The time for testing in user space will soon have passed
  • Replace the linked lists with use of the spl generic list if possible
  • Provide a specialised slice type with low space overhead for small allocations - this will lift the space efficiency overall.
  • Remove suspiciously C++ style type names.

Unresolved symbols while compiling

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'.

Panic in 10.12.1

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)

SPL: MMT it's been an hour since the last reap

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.

Install path for spl.kext hardcoded

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.

Compilation fails during 'make'

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?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.