zfs crash on FreeBSD 10.3

[Julian Elischer]

On 14/10/2016 6:31 PM, Trond Endrestøl wrote:
> On Fri, 14 Oct 2016 00:19-0700, Julian Elischer wrote:
>
>> I attempted to add a second partition to an existing FS pool in FreeBSD 10.3
>> and the result was a crash..
>>
>> is there anyone out there with a scratch system (10.3) (or two spare drives)
>> who can show me this working?
>>
>> Does it look familiar to anyone?
>>
>> The drive 'boot0' is being used as the root drive, but we are in single user
>> mode, so its' read-only at this stage.
>>
>> =============== cut-n-paste =============
>>
>> [boot -s]
>>
>> [...]
>>
>> Trying to mount root from zfs:p8/image1 []...
>> Enter full pathname of shell or RETURN for /bin/sh:
>> PS1="# "
>> #
>> #
>> # ls /dev/gpt
>> boot0    boot1
>> # zpool attach -f p8 gpt/boot0 gpt/boot1
> Do you really need to force zpool to attach the second partition?
> What happens if you omit the -f flag?
from memory, it does nothing
I can't test it now but I know the example I saw on the internet gave 
'-f , and when I tried to leave it out,
it didn't work. I vaguely remember that it complained about the 
filesystem being in use.

I will try it again some time when I have the setup running and get 
back to you.
>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 1; apic id = 01
>> fault virtual address    = 0x50
>> fault code        = supervisor read data, page not present
>> instruction pointer    = 0x20:0xffffffff81717063
>> stack pointer            = 0x28:0xfffffe0169bfc640
>> frame pointer            = 0x28:0xfffffe0169bfc9a0
>> code segment        = base 0x0, limit 0xfffff, type 0x1b
>>              = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags    = interrupt enabled, resume, IOPL = 0
>> current process        = 3 (txg_thread_enter)
>> trap number        = 12
>> Panic:Thought about setting the watchdog to 10 Minutes
>> panic: page fault
>> cpuid = 1
>>
>> KDB: stack backtrace:
>>   stack1 db_trace_self_wrapper+0x2a
>>   kdb_backtrace+0x37 vpanic+0xf7
>>   panic+0x67 trap_fatal+0x264
>>   trap_pfault+0x1c2
>>   trap+0x38c
>>   calltrap+0x8
>>   dsl_scan_sync+0x2f3
>>   spa_sync+0x328
>>   txg_sync_thread+0x140
>>   fork_exit+0x135
>>   fork_trampoline+0xe
>>
>> KDB: enter: panic
>> [ thread pid 3 tid 100328 ]
>> Stopped at      kdb_enter+0x50: movq    $0,0x6bd5cd(%rip)
>> db> reboot
>>
>> I will add that after this, every boot hits this problem. (same stack trace).
>> the box is effectively bricked
>> (or would be if it weren't just a bhyve image)