Re: FreeBSD panics possibly caused by nfs clients

[Matthew L. Dailey]

Posting a few updates on this issue.

I was able to induce a panic on a CURRENT kernel (20240215), built with 
GENERIC-KASAN and running kern.kstack_pages=6 (default) after ~189 
hours. The panic message and backtrace are below - please reach out 
directly if you'd like to have a look at the core. I'm specifically not 
increasing kstack_pages to see what effect this has on the panics.

I have another system running CURRENT (20240215) without any debugging. 
I'm able to regularly panic this (7 panics over two weeks with average 
uptime of ~42 hours) with kstack_pages=4. I set kstack_pages=6, and have 
also induced several panics. Oddly, this seems to happen more quickly (4 
panics over 2 days with average uptime of ~10.5 hours).

Another system running CURRENT (20240208), built with GENERIC-KASAN and 
running kern.kstack_pages=8 has now been running with our hdf5 workload 
non-stop since February 10th with no panics or issues.

 From all this, it seems like increasing kstack_pages to 8 eliminates 
the panics, but obviously doesn't fix the underlying cause of the 
issues. So, although this is an obvious workaround for our production 
system, it would be better to find and fix the underlying cause of the 
panics.

I'm going to continue testing to try to generate more cores with 
kstack_pages<8 on the system with the debug kernel.

Any other ideas to try to narrow down the cause are welcome.

Thanks,
Matt

[680940] Kernel page fault with the following non-sleepable locks held:
[680940] exclusive sleep mutex nfs_state_mutex (nfs_state_mutex) r = 0 
(0x830498e0) locked @ /usr/src/sys/fs/nfsserver/nfs_nfsdstate.c:6652
[680940] stack backtrace:
[680940] #0 0x8127958f at witness_debugger+0x13f
[680940] #1 0x8127b114 at witness_warn+0x674
[680940] #2 0x81aba0a6 at trap_pfault+0x116
[680940] #3 0x81ab901c at trap+0x54c
[680940] #4 0x81a75988 at calltrap+0x8
[680940] #5 0x80fb4bfa at nfsrv_freestateid+0x23a
[680940] #6 0x80fd5e3f at nfsrvd_freestateid+0x1df
[680940] #7 0x80f98d35 at nfsrvd_dorpc+0x2585
[680940] #8 0x80fbf588 at nfssvc_program+0x1078
[680940] #9 0x8173fce6 at svc_run_internal+0x1706
[680940] #10 0x8174094b at svc_thread_start+0xb
[680940] #11 0x811137a3 at fork_exit+0xa3
[680940] #12 0x81a769ee at fork_trampoline+0xe
[680940]
[680940]
[680940] Fatal trap 12: page fault while in kernel mode
[680940] cpuid = 3; apic id = 06
[680940] fault virtual address  = 0x7
[680940] fault code = supervisor read data, page not present
[680940] instruction pointer= 0x20:0x80fafd67
[680940] stack pointer  = 0x28:0xfe0153ba2de0
[680940] frame pointer  = 0x28:0xfe0153ba2eb0
[680940] code segment   = base 0x0, limit 0xf, type 0x1b
[680940]= DPL 0, pres 1, long 1, def32 0, gran 1
[680940] processor eflags   = interrupt enabled, resume, IOPL = 0
[680940] current process= 55202 (nfsd: service)
[680940] rdi: 0007 rsi:  rdx: d7c0
[680940] rcx: fe001b9ec1e8  r8: 0012c4350002  r9: 0012c4350002
[680940] rax: fe001b9ec1e8 rbx:  rbp: fe0153ba2eb0
[680940] r10: 0004 r11: 0006 r12: 0007
[680940] r13: fe019cd75700 r14: 1a1a r15: fe019cd75708
[680940] trap number= 12
[680940] panic: page fault
[680940] cpuid = 3
[680940] time = 1709646178
[680940] KDB: stack backtrace:
[680940] db_trace_self_wrapper() at db_trace_self_wrapper+0xa5/frame 
0xfe0153ba2550
[680940] kdb_backtrace() at kdb_backtrace+0xc6/frame 0xfe0153ba26b0
[680940] vpanic() at vpanic+0x210/frame 0xfe0153ba2850
[680940] panic() at panic+0xb5/frame 0xfe0153ba2910
[680940] trap_fatal() at trap_fatal+0x65b/frame 0xfe0153ba2a10
[680940] trap_pfault() at trap_pfault+0x12b/frame 0xfe0153ba2b30
[680940] trap() at trap+0x54c/frame 0xfe0153ba2d10
[680940] calltrap() at calltrap+0x8/frame 0xfe0153ba2d10
[680940] --- trap 0xc, rip = 0x80fafd67, rsp = 
0xfe0153ba2de0, rbp = 0xfe0153ba2eb0 ---
[680940] nfsrv_freelockowner() at nfsrv_freelockowner+0x97/frame 
0xfe0153ba2eb0
[680940] nfsrv_freestateid() at nfsrv_freestateid+0x23a/frame 
0xfe0153ba2f70
[680940] nfsrvd_freestateid() at nfsrvd_freestateid+0x1df/frame 
0xfe0153ba3030
[680940] nfsrvd_dorpc() at nfsrvd_dorpc+0x2585/frame 0xfe0153ba3570
[680940] nfssvc_program() at nfssvc_program+0x1078/frame 0xfe0153ba3970
[680940] svc_run_internal() at svc_run_internal+0x1706/frame 
0xfe0153ba3ee0
[680940] svc_thread_start() at svc_thread_start+0xb/frame 0xfe0153ba3ef0
[680940] fork_exit() at fork_exit+0xa3/frame 0xfe0153ba3f30
[680940] fork_trampoline() at fork_trampoline+0xe/frame 0xfe0153ba3f30
[680940] --- trap 0xc, rip = 0x3b4ff896f0da, rsp = 0x3b4ff6a500e8, rbp = 
0x3b4ff6a50380 ---
[680940] KDB: 

Re: FreeBSD panics possibly caused by nfs clients

[Matthew L. Dailey]

Hi all,

I induced a panic on my CURRENT (20240215-d79b6b8ec267-268300) VM after 
about 24 hours. This is the one without any debugging, so it only 
confirms the fact that the panics we've been experiencing still exist in 
CURRENT. There was some disk issue that prevented the dump, so all I 
have is the panic, pasted below.

The two test systems with full debugging are still running after a week 
and a half.

> You might want to set
> kern.kstack_pages=6
> in /boot/loader.conf in these setups.
> 
> I would normally expect double faults when a kernel stack is blown,
> but maybe there is a reason that you do now see that for a blown kernel
> stack. (The impact of increasing stack pages from 4->6 should be minimal.)
> 
> rick
Rick - I'm a little confused by the kstack_pages tunable and just want 
to clarify. Are you proposing that this might solve the panic issues 
we've been having, or that it will make the panics/dumps more useful by 
avoiding false positives? We've only ever seen that "double fault" once 
in over 100 observed panics, and that was only when we enabled just 
KASAN on a 14.0p4 system.

-Matt


[85751] Fatal trap 12: page fault while in kernel mode
[85751] cpuid = 3; apic id = 06
[85751] fault virtual address  = 0x4f0f760
[85751] fault code = supervisor read data, page not present
[85751] instruction pointer= 0x20:0x820022f7
[85751] stack pointer  = 0x28:0xfe010bdf8d50
[85751] frame pointer  = 0x28:0xfe010bdf8d80
[85751] code segment   = base 0x0, limit 0xf, type 0x1b
[85751]= DPL 0, pres 1, long 1, def32 0, gran 1
[85751] processor eflags   = interrupt enabled, resume, IOPL = 0
[85751] current process= 0 (z_wr_int_h_3)
[85751] rdi: f802d1036900 rsi: f80416887300 rdx: f80416887380
[85751] rcx: f802d1036908  r8: 0100  r9: 8013070f000700ff
[85751] rax: 04f0f748 rbx: f802d1036900 rbp: fe010bdf8d80
[85751] r10: f80412c4f708 r11:  r12: f8000944ed58
[85751] r13:  r14: 04f0f748 r15: fe010caa9438
[85751] trap number= 12
[85751] panic: page fault
[85751] cpuid = 3
[85751] time = 1708451091
[85751] KDB: stack backtrace:
[85751] #0 0x80b9803d at kdb_backtrace+0x5d
[85751] #1 0x80b4a8d5 at vpanic+0x135
[85751] #2 0x80b4a793 at panic+0x43
[85751] #3 0x81026b8f at trap_fatal+0x40f
[85751] #4 0x81026bdf at trap_pfault+0x4f
[85751] #5 0x80ffd9f8 at calltrap+0x8
[85751] #6 0x81fea83b at dmu_sync_late_arrival_done+0x6b
[85751] #7 0x8214a78e at zio_done+0xc6e
[85751] #8 0x821442cc at zio_execute+0x3c
[85751] #9 0x80bae402 at taskqueue_run_locked+0x182
[85751] #10 0x80baf692 at taskqueue_thread_loop+0xc2
[85751] #11 0x80b0484f at fork_exit+0x7f
[85751] #12 0x80ffea5e at fork_trampoline+0xe
[85751] Uptime: 23h49m11s

Re: FreeBSD panics possibly caused by nfs clients

[Matthew L. Dailey]

Hi all,

So I finally induced a panic on a "pure" ufs system - root and exported 
filesystem were both ufs. So, I think this definitively rules out zfs as 
a source of the issue.

This panic was on 14.0p5 without debugging options, so the core may not 
be helpful. The panic and backtrace are below in case they're 
interesting to anyone.

Next, I'm going to try a CURRENT kernel without debugging options 
enabled just to see if I can finally induce a panic here. My other two 
VMs running CURRENT with full debugging are still clanking along.

-Matt

[218716] Fatal trap 12: page fault while in kernel mode
[218716] cpuid = 4; apic id = 08
[218716] fault virtual address  = 0x10017
[218716] fault code = supervisor read data, page not present
[218716] instruction pointer= 0x20:0x80e9165d
[218716] stack pointer  = 0x28:0xfe010b5aa3b0
[218716] frame pointer  = 0x28:0xfe010b5aa400
[218716] code segment   = base 0x0, limit 0xf, type 0x1b
[218716]= DPL 0, pres 1, long 1, def32 0, gran 1
[218716] processor eflags   = interrupt enabled, resume, IOPL = 0
[218716] current process= 49575 (nfsd: service)
[218716] rdi:  rsi: f800038ec900 rdx: fe00d9326000
[218716] rcx: 00030eb0  r8:   r9: fe010b5aa410
[218716] rax: 008f0eb0 rbx: f8038ac4cd00 rbp: fe010b5aa400
[218716] r10:  r11:  r12: 
[218716] r13: f80003647c00 r14: f802f9dced00 r15: f800038ec900
[218716] trap number= 12
[218716] panic: page fault
[218716] cpuid = 4
[218716] time = 1708319487
[218716] KDB: stack backtrace:
[218716] #0 0x80b9309d at kdb_backtrace+0x5d
[218716] #1 0x80b461a2 at vpanic+0x132
[218716] #2 0x80b46063 at panic+0x43
[218716] #3 0x8101d85c at trap_fatal+0x40c
[218716] #4 0x8101d8af at trap_pfault+0x4f
[218716] #5 0x80ff3fe8 at calltrap+0x8
[218716] #6 0x80e8716e at newdirrem+0x8be
[218716] #7 0x80e866fa at softdep_setup_remove+0x1a
[218716] #8 0x80ea71af at ufs_dirremove+0x21f
[218716] #9 0x80ead4f4 at ufs_remove+0xb4
[218716] #10 0x810f1428 at VOP_REMOVE_APV+0x28
[218716] #11 0x80a60db4 at nfsvno_removesub+0xc4
[218716] #12 0x80a52699 at nfsrvd_remove+0x1b9
[218716] #13 0x80a374d4 at nfsrvd_dorpc+0x1854
[218716] #14 0x80a4e76f at nfssvc_program+0x82f
[218716] #15 0x80e34080 at svc_run_internal+0xb50
[218716] #16 0x80e3475b at svc_thread_start+0xb
[218716] #17 0x80b00b7f at fork_exit+0x7f
[218716] Uptime: 2d12h45m16s
[218716] Dumping 985 out of 16350 
MB:..2%..12%..22%..31%..41%..51%..61%..72%..82%..91%


#0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57
#1  doadump (textdump=) at 
/usr/src/sys/kern/kern_shutdown.c:405
#2  0x80b45d37 in kern_reboot (howto=260)
 at /usr/src/sys/kern/kern_shutdown.c:526
#3  0x80b4620f in vpanic (fmt=0x81147c9c "%s",
 ap=ap@entry=0xfe010b5aa200) at 
/usr/src/sys/kern/kern_shutdown.c:970
#4  0x80b46063 in panic (fmt=)
 at /usr/src/sys/kern/kern_shutdown.c:894
#5  0x8101d85c in trap_fatal (frame=0xfe010b5aa2f0, 
eva=4294967319)
 at /usr/src/sys/amd64/amd64/trap.c:952
#6  0x8101d8af in trap_pfault (frame=0xfe010b5aa2f0,
 usermode=false, signo=, ucode=)
 at /usr/src/sys/amd64/amd64/trap.c:760
#7  
#8  cancel_diradd (dap=0xf8038ac4cd00,
 dirrem=dirrem@entry=0xf800038ec900,
 jremref=jremref@entry=0xf802f9dced00, 
dotremref=dotremref@entry=0x0,
 dotdotremref=dotdotremref@entry=0x0)
 at /usr/src/sys/ufs/ffs/ffs_softdep.c:9028
#9  0x80e8716e in newdirrem (bp=,
 dp=dp@entry=0xf800037fea80, ip=ip@entry=0xf8006b3b9300,
 isrmdir=isrmdir@entry=0, 
prevdirremp=prevdirremp@entry=0xfe010b5aa4b0)
 at /usr/src/sys/ufs/ffs/ffs_softdep.c:9480
#10 0x80e866fa in softdep_setup_remove (bp=0x,
 dp=0xf800038ec900, dp@entry=0xf800037fea80, 
ip=0xfe00d9326000,
 ip@entry=0xf8006b3b9300, isrmdir=200368, isrmdir@entry=0)
 at /usr/src/sys/ufs/ffs/ffs_softdep.c:9176
#11 0x80ea71af in ufs_dirremove (dvp=dvp@entry=0xf801f764be00,
 ip=ip@entry=0xf8006b3b9300, flags=,
 isrmdir=isrmdir@entry=0) at /usr/src/sys/ufs/ufs/ufs_lookup.c:1198
#12 0x80ead4f4 in ufs_remove (ap=0xfe010b5aa5d8)
 at /usr/src/sys/ufs/ufs/ufs_vnops.c:1054
#13 0x810f1428 in VOP_REMOVE_APV (
 vop=0x8172f2d0 , a=a@entry=0xfe010b5aa5d8)
 at vnode_if.c:1534
#14 0x80a60db4 in VOP_REMOVE (dvp=0x8f0eb0, vp=0xf800539b7380,
 cnp=0x30eb0) at ./vnode_if.h:789
#15 nfsvno_removesub (ndp=0xfe010b5aa858, is_v4=,
 cred=, p=p@entry=0xfe010ae803a0,
 exp=exp@entry=0xfe010b5aaa88)
 at 

Re: FreeBSD panics possibly caused by nfs clients

[Matthew L. Dailey]

Hi all,

Before the week was out, I wanted to provide an update on this issue.

Last weekend, I installed two VMs with CURRENT
(20240208-82bebc793658-268105) - one on zfs and one on ufs - and built a 
kernel with this config file:
include GENERIC
ident   THAYER-FULLDEBUG
makeoptions DEBUG=-g
options KASAN
options DDB
options INVARIANT_SUPPORT
options INVARIANTS
options QUEUE_MACRO_DEBUG_TRASH
options WITNESS
options WITNESS_SKIPSPIN
options KGSSAPI

I'm also setting these in loader.conf:
debug.witness.watch=1
debug.witness.kdb=1
kern.kstack_pages=8

These two VMs have been running non-stop with our hdf5 workload without 
a panic for 146 hours and 122 hours, respectively. This might be good 
news, but is well within the threshold we've seen in our testing over 
the past 6 months. Given that all the debug kernel options slow things 
down significantly, these could just be taking a long while to panic.

I also have a another VM with our "standard" 14.0p5 kernel (GENERIC with 
KGSSAPI enabled) running on ufs to try to rule in or out zfs. This 
failed this morning, but not with a panic. In this case, nfs stopped 
responding. This is a failure mode we have seen in our testing, but is 
much rarer than a full panic. I intend to continue testing this to try 
to induce a panic, at which point I think we can rule out zfs as a 
potential cause.

Just so it's documented, since I started experimenting with kernel debug 
options last week, I have so far induced panics with the following:
- 13.2p9 kernel on hardware (only WITNESS enabled)
- 14.0p4 kernel on VM (only KASAN enabled)
- 13.2p9 kernel on hardware (all debug options above except KASAN)

My plan right now is to continue running my two test VMs with CURRENT to 
see if it's just taking a long time to panic. Once I have finished my 
ufs testing on the third VM, I will build a GENERIC kernel for CURRENT 
(no debug options, only KGSSAPI) and test against that to see if the 
actual debug instrumentation is interfering with reproducing this issue.

Please reach out if you have ideas or suggestions. I'll provide updates 
here when I have them.

Thanks,
Matt

Re: FreeBSD panics possibly caused by nfs clients

[Matthew L. Dailey]

On 2/9/24 4:18 PM, Mark Johnston wrote:
> [You don't often get email from ma...@freebsd.org. Learn why this is 
> important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Fri, Feb 09, 2024 at 06:23:08PM +0000, Matthew L. Dailey wrote:
>> I had my first kernel panic with a KASAN kernel after only 01:27. This
>> first panic was a "double fault," which isn't anything we've seen
>> previously - usually we've seen trap 9 or trap 12, but sometimes others.
>> Based on the backtrace, it definitely looks like KASAN caught something,
>> but I don't have the expertise to know if this points to anything
>> specific. From the backtrace, it looks like this might have originated
>> in ipfw code.
> 
> A double fault is rather unexpected.  I presume you're running
> releng/14.0?  Is it at all possible to test with FreeBSD-CURRENT?

This is just 14.0-RELEASE, updated to p4. Haven't played with CURRENT 
before, but I'll give it a shot.

> 
> Did you add INVARIANTS etc. to the kernel configuration used here, or
> just KASAN?
> 

This just had KASAN. Are you suggesting that I only add INVARIANTS 
(along with KASAN), or all the various debug bits:
options DDB
options INVARIANT_SUPPORT
options INVARIANTS
options QUEUE_MACRO_DEBUG_TRASH
options WITNESS
options WITNESS_SKIPSPIN

>> Please let me know what other info I can provide or what I can do to dig
>> deeper.
> 
> If you could repeat the test several times, I'd be interested in seeing
> if you always get the same result.  If you're willing to share the
> vmcore (or several), I'd be willing to take a look at it.
> 

We'll see how things go with testing, and I'll pass along cores directly 
if it makes sense. There shouldn't be anything sensitive that we care about.

>> Thanks!!
>>
>> Panic message:
>> [5674] Fatal double fault
>> [5674] rip 0x812f6e32 rsp 0xfe014677afe0 rbp 0xfe014677b430
>> [5674] rax 0x1fc028cef620 rdx 0xf2f2f2f8f2f2f2f2 rbx 0x1
>> [5674] rcx 0xd7c0 rsi 0xfe004086a4a0 rdi 0xf8f8f8f8f2f2f2f8
>> [5674] r8 0xf8f8f8f8f8f8f8f8 r9 0x162a r10 0x835003002d3a64e1
>> [5674] r11 0 r12 0xf78028cef620 r13 0xfe004086a440
>> [5674] r14 0xfe01488c0560 r15 0x26f40 rflags 0x10006
>> [5674] cs 0x20 ss 0x28 ds 0x3b es 0x3b fs 0x13 gs 0x1b
>> [5674] fsbase 0x95d1d81a130 gsbase 0x84a14000 kgsbase 0
>> [5674] cpuid = 4; apic id = 08
>> [5674] panic: double fault
>> [5674] cpuid = 4
>> [5674] time = 1707498420
>> [5674] KDB: stack backtrace:
>> [5674] Uptime: 1h34m34s
>>
>> Backtrace:
>> #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57
>> #1  doadump (textdump=) at
>> /usr/src/sys/kern/kern_shutdown.c:405
>> #2  0x8128b7dc in kern_reboot (howto=howto@entry=260)
>>   at /usr/src/sys/kern/kern_shutdown.c:526
>> #3  0x8128c000 in vpanic (
>>   fmt=fmt@entry=0x82589a00  "double fault",
>>   ap=ap@entry=0xfe0040866de0) at
>> /usr/src/sys/kern/kern_shutdown.c:970
>> #4  0x8128bd75 in panic (fmt=0x82589a00  "double
>> fault")
>>   at /usr/src/sys/kern/kern_shutdown.c:894
>> #5  0x81c4b335 in dblfault_handler (frame=)
>>   at /usr/src/sys/amd64/amd64/trap.c:1012
>> #6  
>> #7  0x812f6e32 in sched_clock (td=td@entry=0xfe01488c0560,
>>   cnt=cnt@entry=1) at /usr/src/sys/kern/sched_ule.c:2601
>> #8  0x8119e2a7 in statclock (cnt=cnt@entry=1,
>>   usermode=usermode@entry=0) at /usr/src/sys/kern/kern_clock.c:760
>> #9  0x8119fb67 in handleevents (now=now@entry=24371855699832,
>>   fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:195
>> #10 0x811a10cc in timercb (et=, arg=)
>>   at /usr/src/sys/kern/kern_clocksource.c:353
>> #11 0x81dcd280 in lapic_handle_timer (frame=0xfe014677b750)
>>   at /usr/src/sys/x86/x86/local_apic.c:1343
>> #12 
>> #13 __asan_load8_noabort (addr=18446741880219689232)
>>   at /usr/src/sys/kern/subr_asan.c:1113
>> #14 0x851488b8 in ?? () from /boot/thayer/ipfw.ko
>> #15 0xfe01 in ?? ()
>> #16 0x8134dcd5 in pcpu_find (cpuid=1238425856)
>>   at /usr/src/sys/kern/subr_pcpu.c:286
>> #17 0x85151f6f in ?? () from /boot/thayer/ipfw.ko
>> #18 0x in ?? ()

Re: FreeBSD panics possibly caused by nfs clients

[Matthew L. Dailey]

I had my first kernel panic with a KASAN kernel after only 01:27. This 
first panic was a "double fault," which isn't anything we've seen 
previously - usually we've seen trap 9 or trap 12, but sometimes others. 
Based on the backtrace, it definitely looks like KASAN caught something, 
but I don't have the expertise to know if this points to anything 
specific. From the backtrace, it looks like this might have originated 
in ipfw code.

Please let me know what other info I can provide or what I can do to dig 
deeper.

Thanks!!

Panic message:
[5674] Fatal double fault
[5674] rip 0x812f6e32 rsp 0xfe014677afe0 rbp 0xfe014677b430
[5674] rax 0x1fc028cef620 rdx 0xf2f2f2f8f2f2f2f2 rbx 0x1
[5674] rcx 0xd7c0 rsi 0xfe004086a4a0 rdi 0xf8f8f8f8f2f2f2f8
[5674] r8 0xf8f8f8f8f8f8f8f8 r9 0x162a r10 0x835003002d3a64e1
[5674] r11 0 r12 0xf78028cef620 r13 0xfe004086a440
[5674] r14 0xfe01488c0560 r15 0x26f40 rflags 0x10006
[5674] cs 0x20 ss 0x28 ds 0x3b es 0x3b fs 0x13 gs 0x1b
[5674] fsbase 0x95d1d81a130 gsbase 0x84a14000 kgsbase 0
[5674] cpuid = 4; apic id = 08
[5674] panic: double fault
[5674] cpuid = 4
[5674] time = 1707498420
[5674] KDB: stack backtrace:
[5674] Uptime: 1h34m34s

Backtrace:
#0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57
#1  doadump (textdump=) at 
/usr/src/sys/kern/kern_shutdown.c:405
#2  0x8128b7dc in kern_reboot (howto=howto@entry=260)
 at /usr/src/sys/kern/kern_shutdown.c:526
#3  0x8128c000 in vpanic (
 fmt=fmt@entry=0x82589a00  "double fault",
 ap=ap@entry=0xfe0040866de0) at 
/usr/src/sys/kern/kern_shutdown.c:970
#4  0x8128bd75 in panic (fmt=0x82589a00  "double 
fault")
 at /usr/src/sys/kern/kern_shutdown.c:894
#5  0x81c4b335 in dblfault_handler (frame=)
 at /usr/src/sys/amd64/amd64/trap.c:1012
#6  
#7  0x812f6e32 in sched_clock (td=td@entry=0xfe01488c0560,
 cnt=cnt@entry=1) at /usr/src/sys/kern/sched_ule.c:2601
#8  0x8119e2a7 in statclock (cnt=cnt@entry=1,
 usermode=usermode@entry=0) at /usr/src/sys/kern/kern_clock.c:760
#9  0x8119fb67 in handleevents (now=now@entry=24371855699832,
 fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:195
#10 0x811a10cc in timercb (et=, arg=)
 at /usr/src/sys/kern/kern_clocksource.c:353
#11 0x81dcd280 in lapic_handle_timer (frame=0xfe014677b750)
 at /usr/src/sys/x86/x86/local_apic.c:1343
#12 
#13 __asan_load8_noabort (addr=18446741880219689232)
 at /usr/src/sys/kern/subr_asan.c:1113
#14 0x851488b8 in ?? () from /boot/thayer/ipfw.ko
#15 0xfe01 in ?? ()
#16 0x8134dcd5 in pcpu_find (cpuid=1238425856)
 at /usr/src/sys/kern/subr_pcpu.c:286
#17 0x85151f6f in ?? () from /boot/thayer/ipfw.ko
#18 0x in ?? ()

Re: FreeBSD panics possibly caused by nfs clients

[Matthew L. Dailey]

On 2/9/24 11:04 AM, Mark Johnston wrote:
> [You don't often get email from ma...@freebsd.org. Learn why this is 
> important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Thu, Feb 08, 2024 at 03:34:52PM +0000, Matthew L. Dailey wrote:
>> Good morning all,
>>
>> Per Rick Macklem's suggestion, I'm posting this query here in the hopes
>> that other may have ideas.
>>
>> We did do some minimal testing with ufs around this problem back in
>> August, but hadn't narrowed the issue down to hdf5 workloads yet, so
>> testing was inconclusive. We'll do further testing on this to try to
>> rule in or out zfs as a contributing factor.
>>
>> I'm happy to provide more technical details about this issue, but it is
>> quite complex to explain and reproduce.
> 
> It sounds like you've so far only tested with release kernels, is that
> right?  To make some progress and narrow this down a bit, we'd want to
> see testing results from a debug kernel.  Unfortunately we don't ship
> pre-compiled debug kernels with releases, so you'll have to compile your
> own, or test a snapshot of the development branch.  To do the former,
> add the following lines to /usr/src/sys/amd64/conf/GENERIC and follow
> the steps here: 
> https://docs.freebsd.org/en/books/handbook/kernelconfig/#kernelconfig-building
> 
> options DDB
> options INVARIANT_SUPPORT
> options INVARIANTS
> options QUEUE_MACRO_DEBUG_TRASH
> options WITNESS
> options WITNESS_SKIPSPIN
> 
> Since the problem appears to be some random memory corruption, I'd also
> suggest using a KASAN(9) kernel in your test VM.  If the root cause of
> the crashes is some kind of use-after-free or buffer overflow, KASAN has
> a good chance of catching it.  Note that both debug kernels and KASAN
> kernels have are significantly slower than release kernels, so you'll
> want to deploy these in your test VM.  Once you do, and a panic occurs,
> share the panic message and backtrace here, and we'll have a better idea
> of where to start.
> 

Hi Mark,

Thanks for your response. This is mostly right - the bulk of our testing 
has been on GENERIC, with the KGSSAPI option added for kerberized nfs.

I've had some out-of-band discussions where I learned about KASAN - I 
built a 14.0p4 kernel this morning with this and started a test a little 
while ago.

Based on your suggestions, I'll also build a debug kernel so I can do 
some parallel testing with this. I also still need to do more testing to 
rule in or out zfs as Rick suggested.

In our experience, these panics can take hours or days to manifest (our 
high bar so far is 176 hours!), so it may take a while to get results. :-)

I'll post more here as there's anything to report.

Best,
Matt

>> Thanks in advance for any help!
>>
>> Best,
>> Matt
>>
>> On 2/7/24 6:10 PM, Rick Macklem wrote:
>>   >
>>   > Well, there is certainly no obvious answer.
>>   > One thing I would suggest is setting up a test
>>   > server using UFS and see it if panics.
>>   >
>>   > To be honest, NFS is pretty simple when it comes
>>   > to server side reading/writiing. It basically translates
>>   > NFS RPCs to VOP calls on the underlying file system.
>>   > As such, issues are usually either network fabric on one side
>>   > (everything from cables to NIC drives and the TCP stack).
>>   > Since you are seeing this with assorted NICs and FreeBSD
>>   > versions, I doubt it is network fabric related, but??
>>   > This is why I'd suspect the ZFS side and trying UFS would
>>   > isolate the problem to ZFS.
>>   >
>>   > Although I know nothing about hdf5 files, the NFS code does
>>   > nothing with the data (it is just a byte stream),
>>   > Since ZFS does normally do things like compression, it could be
>>   > affected by the data contents.
>>   >
>>   > Another common (although less common now) problem is TSO
>>   > when data of certain sizes (often just less than 64K) is handled.
>>   > However, this usually results in hangs and I have never heard
>>   > of memory data corruption.
>>   >
>>   > Bottom line..determining if it is ZFS specific would be the best
>>   > first step, I think?
>>   >
>>   > It would be good to post this to a mailing list like freebsd-current@,
>>   > since others might have some insite into this. (Although you are
>>   > not using freebsd-current@, that is where most developers read
>>   > email.)
>>   >
>>   > rick
>>   >
>>   >
>>   > On Wed, Feb 7, 2024 at 10:50 AM Matthew L. Dailey
>>   >  wrote:

FreeBSD panics possibly caused by nfs clients

[Matthew L. Dailey]

Good morning all,

Per Rick Macklem's suggestion, I'm posting this query here in the hopes 
that other may have ideas.

We did do some minimal testing with ufs around this problem back in 
August, but hadn't narrowed the issue down to hdf5 workloads yet, so 
testing was inconclusive. We'll do further testing on this to try to 
rule in or out zfs as a contributing factor.

I'm happy to provide more technical details about this issue, but it is 
quite complex to explain and reproduce.

Thanks in advance for any help!

Best,
Matt

On 2/7/24 6:10 PM, Rick Macklem wrote:
 >
 > Well, there is certainly no obvious answer.
 > One thing I would suggest is setting up a test
 > server using UFS and see it if panics.
 >
 > To be honest, NFS is pretty simple when it comes
 > to server side reading/writiing. It basically translates
 > NFS RPCs to VOP calls on the underlying file system.
 > As such, issues are usually either network fabric on one side
 > (everything from cables to NIC drives and the TCP stack).
 > Since you are seeing this with assorted NICs and FreeBSD
 > versions, I doubt it is network fabric related, but??
 > This is why I'd suspect the ZFS side and trying UFS would
 > isolate the problem to ZFS.
 >
 > Although I know nothing about hdf5 files, the NFS code does
 > nothing with the data (it is just a byte stream),
 > Since ZFS does normally do things like compression, it could be
 > affected by the data contents.
 >
 > Another common (although less common now) problem is TSO
 > when data of certain sizes (often just less than 64K) is handled.
 > However, this usually results in hangs and I have never heard
 > of memory data corruption.
 >
 > Bottom line..determining if it is ZFS specific would be the best
 > first step, I think?
 >
 > It would be good to post this to a mailing list like freebsd-current@,
 > since others might have some insite into this. (Although you are
 > not using freebsd-current@, that is where most developers read
 > email.)
 >
 > rick
 >
 >
 > On Wed, Feb 7, 2024 at 10:50 AM Matthew L. Dailey
 >  wrote:
 >>
 >>
 >> Hi Rick,
 >>
 >> My name is Matt Dailey, and (among many other things), I run a FreeBSD
 >> file server for the Thayer School of Engineering and the Department of
 >> Computer Science here at Dartmouth College. We have run into a very odd
 >> issue in which nfs4 Linux clients using hdf5 files are corrupting memory
 >> and causing kernel panics on our FreeBSD server. The issue is very
 >> complex to describe, and despite our diligent efforts, we have not been
 >> able to replicate it in a simple scenario to report to FreeBSD
 >> developers. In advance of filing an official bug report, I’m reaching
 >> out in the hopes of having a discussion to get your guidance about how
 >> best to proceed.
 >>
 >> The quick background is that we’ve been running a FreeBSD file server,
 >> serving files from a zfs filesystem over kerberized nfs4 and samba for
 >> almost 11 years, through 3 different generations of hardware and from
 >> FreeBSD 9.1 up through 13.2. This system has historically been
 >> wonderfully stable and robust.
 >>
 >> Beginning late in 2022, and then more regularly beginning in July of
 >> 2023, we started experiencing kernel panics on our current system, then
 >> running FreeBSD 13.0. They were seemingly random (mostly trap 12 and
 >> trap 9) in random kernel functions, so we initially blamed hardware. We
 >> replaced all RAM, moved to backup hardware, and even moved to an older,
 >> retired system and the panics persisted. We have also upgraded from 13.0
 >> to 13.2 and are currently at 13.2p5.
 >>
 >> After months of investigation, we finally narrowed down that these
 >> panics were being caused by software on our Linux clients writing hdf5
 >> files over nfs to the FreeBSD server. As near as we can tell from poring
 >> through core dumps, something about how this nfs traffic is being
 >> processed is corrupting kernel memory and then eventually a panic is
 >> happening when some unsuspecting function reads the corrupted memory.
 >> Since we have eliminated most known hdf5 workloads on our production
 >> system, the panics have mostly ceased, and we suspect that the remaining
 >> crashes could be from users still using hdf5.
 >>
 >> We have reproduced this issue with both krb5 and sys mounts, and up
 >> through 13.2p9 and 14.0p4. All our testing has been using nfs 4.1.
 >> Depending on conditions, panics sometimes occur within an hour or two,
 >> or sometimes can take several days. On 14.0, the panics seems much less
 >> prevalent, but still exist. With 13.x, it is easier to reproduce on
 &

Re: upgrade stable/12 -> stable/13 zfs + boot partition Mediasize 64K

[Matthew D. Fuller]

On Thu, Feb 11, 2021 at 04:43:57PM -0800 I heard the voice of
Freddie Cash, and lo! it spake thus:
>
> Sorry, meant 256 KB or 512 KB, not MB!

Worth remembering: at least in the past, there was also an _upper_
limit to the size based on the lower-level bootblocks that read the
freebsd-boot partition, above which things would also break horribly.
I don't recall exactly what it was, but it was >512k and <1m (maybe
600k-ish?).  So don't just make it arbitrarily bigger.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gib driver problems?

[Matthew Macy]

What is the PCIID for the MAC?

On Wed, Feb 3, 2021 at 14:35 joe mcguckin  wrote:

> I recently installed 12.2 on a supermicro motherboard.
>
> Connected to a 100M port on a Cisco switch, everything works ok
> Connecting to a 1000BTX port, ifconfig says “Active, 1000B full duplex”
> but no traffic passes.
>
> Are there known problems with the igb driver?
>
> Thanks,
>
> Joe
>
>
> Joe McGuckin
> ViaNet Communications
>
> j...@via.net
> 650-207-0372 cell
> 650-213-1302 office
> 650-969-2124 fax
>
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT, usr/src on git, howto "mergemaster"?

[Matthew Seaman]

On 04/01/2021 12:29, David Wolfskill wrote:


Caveat: Since the switch, I have yet to encounter a case where I needed
to merge a change in (e.g., because of a newly-created user, or there
was a commit to /etc/crontab or /etc/newsyslog.conf).  I may find things
rather "more interesting" when that happens; we shall see.


The process of merging changes in etcupdate(1) is essentially identical 
to merging in mergemaster(1) -- the difference being that typically 
etcupdate(1) will run to completion without any user intervention 
needed, or else it will flag up that there are unresolved differences to 
merge and flag to the user to run `etcupdate resolve` as a separate command.


This is much more time efficient than the typical mergemaster(1) 
procedure, and I find it lends itself much more effectively to 
automation through eg. ansible.  (ie. you can just run the first 
`etcupdate` through automation across all of your server inventory, and 
then go round and manually resolve anything that needs it.)


Cheers,

    Matthew

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenZFS: kldload zfs.ko freezes on i386 4GB memory

[Matthew Macy]

>
> Getting back to your original question. A more efficient ARC would exercise
> your memory more intensely because you are replacing disk reads with memory
> reads. And as I said before the old ZFS "found" weak RAM on three separate
> occasions in three different machines over the last ten years. You're
> advised to replace the marginal memory.

Ryan has been able to reproduce this in a VM with 4GB, similarly a VM
with 2GB loads just fine. It would seem that 4GB triggers a bug in
limit handling. We're hoping that we can simply lower one of the
default limits on i386 and make the problem go away.

Please don't shoot the messenger when I observe that, generally
speaking, i386 is considered a self supported platform due to ZFS
general inability to perform well with limited memory or KVA. Long
mode has been available on virtually all processors shipped since
2006.

Cheers.
-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: vfs.zfs.min_auto_ashift and OpenZFS

[Matthew Macy]

On Sun, Sep 6, 2020 at 17:08 Ed Maste  wrote:

> On Fri, 1 May 2020 at 20:20, Matthew Macy  wrote:
>
> >
>
> > OpenZFS doesn't have the same ashift optimization logic that FreeBSD
>
> > has. It's something that needs to be resolved before the code can be
>
> > integrated downstream.
>
>
>
> Note that our installer tries to set the min_auto_ashift when ZFS is
>
> selected - I've submitted PR 249157 to track that.
>
> This long since been fixed. Note that Ryan built working installer images
during the CFT.
-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenZFS support merged

[Matthew Macy]

On Sat, Aug 29, 2020 at 08:47 Kurt Jaeger  wrote:

> Hi!
>
>
>
> > r364746 merged OpenZFS support in to HEAD.
>
> >
>
> > The change should be transparent unless you want to use new features.
>
> > I caution against 'zpool upgrade' for the next few weeks.
>
> > https://svnweb.freebsd.org/base?view=revision=364746
>
>
>
> A system running r363767 can upgrade to some revision after r364746
>
> and reboot and come up without big issues, running the new openzfs code ?
>
>
>
> Or is some additional step required ?
>


Barring some unusual configuration that no one else there should not be a
problem. The only known issue of immediate concern (that was only raised a
day or two ago :-/) is zfs delegation in poudriere. If you rely on that I’d
say wait a couple days, otherwise proceed.

-M


>
>
> --
>
> p...@opsec.eu+49 171 3101372Now what ?
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic in range_tree_seg64_compare()

[Matthew Macy]

Try updating. I think this may have been fixed in
https://github.com/openzfs/zfs/pull/10823 which was MFVed this
morning.

On Fri, Aug 28, 2020 at 9:49 AM Matthew Macy  wrote:
>
> On Thu, Aug 27, 2020 at 10:37 PM Yuri Pankov  wrote:
> >
> > Matthew Macy wrote:
> > > On Thu, Aug 27, 2020 at 6:34 PM Yuri Pankov  wrote:
> > >>
> > >> Yet another issue I'm seeing after last update (currently running
> > >> r364870), hit it 2 times today:
> > >>
> > >> Fatal trap 12: page fault while in kernel mode
> > >> cpuid = 19; apic id = 0d
> > >> fault virtual address   = 0xf819e2ecdc40
> > >> fault code  = supervisor read data, page not present
> > >> instruction pointer = 0x20:0x8277fa64
> > >> stack pointer   = 0x28:0xfe01f9ff2d90
> > >> frame pointer   = 0x28:0xfe01f9ff2d90
> > >> code segment= base 0x0, limit 0xf, type 0x1b
> > >>   = DPL 0, pres 1, long 1, def32 0, gran 1
> > >> processor eflags= interrupt enabled, resume, IOPL = 0
> > >> current process = 48792 (blk-3:0-0)
> > >> trap number = 12
> > >> panic: page fault
> > >> cpuid = 19
> > >> time = 1598577675
> > >> KDB: stack backtrace:
> > >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > >> 0xfe01f9ff2a40
> > >> vpanic() at vpanic+0x182/frame 0xfe01f9ff2a90
> > >> panic() at panic+0x43/frame 0xfe01f9ff2af0
> > >> trap_fatal() at trap_fatal+0x387/frame 0xfe01f9ff2b50
> > >> trap_pfault() at trap_pfault+0x97/frame 0xfe01f9ff2bb0
> > >> trap() at trap+0x2ab/frame 0xfe01f9ff2cc0
> > >> calltrap() at calltrap+0x8/frame 0xfe01f9ff2cc0
> > >> --- trap 0xc, rip = 0x8277fa64, rsp = 0xfe01f9ff2d90, rbp =
> > >> 0xfe01f9ff2d90 ---
> > >> range_tree_seg64_compare() at range_tree_seg64_compare+0x4/frame
> > >> 0xfe01f9ff2d90
> > >> zfs_btree_find() at zfs_btree_find+0x1bd/frame 0xfe01f9ff2df0
> > >> range_tree_find_impl() at range_tree_find_impl+0x6e/frame 
> > >> 0xfe01f9ff2e30
> > >> range_tree_find() at range_tree_find+0x1c/frame 0xfe01f9ff2e70
> > >> range_tree_contains() at range_tree_contains+0x9/frame 0xfe01f9ff2e80
> > >> dnode_block_freed() at dnode_block_freed+0x11d/frame 0xfe01f9ff2eb0
> > >> dbuf_read() at dbuf_read+0x70c/frame 0xfe01f9ff2fc0
> > >> dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x164/frame
> > >> 0xfe01f9ff3030
> > >> dmu_read_impl() at dmu_read_impl+0xce/frame 0xfe01f9ff30c0
> > >> dmu_read() at dmu_read+0x45/frame 0xfe01f9ff3100
> > >> zvol_geom_bio_strategy() at zvol_geom_bio_strategy+0x2aa/frame
> > >> 0xfe01f9ff3180
> > >> g_io_request() at g_io_request+0x2df/frame 0xfe01f9ff31b0
> > >> g_dev_strategy() at g_dev_strategy+0x155/frame 0xfe01f9ff31e0
> > >> physio() at physio+0x4f8/frame 0xfe01f9ff3270
> > >> devfs_read_f() at devfs_read_f+0xde/frame 0xfe01f9ff32d0
> > >> dofileread() at dofileread+0x81/frame 0xfe01f9ff3320
> > >> kern_preadv() at kern_preadv+0x62/frame 0xfe01f9ff3360
> > >> sys_preadv() at sys_preadv+0x39/frame 0xfe01f9ff3390
> > >> amd64_syscall() at amd64_syscall+0x140/frame 0xfe01f9ff34b0
> > >> fast_syscall_common() at fast_syscall_common+0xf8/frame 
> > >> 0xfe01f9ff34b0
> > >> --- syscall (289, FreeBSD ELF64, sys_preadv), rip = 0x8006fd89a, rsp =
> > >> 0x7fffdfdfcf18, rbp = 0x7fffdfdfcfc0 ---
> > >> Uptime: 4h13m43s
> > >
> > >
> > >>
> > >> Guessing on zvol_geom_bio_strategy(), it's volmode=dev zvol I'm using
> > >> for bhyve VM.  Anything known?
> > >
> > > Not really. A reproduction scenario would be very helpful. This was
> > > seen once by someone at iX - I committed some additional asserts to
> > > the truenas tree, but haven't heard further.
> > >
> > > +++ b/module/zfs/dbuf.c
> > > @@ -3192,7 +3192,7 @@
> > > dbuf_dirty_leaf_with_existing_frontend(dbuf_dirty_state_t *dds)
> > >   * scheduled its write with its buffer, we must
> > >   * disassociate by replacing the frontend.
> > >   */
> > > -

Re: panic in range_tree_seg64_compare()

[Matthew Macy]

On Thu, Aug 27, 2020 at 10:37 PM Yuri Pankov  wrote:
>
> Matthew Macy wrote:
> > On Thu, Aug 27, 2020 at 6:34 PM Yuri Pankov  wrote:
> >>
> >> Yet another issue I'm seeing after last update (currently running
> >> r364870), hit it 2 times today:
> >>
> >> Fatal trap 12: page fault while in kernel mode
> >> cpuid = 19; apic id = 0d
> >> fault virtual address   = 0xf819e2ecdc40
> >> fault code  = supervisor read data, page not present
> >> instruction pointer = 0x20:0x8277fa64
> >> stack pointer   = 0x28:0xfe01f9ff2d90
> >> frame pointer   = 0x28:0xfe01f9ff2d90
> >> code segment= base 0x0, limit 0xf, type 0x1b
> >>   = DPL 0, pres 1, long 1, def32 0, gran 1
> >> processor eflags= interrupt enabled, resume, IOPL = 0
> >> current process = 48792 (blk-3:0-0)
> >> trap number = 12
> >> panic: page fault
> >> cpuid = 19
> >> time = 1598577675
> >> KDB: stack backtrace:
> >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> >> 0xfe01f9ff2a40
> >> vpanic() at vpanic+0x182/frame 0xfe01f9ff2a90
> >> panic() at panic+0x43/frame 0xfe01f9ff2af0
> >> trap_fatal() at trap_fatal+0x387/frame 0xfe01f9ff2b50
> >> trap_pfault() at trap_pfault+0x97/frame 0xfe01f9ff2bb0
> >> trap() at trap+0x2ab/frame 0xfe01f9ff2cc0
> >> calltrap() at calltrap+0x8/frame 0xfe01f9ff2cc0
> >> --- trap 0xc, rip = 0x8277fa64, rsp = 0xfe01f9ff2d90, rbp =
> >> 0xfe01f9ff2d90 ---
> >> range_tree_seg64_compare() at range_tree_seg64_compare+0x4/frame
> >> 0xfe01f9ff2d90
> >> zfs_btree_find() at zfs_btree_find+0x1bd/frame 0xfe01f9ff2df0
> >> range_tree_find_impl() at range_tree_find_impl+0x6e/frame 
> >> 0xfe01f9ff2e30
> >> range_tree_find() at range_tree_find+0x1c/frame 0xfe01f9ff2e70
> >> range_tree_contains() at range_tree_contains+0x9/frame 0xfe01f9ff2e80
> >> dnode_block_freed() at dnode_block_freed+0x11d/frame 0xfe01f9ff2eb0
> >> dbuf_read() at dbuf_read+0x70c/frame 0xfe01f9ff2fc0
> >> dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x164/frame
> >> 0xfe01f9ff3030
> >> dmu_read_impl() at dmu_read_impl+0xce/frame 0xfe01f9ff30c0
> >> dmu_read() at dmu_read+0x45/frame 0xfe01f9ff3100
> >> zvol_geom_bio_strategy() at zvol_geom_bio_strategy+0x2aa/frame
> >> 0xfe01f9ff3180
> >> g_io_request() at g_io_request+0x2df/frame 0xfe01f9ff31b0
> >> g_dev_strategy() at g_dev_strategy+0x155/frame 0xfe01f9ff31e0
> >> physio() at physio+0x4f8/frame 0xfe01f9ff3270
> >> devfs_read_f() at devfs_read_f+0xde/frame 0xfe01f9ff32d0
> >> dofileread() at dofileread+0x81/frame 0xfe01f9ff3320
> >> kern_preadv() at kern_preadv+0x62/frame 0xfe01f9ff3360
> >> sys_preadv() at sys_preadv+0x39/frame 0xfe01f9ff3390
> >> amd64_syscall() at amd64_syscall+0x140/frame 0xfe01f9ff34b0
> >> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe01f9ff34b0
> >> --- syscall (289, FreeBSD ELF64, sys_preadv), rip = 0x8006fd89a, rsp =
> >> 0x7fffdfdfcf18, rbp = 0x7fffdfdfcfc0 ---
> >> Uptime: 4h13m43s
> >
> >
> >>
> >> Guessing on zvol_geom_bio_strategy(), it's volmode=dev zvol I'm using
> >> for bhyve VM.  Anything known?
> >
> > Not really. A reproduction scenario would be very helpful. This was
> > seen once by someone at iX - I committed some additional asserts to
> > the truenas tree, but haven't heard further.
> >
> > +++ b/module/zfs/dbuf.c
> > @@ -3192,7 +3192,7 @@
> > dbuf_dirty_leaf_with_existing_frontend(dbuf_dirty_state_t *dds)
> >   * scheduled its write with its buffer, we must
> >   * disassociate by replacing the frontend.
> >   */
> > -   ASSERT(db->db_state & (DB_READ|DB_PARTIAL));
> > +   ASSERT3U(db->db_state, &, (DB_READ|DB_PARTIAL));
> >  ASSERT3U(db->db_dirtycnt, ==, 1);
> >  dbuf_dirty_set_data(dds);
> >  } else {
> > @@ -3238,18 +3238,24 @@ dbuf_dirty_record_create_leaf(dbuf_dirty_state_t 
> > *dds)
> >
> >  dr = dbuf_dirty_record_create(dds);
> >
> > +   /*
> > +* XXX - convert to ASSERT after dn_free_ranges fix
> > +*/
> > +   VERIFY(db->db_level == 0);
> > +   VERIFY(db->db_blkid != DMU_BONUS_BLKID);
>
> Can't find context for both chunks, there are simply no such functions
> in sys/contrib/openzfs/module/zfs/dbuf.c, and yes, note that I'm running
> the in-tree version.

Sorry. I forgot that this was against the cow fault avoidance changes.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: can't handle raw ops yet!!!

[Matthew Macy]

https://github.com/openzfs/zfs/pull/10836

On Thu, Aug 27, 2020 at 11:37 AM Yuri Pankov  wrote:
>
> Matthew Macy wrote:
> > Expected. I'm working on it. It's just a friendly reminder when
> > INVARIANTS is enabled.
>
> Good, thanks.
>
> > On Thu, Aug 27, 2020 at 11:17 AM Yuri Pankov  wrote:
> >>
> >> After OpenZFS merge, during boot I'm getting several occurrences of what
> >> seems to be the following:
> >>
> >> http://src.illumos.org/source/xref/freebsd-head/sys/contrib/openzfs/module/os/freebsd/spl/spl_kstat.c#207
> >>
> >> And, yes, I'm running GENERIC, so with INVARIANTS.
> >>
> >> Should I be worried?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic in range_tree_seg64_compare()

[Matthew Macy]

On Thu, Aug 27, 2020 at 6:34 PM Yuri Pankov  wrote:
>
> Yet another issue I'm seeing after last update (currently running
> r364870), hit it 2 times today:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 19; apic id = 0d
> fault virtual address   = 0xf819e2ecdc40
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x8277fa64
> stack pointer   = 0x28:0xfe01f9ff2d90
> frame pointer   = 0x28:0xfe01f9ff2d90
> code segment= base 0x0, limit 0xf, type 0x1b
>  = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 48792 (blk-3:0-0)
> trap number = 12
> panic: page fault
> cpuid = 19
> time = 1598577675
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe01f9ff2a40
> vpanic() at vpanic+0x182/frame 0xfe01f9ff2a90
> panic() at panic+0x43/frame 0xfe01f9ff2af0
> trap_fatal() at trap_fatal+0x387/frame 0xfe01f9ff2b50
> trap_pfault() at trap_pfault+0x97/frame 0xfe01f9ff2bb0
> trap() at trap+0x2ab/frame 0xfe01f9ff2cc0
> calltrap() at calltrap+0x8/frame 0xfe01f9ff2cc0
> --- trap 0xc, rip = 0x8277fa64, rsp = 0xfe01f9ff2d90, rbp =
> 0xfe01f9ff2d90 ---
> range_tree_seg64_compare() at range_tree_seg64_compare+0x4/frame
> 0xfe01f9ff2d90
> zfs_btree_find() at zfs_btree_find+0x1bd/frame 0xfe01f9ff2df0
> range_tree_find_impl() at range_tree_find_impl+0x6e/frame 0xfe01f9ff2e30
> range_tree_find() at range_tree_find+0x1c/frame 0xfe01f9ff2e70
> range_tree_contains() at range_tree_contains+0x9/frame 0xfe01f9ff2e80
> dnode_block_freed() at dnode_block_freed+0x11d/frame 0xfe01f9ff2eb0
> dbuf_read() at dbuf_read+0x70c/frame 0xfe01f9ff2fc0
> dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x164/frame
> 0xfe01f9ff3030
> dmu_read_impl() at dmu_read_impl+0xce/frame 0xfe01f9ff30c0
> dmu_read() at dmu_read+0x45/frame 0xfe01f9ff3100
> zvol_geom_bio_strategy() at zvol_geom_bio_strategy+0x2aa/frame
> 0xfe01f9ff3180
> g_io_request() at g_io_request+0x2df/frame 0xfe01f9ff31b0
> g_dev_strategy() at g_dev_strategy+0x155/frame 0xfe01f9ff31e0
> physio() at physio+0x4f8/frame 0xfe01f9ff3270
> devfs_read_f() at devfs_read_f+0xde/frame 0xfe01f9ff32d0
> dofileread() at dofileread+0x81/frame 0xfe01f9ff3320
> kern_preadv() at kern_preadv+0x62/frame 0xfe01f9ff3360
> sys_preadv() at sys_preadv+0x39/frame 0xfe01f9ff3390
> amd64_syscall() at amd64_syscall+0x140/frame 0xfe01f9ff34b0
> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe01f9ff34b0
> --- syscall (289, FreeBSD ELF64, sys_preadv), rip = 0x8006fd89a, rsp =
> 0x7fffdfdfcf18, rbp = 0x7fffdfdfcfc0 ---
> Uptime: 4h13m43s


>
> Guessing on zvol_geom_bio_strategy(), it's volmode=dev zvol I'm using
> for bhyve VM.  Anything known?

Not really. A reproduction scenario would be very helpful. This was
seen once by someone at iX - I committed some additional asserts to
the truenas tree, but haven't heard further.

+++ b/module/zfs/dbuf.c
@@ -3192,7 +3192,7 @@
dbuf_dirty_leaf_with_existing_frontend(dbuf_dirty_state_t *dds)
 * scheduled its write with its buffer, we must
 * disassociate by replacing the frontend.
 */
-   ASSERT(db->db_state & (DB_READ|DB_PARTIAL));
+   ASSERT3U(db->db_state, &, (DB_READ|DB_PARTIAL));
ASSERT3U(db->db_dirtycnt, ==, 1);
dbuf_dirty_set_data(dds);
} else {
@@ -3238,18 +3238,24 @@ dbuf_dirty_record_create_leaf(dbuf_dirty_state_t *dds)

dr = dbuf_dirty_record_create(dds);

+   /*
+* XXX - convert to ASSERT after dn_free_ranges fix
+*/
+   VERIFY(db->db_level == 0);
+   VERIFY(db->db_blkid != DMU_BONUS_BLKID);


Thanks.
-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel fais with option ZFS in kernel configuration

[Matthew Macy]

Need zstdio option when linking statically

On Thu, Aug 27, 2020 at 8:23 AM Scott Kenney  wrote:
>
> Hello,
>
> Just noticed that buildkernel fails with "options ZFS" in the kernel
> configuration file, the modules build without error.
>
> Source is at revision 364870
>
> FreeBSD datura.rmta.org 13.0-CURRENT FreeBSD
> 13.0-CURRENT #3 r364525: Sun Aug 23 23:14:23 EDT 2020
> r...@datura.rmta.org:/usr/obj/usr/src/amd64.amd64/sys/DATURA amd64
>
>
>
> linking kernel
> ld: error: undefined symbol: zfs_zstd_compress
> >>> referenced by zio_compress.c
> >>>   zio_compress.o:(zio_compress_table)
>
> ld: error: undefined symbol: zfs_zstd_decompress
> >>> referenced by zio_compress.c
> >>>   zio_compress.o:(zio_compress_table)
>
> ld: error: undefined symbol: zfs_zstd_decompress_level
> >>> referenced by zio_compress.c
> >>>   zio_compress.o:(zio_compress_table)
> *** [kernel] Error code 1
>
> make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/DATURA
> 1 error
>
> make[2]: stopped in /usr/obj/usr/src/amd64.a
> make[2]: stopped in /usr/obj/usr/src/amd64.a
>
>
>
>
>
> --
> Scott Kenney >|< sa...@coderd.rmta.org
> "Let's exchange the experience" - KB
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: can't handle raw ops yet!!!

[Matthew Macy]

Expected. I'm working on it. It's just a friendly reminder when
INVARIANTS is enabled.

On Thu, Aug 27, 2020 at 11:17 AM Yuri Pankov  wrote:
>
> After OpenZFS merge, during boot I'm getting several occurrences of what
> seems to be the following:
>
> http://src.illumos.org/source/xref/freebsd-head/sys/contrib/openzfs/module/os/freebsd/spl/spl_kstat.c#207
>
> And, yes, I'm running GENERIC, so with INVARIANTS.
>
> Should I be worried?
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenZFS support merged

[Matthew Macy]

On Tue, Aug 25, 2020 at 9:36 AM Danilo Egêa Gondolfo  wrote:
>
> On Tue, Aug 25, 2020 at 3:39 AM Matthew Macy  wrote:
>>
>> r364746 merged OpenZFS support in to HEAD.
>>
>> The change should be transparent unless you want to use new features.
>> I caution against 'zpool upgrade' for the next few weeks.
>>
>> https://svnweb.freebsd.org/base?view=revision=364746
>>
>> If you encounter problems please report them to me, Ryan Moeller, and 
>> -current.
>> ___
>> freebsd-hack...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
>
> Hi, that is good news.
>
> It seems that our boot loader will fail to boot after zpool upgrade. Is that 
> a known issue?

No. Unfortunately zstd support was merged in to openzfs very late in
the CFT. Features needed for read like zstd need to be white listed in
the loader and added to the support.

-M


> I've replicated my setup, root zfs over GELI, in a VM to avoid any surprise 
> (phew!), and it booted fine after upgrading the system. Although it fails 
> after zpool upgrade (yes, I know you've asked us to be cautious with zpool 
> upgrade):
>
> ZFS: unsupported feature: org.freebsd:zstd_compress
> ZFS: pool zroot is not supported
> ZFS: can't find pool by guid
>
> Thank you!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

OpenZFS support merged

[Matthew Macy]

r364746 merged OpenZFS support in to HEAD.

The change should be transparent unless you want to use new features.
I caution against 'zpool upgrade' for the next few weeks.

https://svnweb.freebsd.org/base?view=revision=364746

If you encounter problems please report them to me, Ryan Moeller, and -current.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT for vendor openzfs - week 5 reminder + memdisk images

[Matthew Macy]

> # kldload zfs
> can't handle raw ops yet!!!
> can't handle raw ops yet!!!
> can't handle raw ops yet!!!
> ZFS filesystem version: 5
> ZFS storage pool version: features support 5000
> can't handle raw ops yet!!!

I'm working on it - Ryan reminded me of it today. It will probably get
fixed before the merge. KSTAT_TYPE_RAW isn't supported in legacy ZFS,
so strictly speaking it's not a regression (apart from the annoying
reminder on debug kernels).
-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT for vendor openzfs - week 5 reminder + memdisk images

[Matthew Macy]

>
> Hi. I have some problems downloading the amd64 image:
>
> baymax /home/djn > fetch -a
> https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz
> freebsd-openzfs-amd64-2020081100-memstick.img. 19% of  655 MB 2179 kBps 04m07s
> fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be
> truncated: 134152192/687158140 bytes
> baymax /home/djn > fetch -ar
> https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz
> freebsd-openzfs-amd64-2020081100-memstick.img. 20% of  655 MB  882 kBps 09m10s
> fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be
> truncated: 139132928/687158140 bytes
> baymax /home/djn > fetch -ar
> https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/freebsd-openzfs-amd64-2020081100-memstick.img.xz
> freebsd-openzfs-amd64-2020081100-memstick.img. 20% of  655 MB  647 kBps 12m23s
> fetch: freebsd-openzfs-amd64-2020081100-memstick.img.xz appears to be
> truncated: 142065664/687158140 bytes
> baymax /home/djn >
>
> It also fails using Firefox on windows on a different machine. (It's
> also much slower from that machine, about 200 kB/sec. I have no idea
> if that's relevant.)

Yes, this appears to have been going on for at least the last week.
The FreeBSD infrastructure directly available to developers appears to
be unreliable for serving large files. Individuals with accounts on
freefall have been able to scp the files. It's possible that we may
just end up sharing images more widely by way of releng generated
images after commit. I'll see if there's an alternative for the last
week of the CFT.

Cheers.
-M

>
> --
> Daniel Nebdal
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

CFT for vendor openzfs - week 5 reminder + memdisk images

[Matthew Macy]

On Wednesday, July 8th I issued the initial call for testing for the
update to HEAD to vendored openzfs. We'd like to give users roughly a
month to test before merging.  The tentative merge date is August
17th.

Again, I hope it's not terribly controversial to point out that
it really rests with users of non amd64 platforms to test to avoid any
unpleasant surprises the next time they update their trees following
the merge.

amd64, i386, and aarch64 memdisk images can be found at:
https://people.freebsd.org/~freqlabs/freebsd-openzfs/latest/

If you're using a platform not listed above and would be inclined to
test if you had an image to work with, let us know. Alternatively, you
can still build following the instructions below.

The review for merging in to base can be found at:
https://reviews.freebsd.org/D25872

==
NB: Do NOT zpool upgrade unless you are willing to live without the
ability to ever rollback to the legacy zfs kmod.

Checkout updated HEAD:
% git clone https://github.com/mattmacy/networking.git -b
projects/openzfs_vendor freebsd

Checkout updated openzfs in to sys/contrib:
% git clone https://github.com/zfsonfreebsd/ZoF.git -b
projects/openzfs_vendor freebsd/sys/contrib/openzfs

Build world and kernel with whatever your usual configuration is.
Where possible the openzfs kmod is backward compatible with the cmd
utils in HEAD so common operations work with existing tools and the
new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries
are backward compatible with the zfs kmod in HEAD. Although ideally
one would test this in a separate boot environment, the
interoperability should allow one to rollback without too much
difficulty.

NB: The patch updates /etc/rc.d/zfs - so if you skip mergemaster pools
other than the root pool will not be imported at boot.

Thanks in advance for your time.

-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT for vendor openzfs - week 4 reminder + memdisk images

[Matthew Macy]

On Wed, Jul 29, 2020 at 20:16 Chris  wrote:

> On Tue, 28 Jul 2020 21:16:28 -0700 Matthew Macy mm...@freebsd.org said
>
> > On Tue, Jul 28, 2020 at 21:06 Chris  wrote:
> >
> > > On Tue, 28 Jul 2020 20:50:33 -0700 Matthew Macy mm...@freebsd.org said
> > >
> > > > On Tue, Jul 28, 2020 at 20:43 Chris  wrote:
> > > >
> > > > > On Tue, 28 Jul 2020 20:08:33 -0700 Matthew Macy mm...@freebsd.org
> said
> > > > >
> > > > > > On Tue, Jul 28, 2020 at 8:03 PM Chris 
> > > wrote:
> > > > > > >
> > > > > > > On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy
> mm...@freebsd.org
> > > said
> > > > > > >
> > > > > > > > On Wednesday, July 8th I issued the initial call for testing
> for
> > > the
> > > > > > > > update to HEAD to vendored openzfs. We'd like to give users
> > > roughly a
> > > > > > > > month to test before merging.  The tentative merge date is
> August
> > > > > > > > 17th.
> > > > > > > >
> > > > > > > > Again, I hope it's not terribly controversial to point out
> that
> > > > > > > > it really rests with users of non amd64 platforms to test to
> > > avoid
> > > > > any
> > > > > > > > unpleasant surprises the next time they update their trees
> > > following
> > > > > > > > the merge.
> > > > > > > >
> > > > > > > > amd64, i386, and aarch64 memdisk images can be found at:
> > > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
> https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/
> > > > > > >
> > > > > > > Is this in an attempt to replace the opensolaris version used
> now?
> > > > > >
> > > > > > The word "attempt" is a misnomer. If you search the mail archives
> > > this
> > > > > > has been the PoR for some time.
> > > > > Sure. OK. I caught this thread. But must have missed the
> announcement
> > > > > of the intent to replace the opensolaris version with openzfs.
> > > > > Do you recall which mailing list that was made to?
> > > > >
> > > > > Thank you for your quick reply, Matthew.
> > > > >
> > > >
> > > > Apart from the 3 previous CFT mails, the initial intent was
> discussed in
> > > > December 2018. Getting FreeBSD support integrated in to openzfs took
> a
> > > lot
> > > > more incremental PRs than I anticipated.
> > > >
> > > >
> > >
> > >
> https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072422.html
> > >
> > > Thank you very much, Mathew. Sorry for any bother.
> > >
> >
> >
> > No bother or not much at least. It’s just been a long haul and I’d like
> > to
> > wrap this up.
> No doubt.
> FTR I'm not looking to impede you. :-)
> My only concern would be that I'd need to remaster the art of ZFS. I've
> got 1500 installs to maintain, and any changes tend to alarm me. :-)
> I see we're a bit behind the others, if this status report is current:
>
> https://docs.google.com/spreadsheets/d/1CFapSYxA5QRFYy5k6ge3FutU7zbAWbaeGN2nKVXgxCI/edit#gid=0
> Will your impending commit move us closer? Is there anything others
> like myself can do to help?


Close to 90% of the sources files in openzfs are shared between Linux and
FreeBSD. So the features will, give or take a line item, be the same. For
non developers the main thing they can do to help out is to run it in their
own environments to identify any changes in behavior or regressions. If
you’re doing 1500 installs it’s in your best interest to make this as
smooth a transition as possible. However, it’s not something you’re going
to face until you move to 13. The openzfs port is available to those who
want to run it on 12.

-M

>
>
> Thanks again, Matthew.
>
> --Chris
> >
> > -M
> >
> > >
>
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT for vendor openzfs - week 4 reminder + memdisk images

[Matthew Macy]

On Tue, Jul 28, 2020 at 21:06 Chris  wrote:

> On Tue, 28 Jul 2020 20:50:33 -0700 Matthew Macy mm...@freebsd.org said
>
> > On Tue, Jul 28, 2020 at 20:43 Chris  wrote:
> >
> > > On Tue, 28 Jul 2020 20:08:33 -0700 Matthew Macy mm...@freebsd.org said
> > >
> > > > On Tue, Jul 28, 2020 at 8:03 PM Chris 
> wrote:
> > > > >
> > > > > On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mm...@freebsd.org
> said
> > > > >
> > > > > > On Wednesday, July 8th I issued the initial call for testing for
> the
> > > > > > update to HEAD to vendored openzfs. We'd like to give users
> roughly a
> > > > > > month to test before merging.  The tentative merge date is August
> > > > > > 17th.
> > > > > >
> > > > > > Again, I hope it's not terribly controversial to point out that
> > > > > > it really rests with users of non amd64 platforms to test to
> avoid
> > > any
> > > > > > unpleasant surprises the next time they update their trees
> following
> > > > > > the merge.
> > > > > >
> > > > > > amd64, i386, and aarch64 memdisk images can be found at:
> > > > > >
> > > > >
> > >
> > >
> https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/
> > > > >
> > > > > Is this in an attempt to replace the opensolaris version used now?
> > > >
> > > > The word "attempt" is a misnomer. If you search the mail archives
> this
> > > > has been the PoR for some time.
> > > Sure. OK. I caught this thread. But must have missed the announcement
> > > of the intent to replace the opensolaris version with openzfs.
> > > Do you recall which mailing list that was made to?
> > >
> > > Thank you for your quick reply, Matthew.
> > >
> >
> > Apart from the 3 previous CFT mails, the initial intent was discussed in
> > December 2018. Getting FreeBSD support integrated in to openzfs took a
> lot
> > more incremental PRs than I anticipated.
> >
> >
> https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072422.html
>
> Thank you very much, Mathew. Sorry for any bother.
>


No bother or not much at least. It’s just been a long haul and I’d like to
wrap this up.

-M

>
> --Chris
> >
> > Cheers.
> >
> >
>
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT for vendor openzfs - week 4 reminder + memdisk images

[Matthew Macy]

On Tue, Jul 28, 2020 at 20:43 Chris  wrote:

> On Tue, 28 Jul 2020 20:08:33 -0700 Matthew Macy mm...@freebsd.org said
>
> > On Tue, Jul 28, 2020 at 8:03 PM Chris  wrote:
> > >
> > > On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mm...@freebsd.org said
> > >
> > > > On Wednesday, July 8th I issued the initial call for testing for the
> > > > update to HEAD to vendored openzfs. We'd like to give users roughly a
> > > > month to test before merging.  The tentative merge date is August
> > > > 17th.
> > > >
> > > > Again, I hope it's not terribly controversial to point out that
> > > > it really rests with users of non amd64 platforms to test to avoid
> any
> > > > unpleasant surprises the next time they update their trees following
> > > > the merge.
> > > >
> > > > amd64, i386, and aarch64 memdisk images can be found at:
> > > >
> > >
> https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/
> > >
> > > Is this in an attempt to replace the opensolaris version used now?
> >
> > The word "attempt" is a misnomer. If you search the mail archives this
> > has been the PoR for some time.
> Sure. OK. I caught this thread. But must have missed the announcement
> of the intent to replace the opensolaris version with openzfs.
> Do you recall which mailing list that was made to?
>
> Thank you for your quick reply, Matthew.
>

Apart from the 3 previous CFT mails, the initial intent was discussed in
December 2018. Getting FreeBSD support integrated in to openzfs took a lot
more incremental PRs than I anticipated.

https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072422.html

Cheers.


> --Chris
> >
> > >
>
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT for vendor openzfs - week 4 reminder + memdisk images

[Matthew Macy]

On Tue, Jul 28, 2020 at 8:03 PM Chris  wrote:
>
> On Tue, 28 Jul 2020 19:10:21 -0700 Matthew Macy mm...@freebsd.org said
>
> > On Wednesday, July 8th I issued the initial call for testing for the
> > update to HEAD to vendored openzfs. We'd like to give users roughly a
> > month to test before merging.  The tentative merge date is August
> > 17th.
> >
> > Again, I hope it's not terribly controversial to point out that
> > it really rests with users of non amd64 platforms to test to avoid any
> > unpleasant surprises the next time they update their trees following
> > the merge.
> >
> > amd64, i386, and aarch64 memdisk images can be found at:
> > https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/
>
> Is this in an attempt to replace the opensolaris version used now?

The word "attempt" is a misnomer. If you search the mail archives this
has been the PoR for some time.

>
> Thanks.
>
> --Chris
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

CFT for vendor openzfs - week 4 reminder + memdisk images

[Matthew Macy]

On Wednesday, July 8th I issued the initial call for testing for the
update to HEAD to vendored openzfs. We'd like to give users roughly a
month to test before merging.  The tentative merge date is August
17th.

Again, I hope it's not terribly controversial to point out that
it really rests with users of non amd64 platforms to test to avoid any
unpleasant surprises the next time they update their trees following
the merge.

amd64, i386, and aarch64 memdisk images can be found at:
https://people.freebsd.org/~freqlabs/freebsd-openzfs-3d833bea-f10f94aa-2020072900/

If you're using a platform not listed above and would be inclined to
test if you had an image to work with, let us know. Alternatively, you
can still build following the instructions below.

The review for merging in to base can be found at:
https://reviews.freebsd.org/D25872

==
NB: Do NOT zpool upgrade unless you are willing to live without the
ability to ever rollback to the legacy zfs kmod.

Checkout updated HEAD:
% git clone https://github.com/mattmacy/networking.git -b
projects/openzfs_vendor freebsd

Checkout updated openzfs in to sys/contrib:
% git clone https://github.com/zfsonfreebsd/ZoF.git -b
projects/openzfs_vendor freebsd/sys/contrib/openzfs

Build world and kernel with whatever your usual configuration is.
Where possible the openzfs kmod is backward compatible with the cmd
utils in HEAD so common operations work with existing tools and the
new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries
are backward compatible with the zfs kmod in HEAD. Although ideally
one would test this in a separate boot environment, the
interoperability should allow one to rollback without too much
difficulty.

Thanks in advance for your time.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

CFT for vendor openzfs - week 3 reminder

[Matthew Macy]

On Wednesday, July 8th I issued the initial call for testing for the
update to HEAD to vendored openzfs. We'd like to give users roughly a
month to test before merging. I'm pushing the tentative merge date out
by a week to August 17th as I wasn't able to spend any time working on
this myself last week.

Again, I hope it's not terribly controversial to point out that
it really rests with users of non amd64 platforms to test to avoid any
unpleasant surprises the next time they update their trees following
the merge.

==
NB: Do NOT zpool upgrade unless you are willing to live without the
ability to ever rollback to the legacy zfs kmod.

Checkout updated HEAD:
% git clone https://github.com/mattmacy/networking.git -b
projects/openzfs_vendor freebsd

Checkout updated openzfs in to sys/contrib:
% git clone https://github.com/zfsonfreebsd/ZoF.git -b
projects/openzfs_vendor freebsd/sys/contrib/openzfs

Build world and kernel with whatever your usual configuration is.
Where possible the openzfs kmod is backward compatible with the cmd
utils in HEAD so common operations work with existing tools and the
new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries
are backward compatible with the zfs kmod in HEAD. Although ideally
one would test this in a separate boot environment, the
interoperability should allow one to rollback without too much
difficulty.

Thanks in advance for your time.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFT for vendor openzfs - week 2 reminder

[Matthew Macy]

To help us keep track, please file an issue
https://github.com/zfsonfreebsd/zof/issues

Thanks.

On Mon, Jul 13, 2020 at 3:39 PM Evilham  wrote:
>
> On dl., jul. 13 2020, Kyle Evans wrote:
>
> > On Mon, Jul 13, 2020 at 12:27 PM Matthew Macy
> >  wrote:
> >>
> >> On Wednesday, July 8th I issued the initial call for testing
> >> for the
> >> update to HEAD to vendored openzfs. We'd like to give users
> >> roughly a
> >> month to test before merging. The current *tentative* merge
> >> date is
> >> August 10th. I hope it's not terribly controversial to point
> >> out that
> >> it really rests with users of non amd64 platforms to test to
> >> avoid any
> >> unpleasant surprises the next time they update their trees
> >> following
> >> the merge.
> >>
> >
> > I've had no problems with this on a couple amd64 systems; I did
> > note
> > that my loader.conf's needed a good
> > s/vfs.zfs.arc_max/vfs.zfs.arc.max/
> > but I'm told a compat sysctl is on the TODO list to ease the
> > transition.
>
>
> I've also been using this on amd64 for a few days without any
> issues, it's even fixed a bug I've been trying to figure out:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247544
>
> I have noticed a thing though:
>
> Previously observed behaviour:
> 1. A new zpool is made available (e.g. geli attach)
> 2. The zpool is imported
> 3. Something happens (e.g. system reboot) and the zpool is not
> available anymore but also not exported
> 4. The zpool is made available again
> 5. The zpool is *still* imported
> 6. The zpool must be manually mounted
>
> With the patches for OpenZFS, number 5 and 6 are instead:
> 5. The data zpool is not imported
> 6. The zpool must be manually re-imported
>
> It is different behaviour, but I am very unsure about whether or
> not that is to be considered a bug and needs a PR.
> --
> Evilham
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

CFT for vendor openzfs - week 2 reminder

[Matthew Macy]

On Wednesday, July 8th I issued the initial call for testing for the
update to HEAD to vendored openzfs. We'd like to give users roughly a
month to test before merging. The current *tentative* merge date is
August 10th. I hope it's not terribly controversial to point out that
it really rests with users of non amd64 platforms to test to avoid any
unpleasant surprises the next time they update their trees following
the merge.

==
NB: Do NOT zpool upgrade unless you are willing to live without the
ability to ever rollback to the legacy zfs kmod.

Checkout updated HEAD:
% git clone https://github.com/mattmacy/networking.git -b
projects/openzfs_vendor freebsd

Checkout updated openzfs in to sys/contrib:
% git clone https://github.com/zfsonfreebsd/ZoF.git -b
projects/openzfs_vendor freebsd/sys/contrib/openzfs

Build world and kernel with whatever your usual configuration is.
Where possible the openzfs kmod is backward compatible with the cmd
utils in HEAD so common operations work with existing tools and the
new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries
are backward compatible with the zfs kmod in HEAD. Although ideally
one would test this in a separate boot environment, the
interoperability should allow one to rollback without too much
difficulty.

Thanks in advance for your time.

-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Further note - Re: CFT for vendor openzfs

[Matthew Macy]

Do NOT zpool upgrade unless you are willing to live without the
ability to ever rollback to the legacy zfs kmod.

On Wed, Jul 8, 2020 at 2:31 PM Matthew Macy  wrote:
>
> Checkout updated HEAD:
> % git clone https://github.com/mattmacy/networking.git -b
> projects/openzfs_vendor freebsd
>
> Checkout updated openzfs in to sys/contrib:
> % git clone https://github.com/zfsonfreebsd/ZoF.git -b
> projects/openzfs_vendor freebsd/sys/contrib/openzfs
>
> Build world and kernel with whatever your usual configuration is.
> Where possible the openzfs kmod is backward compatible with the cmd
> utils in HEAD so common operations work with existing tools and the
> new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries
> are backward compatible with the zfs kmod in HEAD. Although ideally
> one would test this in a separate boot environment, the
> interoperability should allow one to rollback without too much
> difficulty.
>
> Thanks in advance for your time.
> -M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

CFT for vendor openzfs

[Matthew Macy]

Checkout updated HEAD:
% git clone https://github.com/mattmacy/networking.git -b
projects/openzfs_vendor freebsd

Checkout updated openzfs in to sys/contrib:
% git clone https://github.com/zfsonfreebsd/ZoF.git -b
projects/openzfs_vendor freebsd/sys/contrib/openzfs

Build world and kernel with whatever your usual configuration is.
Where possible the openzfs kmod is backward compatible with the cmd
utils in HEAD so common operations work with existing tools and the
new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries
are backward compatible with the zfs kmod in HEAD. Although ideally
one would test this in a separate boot environment, the
interoperability should allow one to rollback without too much
difficulty.

Thanks in advance for your time.
-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r362666 breaking buildworld (don't know how to make nvpair.c) & Fix/Patch

[Matthew Macy]

Well -  it was from his review.

On Fri, Jun 26, 2020 at 8:00 PM Enji Cooper  wrote:
>
> (Moving hackers to BCC since the issue is current-related)
>
> > On Jun 26, 2020, at 6:56 PM, Neel Chauhan  wrote:
> >
> > Hi,
> >
> > When I attempt to build world in 13-CURRENT, I get this error:
>
> …
>
> > The build broke with mmacy@'s commit r362666 which renamed nvpair.c to 
> > bsd_nvpair.c without renaming the Makefile.
>
> ...
>
> Hi Neel,
> It looks like the issue was recently fixed in r362669 by mmacy.
> Cheers!
> -Enji
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Fwd: iflib and options RSS is a no go for igbX

[Matthew Macy]

>
> I can go setup my second PC this week (I have PTO!) and go see if I
> have any PCIe igb hardware here. I /think/ I do but it's fibre.

The RSS compile time option used to be disabled in part because of
this. The drivers had working RSS that relied on packet receipt before
setting flowid.
-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: vfs.zfs.min_auto_ashift and OpenZFS

[Matthew Macy]

OpenZFS doesn't have the same ashift optimization logic that FreeBSD
has. It's something that needs to be resolved before the code can be
integrated downstream.

-M

On Fri, May 1, 2020 at 11:04 AM Graham Perrin  wrote:
>
> In my sysctl.conf:
>
> vfs.zfs.min_auto_ashift=12
>
> – if I recall correctly, the line was written automatically when I
> installed FreeBSD-CURRENT a year or so ago.
>
> With OpenZFS enabled:
>
> root@momh167-gjp4-8570p:~ # sysctl vfs.zfs.min_auto_ashift
> sysctl: unknown oid 'vfs.zfs.min_auto_ashift'
>
> Should I have a different line in sysctl.conf, or is
> vfs.zfs.min_auto_ashift not required with OpenZFS?
>
> Hardware: HP EliteBook 8570p, circa 2013
> 
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OpenZFS port updated

[Matthew Macy]

On Fri, Apr 17, 2020 at 1:16 PM Scott Long  wrote:
>
> Is the intention to eventually replace the zfs code in src/ ?

Yes. Once the feature gap is filled in and most of the potential POLA
violations are fixed.

> What will be the long-term relationship between src/ and ports/ for this?

OpenZFS users on 12 will use the port indefinitely. HEAD will
presumably be updated whenever a point release is created upstream.
Ultimately I can see two versions of the port, one that tracks master
for HEAD and 12 and one that tracks only the latest release for 12
users.
-M

>
> Scott
>
>
> > On Apr 17, 2020, at 12:35 PM, Ryan Moeller  wrote:
> >
> > FreeBSD support has been merged into the master branch of the openzfs/zfs 
> > repository, and the FreeBSD ports have been switched to this branch.
> >
> > OpenZFS brings many exciting features to FreeBSD, including:
> > * native encryption
> > * improved TRIM implementation
> > * most recently, persistent L2ARC
> >
> > Of course, avoid upgrading your pools if you want to keep the option to go 
> > back to the base ZFS.
> >
> > OpenZFS can be installed alongside the base ZFS. Change your loader.conf 
> > entry to openzfs_load=“YES” to load the OpenZFS module at boot, and set 
> > PATH to find the tools in /usr/local/sbin before /sbin. The base zfs tools 
> > are still basically functional with the OpenZFS module, so changing PATH in 
> > rc is not strictly necessary.
> >
> > The FreeBSD loader can boot from pools with the encryption feature enabled, 
> > but the root/bootenv datasets must not be encrypted themselves.
> >
> > The FreeBSD platform support in OpenZFS does not yet include all features 
> > present in FreeBSD’s ZFS. Some notable changes/missing features include:
> > * many sysctl names have changed (legacy compat sysctls should be added at 
> > some point)
> > * zfs send progress reporting in process title via setproctitle
> > * extended 'zfs holds -r' 
> > (https://svnweb.freebsd.org/base?view=revision=290015)
> > * vdev ashift optimizations 
> > (https://svnweb.freebsd.org/base?view=revision=254591)
> > * pre-mountroot zpool.cache loading (for automatic pool imports)
> >
> > To the last point, this mainly effects the case where / is on ZFS and /boot 
> > is not or is on a different pool. OpenZFS cannot handle this case yet, but 
> > work is in progress to cover that use case. Booting directly from ZFS does 
> > work.
> >
> > If there are pools that need to be imported at boot other than the boot 
> > pool, OpenZFS does not automatically import yet, and it uses 
> > /etc/zfs/zpool.cache rather than /boot/zfs/zpool.cache to keep track of 
> > imported pools.  To ensure all pool imports occur automatically, a simple 
> > edit to /etc/rc.d/zfs will suffice:
> >
> > diff --git a/libexec/rc/rc.d/zfs b/libexec/rc/rc.d/zfs
> > index 2d35f9b5464..8e4aef0b1b3 100755
> > --- a/libexec/rc/rc.d/zfs
> > +++ b/libexec/rc/rc.d/zfs
> > @@ -25,6 +25,13 @@ zfs_start_jail()
> >
> > zfs_start_main()
> > {
> > + local cachefile
> > +
> > + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do
> > + if [ -f $cachefile ]; then
> > + zpool import -c $cachefile -a
> > + fi
> > + done
> >   zfs mount -va
> >   zfs share -a
> >   if [ ! -r /etc/zfs/exports ]; then
> >
> > This will probably not be needed long-term. It is not necessary if the boot 
> > pool is the only pool.
> >
> > Happy testing :)
> >
> > - Ryan
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: what 3rd party boot mgr is required to boot multiple freebsd versions?

[Matthew Seaman]

On 17/03/2020 12:58, Florian Limberger wrote:
> On 16.03.20 23:33, Chris wrote:
> 
>> For the record. I'm *only* using FreeBSD in this situation. I
>> only mentioned Windows above, for the use of it's boot manager.
> 
> If you only use FreeBSD, and also use ZFS, you might find beadm[1]
> interesting.
> 
> [1]: https://www.freshports.org/sysutils/beadm
> 

Did you know that the system now comes with bectl(8) which is very
similar to beadm?  As far as I can tell, the biggest difference is that
if you have more than one ZFS in your boot environment then:

beadm create FOO

is actually equivalent to

bectl create -r FOO

ie. turning on the recursive functionality in bectl.

However, this is not really what the OP was asking about.  As I
understand it, they were looking for something that would allow choosing
between several independent installations of different versions of
FreeBSD, rather than having multiple environments in the same
installation.  You can achieve pretty much the same effect though --
there is a boot menu option to switch between BEs.  You would have to
manage any ported software between the different OS versions, perhaps by
including /usr/local and /var/db/pkg are both parts of your BEs.

Cheers,

Matthew



signature.asc
Description: OpenPGP digital signature

Re: Pkg repository is broken...

[Matthew Seaman]

On 07/03/2020 22:38, Greg 'groggy' Lehey wrote:
>> This was only an issue on the "latest" branch. If you don't alter
>> "/etc/pkg/FreeBSD.conf", you'll get packages from the "quarterly"
>> branch, which fortunately wasn't affected.

> No, this isn't necessarily correct.  I have never modified this file,
> but I ended up with a copy of /usr/src/usr.bin/pkg/FreeBSD.conf.latest
> with this revision string:
> 
>   # $FreeBSD: stable/11/etc/pkg/FreeBSD.conf 263937 2014-03-30 15:24:17Z 
> bdrewery $
> 
> Despite the age, this appears to identical to the current version,
> according to svn blame.  Arguably this should be the default anyway.
> 

Best practice is *not* to modify /etc/pkg/FreeBSD.conf, but to create a
supplemental file /usr/local/etc/pkg/repos/FreeBSD.conf to override any
of the default settings.

So, for example, this in /usr/local/etc/pkg/repos/FreeBSD.conf will
switch to the 'latest' package set:

```
FreeBSD: { url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest; }
```

and this will disable the FreeBSD pkg repos entirely:

```
FreeBSD: { enabled: no }
```

(presumably with an additional .../pkg/repos/foo.conf file to enable a
custom local repository)

The best way to confirm exactly what the resultant pkg(8) configuration
comes out as is by:

   pkg -vv

Cheers,

Matthew



signature.asc
Description: OpenPGP digital signature

Re: kernel module code coverage

[Matthew Macy]

On Thu, Dec 5, 2019 at 8:38 AM Ed Maste  wrote:
>
> > > Have you looked into /dev/kcov. This is used by SYZKALLER for getting
> > > coverage information from the kernel.
> > >
> > That's part of Matt Macy's gcov project, right?.
>
> No, /dev/kcov is independent of, and predates, Matt Macy's work. It
> provides broadly the same sort of information, but not using the same
> interface.

GCOV also depends on GCC - probably limiting its potential use cases
largely to vendor CI.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel module code coverage

[Matthew Macy]

The whole point of adding gcov support was for integrating with the
ZoL CI framework which does coverage. So it very much does work with
modules. Not sure where that comes from.
-M

On Thu, Aug 8, 2019 at 6:52 AM Alan Somers  wrote:
>
> On Thu, Aug 8, 2019 at 7:42 AM Michael Tuexen  wrote:
> >
> >
> >
> > > On 8. Aug 2019, at 14:24, Slava Shwartsman  wrote:
> > >
> > > Apparently, Bullseye are dropping support for FreeBSD.
> > >
> > > We are looking for an alternative for kernel module run time analysis.
> > > Mostly interested in code coverage (for now).
> > >
> > > Any suggestions that work for you?
> > Have you looked into /dev/kcov. This is used by SYZKALLER for getting
> > coverage information from the kernel.
> >
> > Best regards
> > Michael
> > >
> > >
> > > Slava
>
> That's part of Matt Macy's gcov project, right?.  However, while it
> works for the kernel itself, it doesn't work for modules.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239194
> -Alan
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

[Matthew Macy]

On Tue, Oct 8, 2019 at 15:01 Julian Elischer  wrote:

> On 10/8/19 2:42 PM, Walter Parker wrote:
> > See the Wikipedia page at https://en.wikipedia.org/wiki/Unix_time
>
> but I was refering to the new "epoch" faciity in the kernel..  ( man 9
> epoch  )




That’s what one would assume given that the thread started with a panic in
said system. Epoch is built on concurrency kit’s EBR implementation. Hence
the link I shared.


>
>
> https://www.freebsd.org/cgi/man.cgi?query=epoch=0=9=FreeBSD+13-current=default=html
>
>
> >
> >
> > Walter
> >
> > On Tue, Oct 8, 2019 at 2:37 PM Julian Elischer  > > wrote:
> >
> > Is there a paper or good description of the epoch concept? (more
> > readable than epoch(9)).
> > Haven't been to enough BSD confs recently.
> >
> > julian
> > ___
> > freebsd-current@freebsd.org 
> > mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to
> > "freebsd-current-unsubscr...@freebsd.org
> > "
> >
> >
> >
> > --
> > The greatest dangers to liberty lurk in insidious encroachment by
> > men of zeal, well-meaning but without understanding.   -- Justice
> > Louis D. Brandeis
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

[Matthew Macy]

On Tue, Oct 8, 2019 at 14:42 Walter Parker  wrote:

> See the Wikipedia page at https://en.wikipedia.org/wiki/Unix_time
>
>

Unrelated.
http://concurrencykit.org/slides.html

And see also Keir Fraser’s thesis where the idea originated.

>
> Walter
>
> On Tue, Oct 8, 2019 at 2:37 PM Julian Elischer  wrote:
>
> > Is there a paper or good description of the epoch concept? (more
> > readable than epoch(9)).
> > Haven't been to enough BSD confs recently.
> >
> > julian
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
> >
>
>
> --
> The greatest dangers to liberty lurk in insidious encroachment by men of
> zeal, well-meaning but without understanding.   -- Justice Louis D.
> Brandeis
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg: Cannot open /dev/null:No such file or directory

[Matthew Seaman]

On 04/06/2019 06:32, O. Hartmann wrote:
> As far as I know,, the package installation is performed via "chroot'ed"
> environment and somehow /dev/null is out of a sudden not accessible anymore
> while pkg tries to delegate some output to /dev/null.

Assuming you're chroot'd to /chroot, then:

mount -t devfs devfs /chroot/dev

should allow pkg(8) to work as usual.

    Cheers,

Matthew



signature.asc
Description: OpenPGP digital signature

Re: New vm-image size is much smaller than previos

[Matthew Seaman]

On 03/05/2019 17:10, David Boyd wrote:

The vm-image for 13.0-CURRENT

 FreeBSD-13.0-CURRENT-amd64-20190503-r347033.vmdk

is only 4.0 GB in size.  Previous images were about 31.0 GB.

This smaller image doesn't leave much room to add packages and other
customizations.



Yes, the VM images are smaller, and deliberately so.  The idea is that 
the image is basically shrunk to the minimum size -- just big enough to 
hold a standard install.  Then when you deploy one of these images, you 
allocate a virtual drive of whatever size you need, and growfs(8) your 
filesystems (if using UFS) or allow your vdevs to expand to fill the 
space available (if using ZFS).  This allows you to build a system of 
pretty much any feasible size and parallels the behaviour of eg. the 
AMIs available for AWS.


Cheers,

Matthew
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS no longer mounted in alphanumerical order

[Matthew Ahrens]

On Mon, Mar 11, 2019 at 11:33 AM Trond Endrestøl <
trond.endres...@fagskolen.gjovik.no> wrote:

> Has anyone else noticed ZFS datasets are no longer mounted in
> alphanumerical order in CURRENT? It looks more like they are mounted
> in the order in which they are encountered.
>

Wouldn't surprise me if this was caused by the parallel mount changes.  The
filesystems should still be mounted in hierarchical order (parents before
children), so everything should still work. What problem are you seeing as
a result of the changed mount order?

--matt


>
> Are there any chance of reverting to the old behaviour?
>
> Here's an example:
>
> Filesystem SizeUsed   Avail Capacity  Mounted on
> zroot/ROOT/20190311-r3450136.8G1.7G5.1G25%/
> devfs  1.0K1.0K  0B   100%/dev
> zroot/usr/obj  5.1G 30K5.1G 0%/usr/obj
> zroot/usr/src  5.1G 30K5.1G 0%/usr/src
> zroot/home 5.1G 30K5.1G 0%/home
> zroot/usr/ports5.1G 30K5.1G 0%/usr/ports
> zroot/tmp  5.1G 51K5.1G 0%/tmp
> zroot/usr/ports/packages   5.1G 30K5.1G 0%
> /usr/ports/packages
> zroot/usr/ports/workdirs   5.1G 30K5.1G 0%
> /usr/ports/workdirs
> zroot/usr/ports/local  5.1G 30K5.1G 0%
> /usr/ports/local
> zroot/usr/compat   5.1G 30K5.1G 0%/usr/compat
> zroot/usr/ports/distfiles  5.1G 30K5.1G 0%
> /usr/ports/distfiles
> zroot/var  5.1G 22M5.1G 0%/var
> zroot/nfs  5.1G 30K5.1G 0%/nfs
> zroot/media5.1G 31K5.1G 0%/media
> zroot/usr/local5.9G804M5.1G13%/usr/local
> zroot/usr/compat/linux 5.1G 31K5.1G 0%
> /usr/compat/linux
> zroot/var/db/ports 5.1G 30K5.1G 0%/var/db/ports
> zroot/var/lib  5.1G 30K5.1G 0%/var/lib
> zroot/usr/local/etc5.1G924K5.1G 0%
> /usr/local/etc
> zroot/var/empty5.1G 30K5.1G 0%/var/empty
> zroot/usr/local/pgsql  5.1G 30K5.1G 0%
> /usr/local/pgsql
> zroot/var/audit5.1G 30K5.1G 0%/var/audit
> zroot/var/backups  5.1G3.2M5.1G 0%/var/backups
> zroot/var/mail 5.1G 30K5.1G 0%/var/mail
> zroot/usr/local/certs  5.1G 30K5.1G 0%
> /usr/local/certs
> zroot/var/unbound  5.1G 30K5.1G 0%/var/unbound
> zroot/var/db/mysql 5.1G 30K5.1G 0%/var/db/mysql
> zroot/usr/local/www5.1G 30K5.1G 0%
> /usr/local/www
> zroot/usr/local/tests  5.1G 30K5.1G 0%
> /usr/local/tests
> zroot/var/db/boinc 5.1G 30K5.1G 0%/var/db/boinc
> zroot/var/Named5.1G 30K5.1G 0%/var/Named
> zroot/var/db/etcupdate 5.1G993K5.1G 0%
> /var/db/etcupdate
> zroot/var/db/hyperv5.1G 30K5.1G 0%
> /var/db/hyperv
> zroot/usr/local/var5.1G 30K5.1G 0%
> /usr/local/var
> zroot/var/crash5.1G 30K5.1G 0%/var/crash
> zroot/usr/local/info   5.1G 32K5.1G 0%
> /usr/local/info
> zroot/var/tmp  5.1G 30K5.1G 0%/var/tmp
> zroot/var/spool5.1G 81K5.1G 0%/var/spool
> zroot/var/log  5.1G8.7M5.1G 0%/var/log
> zroot/var/db/bacula5.1G 30K5.1G 0%
> /var/db/bacula
> zroot/var/run  5.1G 53K5.1G 0%/var/run
> zroot/var/cache/synth  5.1G801K5.1G 0%
> /var/cache/synth
> zroot/var/db/pkg   5.1G7.1M5.1G 0%/var/db/pkg
> zroot/var/synth5.1G 34K5.1G 0%/var/synth
> zroot/var/spool/ftp5.1G 30K5.1G 0%
> /var/spool/ftp
> zroot/var/synth/builders   5.1G 30K5.1G 0%
> /var/synth/builders
> fdescfs1.0K1.0K  0B   100%/dev/fd
> procfs 4.0K4.0K  0B   100%/proc
> devfs  1.0K1.0K  0B   100%
> /usr/compat/linux/dev
> fdescfs1.0K1.0K  0B   100%
> /usr/compat/linux/dev/fd
> linprocfs  4.0K4.0K  0B   100%
> /usr/compat/linux/proc
> linsysfs   4.0K4.0K  0B   100%
> /usr/compat/linux/sys
>
> --
> Trond.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 

Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"

[Matthew Macy]

I just updated world/kernel/ports to today's HEAD and packages  and
pkg "upgraded" chrome to be broken in this way. This isn't an isolated
issue.

On Tue, Jan 1, 2019 at 9:53 PM Matthias Apitz  wrote:
>
> El día viernes, diciembre 28, 2018 a las 12:55:32p. m. -0800, Cy Schubert 
> escribió:
>
> > In message  > il.com>
> > , Antoine Brodin writes:
> > > On Fri, Dec 28, 2018 at 8:39 PM Graham Perrin  
> > > wrote:
> > > >
> > > > On Fri, 28 Dec 2018 at 16:31, Emiel Kollof  
> > > > wrot
> > > e:
> > > >
> > > > > Confirmed with Chromium on my CURRENT box:
> > > >
> > > > …
> > > >
> > > > Thanks folks. Should I report it as a bug with devel/glib20?
> > >
> > > Hi,
> > >
> > > I think it's a regression in the toolchain (the problem doesn't occur
> > > on 11.2 or 12.0),  so it should be reported to freebsd-toolchain@
> >
> > No issue here however I rebuilt glib on Dec 21.
>
> I see the same with www/chromium on r342378 and ports, both from Dec 23.
>
> matthias
>
> --
> Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
> October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, 
> Druschba
> instead of Nazis, to live instead of to survive.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"

[Matthew Macy]

I just updated world/kernel/ports to today's HEAD and packages  and
pkg "upgraded" chrome to be broken in this way. This isn't an isolated
issue.

On Tue, Jan 1, 2019 at 9:55 PM Matthew Macy  wrote:
>
> I just updated world/kernel/ports to today's HEAD and packages  and
> pkg "upgraded" chrome to be broken in this way. This isn't an isolated
> issue.
>
> On Tue, Jan 1, 2019 at 9:53 PM Matthias Apitz  wrote:
> >
> > El día viernes, diciembre 28, 2018 a las 12:55:32p. m. -0800, Cy Schubert 
> > escribió:
> >
> > > In message  > > il.com>
> > > , Antoine Brodin writes:
> > > > On Fri, Dec 28, 2018 at 8:39 PM Graham Perrin  
> > > > wrote:
> > > > >
> > > > > On Fri, 28 Dec 2018 at 16:31, Emiel Kollof 
> > > > >  wrot
> > > > e:
> > > > >
> > > > > > Confirmed with Chromium on my CURRENT box:
> > > > >
> > > > > …
> > > > >
> > > > > Thanks folks. Should I report it as a bug with devel/glib20?
> > > >
> > > > Hi,
> > > >
> > > > I think it's a regression in the toolchain (the problem doesn't occur
> > > > on 11.2 or 12.0),  so it should be reported to freebsd-toolchain@
> > >
> > > No issue here however I rebuilt glib on Dec 21.
> >
> > I see the same with www/chromium on r342378 and ports, both from Dec 23.
> >
> > matthias
> >
> > --
> > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
> > Public GnuPG key: http://www.unixarea.de/key.pub
> > October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, 
> > Druschba
> > instead of Nazis, to live instead of to survive.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: bind 9.12.3-P1 dies after change of IP on outbound interface

[Matthew Luckie]

> Prior to the last update of dns/bind912, this router/firewall
> appliance was running more than a month without having such trouble,
> even the ISP is randomly changing the IPv4/IPv6 addresses spread
> over the day.
>
> What is wrong?

I am not sure what is wrong, but it seems like a bug in bind.

https://gitlab.isc.org/isc-projects/bind9/issues/777

Matthew

signature.asc
Description: PGP signature

Re: The future of ZFS in FreeBSD

[Matthew Macy]

On Thu, Dec 20, 2018 at 03:11 Eugene M. Zheganin  wrote:

> Hello,
>
> On 19.12.2018 23:32, Allan Jude wrote:
> > The biggest thing to remember is that this is still OpenZFS, and still
> > run by the same developers as it has been. We are just commonizing on
> > the repo that has the most features integrated into it.
>
> Does it mean that ZoF and thus FreeBSD will lose NFSv4 ACLs because
> there is no such thing in ZoL ?



No, but the ZTS will need to have ACL tests re-added. Please help out by
aiding in getting this merged:

https://github.com/zfsonlinux/zfs/pull/7728

Thanks.
-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: The future of ZFS in FreeBSD

[Matthew Macy]

On Thu, Dec 20, 2018 at 06:39 Alexey Dokuchaev  wrote:

> On Thu, Dec 20, 2018 at 03:49:38PM +0500, Eugene M. Zheganin wrote:
> > On 19.12.2018 23:32, Allan Jude wrote:
> > > The biggest thing to remember is that this is still OpenZFS, and still
> > > run by the same developers as it has been. We are just commonizing on
> > > the repo that has the most features integrated into it.
> >
> > Does it mean that ZoF and thus FreeBSD will lose NFSv4 ACLs because
> > there is no such thing in ZoL?


> +1.  I'm also worried if this would bring more Linuxish bits into our
> kernel (cf. LinuxKPI).  Also, I thought that ZFS was never really native
> to Linux but implemented through SPL (Solaris Porting Layer), and Linux'
> VFS is not ARC-aware unlike Solaris and FreeBSD.
>

There is no LinuxKPI involved here. Please re-read Allan’s comments on
directory structuring. No open source OS supporting ZFS has a VM subsystem
that is integrated with the ARC. The limited feedback that the ARC has from
FreeBSD’s VM will remain unchanged.



> It would be quite upsetting to see ZFS as we know it in FreeBSD become
> pessimized because of those things. :-(
>

ZFS will be no more pessimized than it currently is. Talk to mjg some time
about ZFS some time, there are ... scaling issues in its locking
strategies. Apart from that FreeBSD’s VFS itself has serious scaling. None
of this will get better or worse when we change the vendor repo we use for
integrating changes.

-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: The future of ZFS in FreeBSD

[Matthew Macy]

On Thu, Dec 20, 2018 at 9:33 AM Warner Losh  wrote:
>
>
> Matt,
>
> This is a fairly comprehensive plan. Kudos for putting it together.
>
> The big question here is do you have a complete list of FreeBSD-specific 
> changes that will be lost in the cut-over? We've heard about TRIM support and 
> maybe NFSv4, but are there others that can be identified?
>
> Once you have that list, it wouldn't be hard to throw the initial email with 
> some tweaks from the replies into a FCP so everybody knows the plan, and we 
> have it ratified in case people come along later and 'forget'.

The general intent is that we not lose anything. TRIM is the only
piece of code that really needs resolution upstream causing us to lose
it temporarily. Failure to upstream FreeBSD's TRIM support has been a
recurring source of bugs when integrating new features. As for NFSv4
I've forked the ACL bits in to the OS dependent code - I'll make a
note to make sure that nothing regresses there. This is yet another
example of why there will be a 3 month period for users to try the
port before we cut over.

-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: The future of ZFS in FreeBSD

[Matthew Macy]

On Wed, Dec 19, 2018 at 15:11 Steven Hartland 
wrote:

> Sorry been off for a few weeks so must have missed that, please do prod me
> on again if you don’t see any response to anything not just this. Like many
> others I get so may emails across so many lists it’s more than likely I
> just missed it.
>
> That said would you say that with the right support we can make progress
> on the this prior to the port? I have to ask as the alternative version has
> been on the cusp for many years now so it’s feels more like a distant
> memory than something that may happen, no disrespect to anyone involved, as
> I know all too well how hard it can be to get something like this over the
> line, especially when people have competing priorities.
>

I am hoping that it's sufficiently important to FreeBSD ZFS developers that
they'll give the PR the attention it needs so that it can be merged before
summer. My understanding is that it's mostly suffered from neglect. TRIM is
most important to FreeBSD and it already had its own implementation.

https://github.com/zfsonlinux/zfs/pull/5925

I forwarded you the private communication again as well.

-M


>
> On Wed, 19 Dec 2018 at 22:52, Matthew Macy  wrote:
>
>>
>>
>> On Wed, Dec 19, 2018 at 14:47 Steven Hartland 
>> wrote:
>>
>>> Thanks for the write up most appreciated. One of the more meaty
>>> differences is that FreeBSD ZFS still has the only merged and production
>>> ready TRIM support so my question would be are their any plans to address
>>> this before creating the new port as going back to a world without TRIM
>>> support wouldn’t be something I’d look forward to.
>>>
>>
>> Well, then please follow up on the request I CC'd you on a week ago
>> asking that you engage on the deadlist based TRIM  PR. That's a better
>> forum for discussing these details than lamenting in public lists.
>>
>> Thanks.
>>
>> -M
>>
>>
>>
>>
>>> On Wed, 19 Dec 2018 at 06:51, Matthew Macy  wrote:
>>>
>>>> The sources for FreeBSD's ZFS support are currently taken directly
>>>> from Illumos with local ifdefs to support the peculiarities of FreeBSD
>>>> where the Solaris Portability Layer (SPL) shims fall short. FreeBSD
>>>> has regularly pulled changes from Illumos and tried to push back any
>>>> bug fixes and new features done in the context of FreeBSD. In the past
>>>> few years the vast majority of new development in ZFS has taken place
>>>> in DelphixOS and zfsonlinux (ZoL). Earlier this year Delphix announced
>>>> that they will be moving to ZoL
>>>> https://www.delphix.com/blog/kickoff-future-eko-2018 This shift means
>>>> that there will be little to no net new development of Illumos. While
>>>> working through the git history of ZoL I have also discovered that
>>>> many races and locking bugs have been fixed in ZoL and never made it
>>>> back to Illumos and thus FreeBSD. This state of affairs has led to a
>>>> general agreement among the stakeholders that I have spoken to that it
>>>> makes sense to rebase FreeBSD's ZFS on ZoL. Brian Behlendorf
>>>> has graciously encouraged me to add FreeBSD support directly to ZoL
>>>> https://github.com/zfsonfreebsd/ZoF so that we might all have a single
>>>> shared code base.
>>>>
>>>> A port for ZoF can be found at https://github.com/miwi-fbsd/zof-port
>>>> Before it can be committed some additional functionality needs to be
>>>> added to the FreeBSD opencrypto framework. These can be found at
>>>> https://reviews.freebsd.org/D18520
>>>>
>>>> This port will provide FreeBSD users with multi modifier protection,
>>>> project quotas, encrypted datasets, allocation classes, vectorized
>>>> raidz, vectorized checksums, and various command line improvements.
>>>>
>>>> Before ZoF can be merged back in to ZoL several steps need to be taken:
>>>> - Integrate FreeBSD support into ZoL CI
>>>> - Have most of the ZFS test suite passing
>>>> - Complete additional QA testing at iX
>>>>
>>>> We at iX Systems need to port ZoL's EC2 CI scripts to work with
>>>> FreeBSD and make sure that most of the ZFS Test Suite (ZTS) passes.
>>>> Being integrated in to their CI will mean that, among other things,
>>>> most integration issues will be caught before a PR is merged upstream
>>>> rather than many months later when it is MFVed into FreeBSD. I’m
>>>> hoping to submit the PR to ZoL some

Re: The future of ZFS in FreeBSD

[Matthew Macy]

On Wed, Dec 19, 2018 at 14:47 Steven Hartland 
wrote:

> Thanks for the write up most appreciated. One of the more meaty
> differences is that FreeBSD ZFS still has the only merged and production
> ready TRIM support so my question would be are their any plans to address
> this before creating the new port as going back to a world without TRIM
> support wouldn’t be something I’d look forward to.
>

Well, then please follow up on the request I CC'd you on a week ago asking
that you engage on the deadlist based TRIM  PR. That's a better forum for
discussing these details than lamenting in public lists.

Thanks.

-M




> On Wed, 19 Dec 2018 at 06:51, Matthew Macy  wrote:
>
>> The sources for FreeBSD's ZFS support are currently taken directly
>> from Illumos with local ifdefs to support the peculiarities of FreeBSD
>> where the Solaris Portability Layer (SPL) shims fall short. FreeBSD
>> has regularly pulled changes from Illumos and tried to push back any
>> bug fixes and new features done in the context of FreeBSD. In the past
>> few years the vast majority of new development in ZFS has taken place
>> in DelphixOS and zfsonlinux (ZoL). Earlier this year Delphix announced
>> that they will be moving to ZoL
>> https://www.delphix.com/blog/kickoff-future-eko-2018 This shift means
>> that there will be little to no net new development of Illumos. While
>> working through the git history of ZoL I have also discovered that
>> many races and locking bugs have been fixed in ZoL and never made it
>> back to Illumos and thus FreeBSD. This state of affairs has led to a
>> general agreement among the stakeholders that I have spoken to that it
>> makes sense to rebase FreeBSD's ZFS on ZoL. Brian Behlendorf
>> has graciously encouraged me to add FreeBSD support directly to ZoL
>> https://github.com/zfsonfreebsd/ZoF so that we might all have a single
>> shared code base.
>>
>> A port for ZoF can be found at https://github.com/miwi-fbsd/zof-port
>> Before it can be committed some additional functionality needs to be
>> added to the FreeBSD opencrypto framework. These can be found at
>> https://reviews.freebsd.org/D18520
>>
>> This port will provide FreeBSD users with multi modifier protection,
>> project quotas, encrypted datasets, allocation classes, vectorized
>> raidz, vectorized checksums, and various command line improvements.
>>
>> Before ZoF can be merged back in to ZoL several steps need to be taken:
>> - Integrate FreeBSD support into ZoL CI
>> - Have most of the ZFS test suite passing
>> - Complete additional QA testing at iX
>>
>> We at iX Systems need to port ZoL's EC2 CI scripts to work with
>> FreeBSD and make sure that most of the ZFS Test Suite (ZTS) passes.
>> Being integrated in to their CI will mean that, among other things,
>> most integration issues will be caught before a PR is merged upstream
>> rather than many months later when it is MFVed into FreeBSD. I’m
>> hoping to submit the PR to ZoL some time in January.
>>
>> This port will make it easy for end users on a range of releases to
>> run the latest version of ZFS. Nonetheless, transitioning away from an
>> Illumos based ZFS is not likely to be entirely seamless. The
>> stakeholders I’ve spoken to all agree that this is the best path
>> forward but some degree of effort needs to be made to accommodate
>> downstream consumers. The current plan is to import ZoF and unhook the
>> older Illumos based sources from the build on April 15th or two months
>> after iX systems QA deems ZoF stable - which ever comes later. The
>> Illumos based sources will be removed some time later - but well
>> before 13. This will give users a 3 month period during which both the
>> port and legacy Illumos based ZFS will be available to users. Pools
>> should interoperate between ZoF and legacy provided the user does not
>> enable any features available only in ZoF. We will try to accommodate
>> any downstream consumers in the event that they need that date pushed
>> back. We ask that any downstream consumers who are particularly
>> sensitive to changes start testing the port when it is formally
>> announced and report back any issues they have. I will do my best to
>> ensure that this message is communicated to all those who it may
>> concern. However, I can’t ensure that everyone reads these lists. That
>> is the responsibility of -CURRENT users.
>>
>> -M
>>
> ___
>> freebsd...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
>> To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org"
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: The future of ZFS in FreeBSD

[Matthew Ahrens]

On Wed, Dec 19, 2018 at 8:35 AM Shawn Webb 
wrote:

> I'm curious what this means for OpenZFS.
>

OpenZFS will continue to be an umbrella project for coordinating all work
on open-source ZFS.  The primary activities of OpenZFS are the annual OpenZFS
Developer Summit
 and the
monthly OpenZFS Leadership Meetings

.
There is also an OpenZFS GitHub repo, which has identical code to illumos.
This is used to streamline the process of getting changes into illumos
(removing some of the burden of testing and the illumos RTI process).  This
repo will continue to exist as long as there's need for it and folks able
to keep the automation running.  The naming of this GitHub project was
perhaps unfortunate, since it is specific to illumos and not
platform-agnostic.

 I was under the impression that OpenZFS was the upstream for all the ZFS
> implementations (sans
> Oracle).


Being "upstream" is more a matter of degree than an absolute ordering.  In
the past, most ZFS features have originated in illumos, and those changes
have been ported to the other platforms (notably FreeBSD and ZoL).  Looking
forward, we see more features originating in ZoL.  The OpenZFS community
(including FreeBSD) is working to put in place technical processes to
ensure that new ZFS features are available on all platforms.  The original
post in this thread was a proposal for how to do that.

--matt
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: The future of ZFS in FreeBSD

[Matthew Macy]

On Tue, Dec 18, 2018 at 11:49 PM Enji Cooper  wrote:
>
> Hello Matthew,
>
> I appreciate the long write up, as someone who still uses FreeBSD ZFS on my 
> NAS box and knowing some of the history with ZFS on *Solaris, etc. Something 
> like this was bound to happen with post the Oracle buyout.
>
> > On Dec 18, 2018, at 10:49 PM, Matthew Macy  wrote:
> >
> > The sources for FreeBSD's ZFS support are currently taken directly
> > from Illumos with local ifdefs to support the peculiarities of FreeBSD
> > where the Solaris Portability Layer (SPL) shims fall short. FreeBSD
> > has regularly pulled changes from Illumos and tried to push back any
> > bug fixes and new features done in the context of FreeBSD. In the past
> > few years the vast majority of new development in ZFS has taken place
> > in DelphixOS and zfsonlinux (ZoL). Earlier this year Delphix announced
> > that they will be moving to ZoL
> > https://www.delphix.com/blog/kickoff-future-eko-2018 This shift means
> > that there will be little to no net new development of Illumos. While
> > working through the git history of ZoL I have also discovered that
> > many races and locking bugs have been fixed in ZoL and never made it
> > back to Illumos and thus FreeBSD. This state of affairs has led to a
> > general agreement among the stakeholders that I have spoken to that it
> > makes sense to rebase FreeBSD's ZFS on ZoL. Brian Behlendorf
> > has graciously encouraged me to add FreeBSD support directly to ZoL
> > https://github.com/zfsonfreebsd/ZoF so that we might all have a single
> > shared code base.
> >
> > A port for ZoF can be found at https://github.com/miwi-fbsd/zof-port
> > Before it can be committed some additional functionality needs to be
> > added to the FreeBSD opencrypto framework. These can be found at
> > https://reviews.freebsd.org/D18520
> >
> > This port will provide FreeBSD users with multi modifier protection,
> > project quotas, encrypted datasets, allocation classes, vectorized
> > raidz, vectorized checksums, and various command line improvements.
> >
> > Before ZoF can be merged back in to ZoL several steps need to be taken:
> > - Integrate FreeBSD support into ZoL CI
> > - Have most of the ZFS test suite passing
> > - Complete additional QA testing at iX
>
> Can you please describe the testing process that will be employed to verify 
> the sanity of the ZoL on FreeBSD port? Should other large companies who use 
> ZFS on FreeBSD (Panzura?) chime in and the ZFS on FreeBSD community (as a 
> whole) collaborate to better suss out issues with the ZoL port?

The ZFS test suite itself provides ~80% coverage
https://codecov.io/gh/zfsonlinux/zfs/branch/master - FreeBSD currently
lacks equivalent gcov support, but presumably it would provide
comparable coverage here. Andrew Turner has some form of kernel gcov
support that he uses with syzkaller. However, I believe that it isn't
sufficient for this purpose. ZoL requires that coverage only increase
over time. If a change would decrease total coverage new tests have to
be included with the change. There is a command called ztest which
runs in user space that quickly covers a large percentage of the code
base where it doesn't integrate directly with geom or VFS (disk access
is emulated with files, kernel threads are emulated with pthreads,
etc). ztest has been broken in HEAD for the past 2 years (it triggers
an assertion failure), whereas it is not broken in ZoF. Joe Maloney is
the head of QA at iX and can likely give you more detail on their
approach to testing. This e-mail was an implicit request to Panzura to
do whatever testing that they can.

>
> > We at iX Systems need to port ZoL's EC2 CI scripts to work with
> > FreeBSD and make sure that most of the ZFS Test Suite (ZTS) passes.
> > Being integrated in to their CI will mean that, among other things,
> > most integration issues will be caught before a PR is merged upstream
> > rather than many months later when it is MFVed into FreeBSD. I’m
> > hoping to submit the PR to ZoL some time in January.
>
> Could you please better describe this, in particular provide pointers to any 
> scripts that might be executed with the ZoL port?

The ZFS test suite is in ZoL under tests, it makes some Linux specific
assumptions about paths to binaries like ksh etc and it appears to
require some additional configuration options. I started fixing things
before I decided to punt and ask that a porter at iX fix it so that I
could focus on areas that make more sense for me to spend my time on.
If it doesn't get handled I will of course go back to it. The CI
scripts are not something I've looked at. My intention is again that
the people who would be responsible for keeping 

The future of ZFS in FreeBSD

[Matthew Macy]

The sources for FreeBSD's ZFS support are currently taken directly
from Illumos with local ifdefs to support the peculiarities of FreeBSD
where the Solaris Portability Layer (SPL) shims fall short. FreeBSD
has regularly pulled changes from Illumos and tried to push back any
bug fixes and new features done in the context of FreeBSD. In the past
few years the vast majority of new development in ZFS has taken place
in DelphixOS and zfsonlinux (ZoL). Earlier this year Delphix announced
that they will be moving to ZoL
https://www.delphix.com/blog/kickoff-future-eko-2018 This shift means
that there will be little to no net new development of Illumos. While
working through the git history of ZoL I have also discovered that
many races and locking bugs have been fixed in ZoL and never made it
back to Illumos and thus FreeBSD. This state of affairs has led to a
general agreement among the stakeholders that I have spoken to that it
makes sense to rebase FreeBSD's ZFS on ZoL. Brian Behlendorf
has graciously encouraged me to add FreeBSD support directly to ZoL
https://github.com/zfsonfreebsd/ZoF so that we might all have a single
shared code base.

A port for ZoF can be found at https://github.com/miwi-fbsd/zof-port
Before it can be committed some additional functionality needs to be
added to the FreeBSD opencrypto framework. These can be found at
https://reviews.freebsd.org/D18520

This port will provide FreeBSD users with multi modifier protection,
project quotas, encrypted datasets, allocation classes, vectorized
raidz, vectorized checksums, and various command line improvements.

Before ZoF can be merged back in to ZoL several steps need to be taken:
- Integrate FreeBSD support into ZoL CI
- Have most of the ZFS test suite passing
- Complete additional QA testing at iX

We at iX Systems need to port ZoL's EC2 CI scripts to work with
FreeBSD and make sure that most of the ZFS Test Suite (ZTS) passes.
Being integrated in to their CI will mean that, among other things,
most integration issues will be caught before a PR is merged upstream
rather than many months later when it is MFVed into FreeBSD. I’m
hoping to submit the PR to ZoL some time in January.

This port will make it easy for end users on a range of releases to
run the latest version of ZFS. Nonetheless, transitioning away from an
Illumos based ZFS is not likely to be entirely seamless. The
stakeholders I’ve spoken to all agree that this is the best path
forward but some degree of effort needs to be made to accommodate
downstream consumers. The current plan is to import ZoF and unhook the
older Illumos based sources from the build on April 15th or two months
after iX systems QA deems ZoF stable - which ever comes later. The
Illumos based sources will be removed some time later - but well
before 13. This will give users a 3 month period during which both the
port and legacy Illumos based ZFS will be available to users. Pools
should interoperate between ZoF and legacy provided the user does not
enable any features available only in ZoF. We will try to accommodate
any downstream consumers in the event that they need that date pushed
back. We ask that any downstream consumers who are particularly
sensitive to changes start testing the port when it is formally
announced and report back any issues they have. I will do my best to
ensure that this message is communicated to all those who it may
concern. However, I can’t ensure that everyone reads these lists. That
is the responsibility of -CURRENT users.

-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mtx_lock() by idle thread ... mutex igb0 @ ../../../net/iflib.c:2084

[Matthew Macy]

Will fix.
On Tue, Oct 23, 2018 at 2:21 AM Peter Holm  wrote:
>
> Feeding entropy: .
> lo0: link state changed to UP
> panic: mtx_lock() by idle thread 0xf800036ac000 on sleep mutex igb0 @ 
> ../../../net/iflib.c:2084
> cpuid = 4
> time = 1540286062
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe007876e610
> vpanic() at vpanic+0x1a3/frame 0xfe007876e670
> panic() at panic+0x43/frame 0xfe007876e6d0
> __mtx_lock_flags() at __mtx_lock_flags+0x15a/frame 0xfe007876e720
> iflib_admin_intr_deferred() at iflib_admin_intr_deferred+0x2a/frame 
> 0xfe007876e750
> em_msix_link() at em_msix_link+0x84/frame 0xfe007876e780
> iflib_fast_intr_ctx() at iflib_fast_intr_ctx+0x21/frame 0xfe007876e7a0
> intr_event_handle() at intr_event_handle+0xbb/frame 0xfe007876e7f0
> intr_execute_handlers() at intr_execute_handlers+0x58/frame 0xfe007876e820
> lapic_handle_intr() at lapic_handle_intr+0x5f/frame 0xfe007876e840
> Xapic_isr1() at Xapic_isr1+0xd9/frame 0xfe007876e840
> --- interrupt, rip = 0x811e6be6, rsp = 0xfe007876e910, rbp = 
> 0xfe007876e910 ---
> acpi_cpu_c1() at acpi_cpu_c1+0x6/frame 0xfe007876e910
> acpi_cpu_idle() at acpi_cpu_idle+0x23d/frame 0xfe007876e960
> cpu_idle_acpi() at cpu_idle_acpi+0x3f/frame 0xfe007876e980
> cpu_idle() at cpu_idle+0xa7/frame 0xfe007876e9a0
> sched_idletd() at sched_idletd+0x517/frame 0xfe007876ea70
> fork_exit() at fork_exit+0x84/frame 0xfe007876eab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe007876eab0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> KDB: enter: panic
> [ thread pid 11 tid 17 ]
> Stopped at  kdb_enter+0x3b: movq$0,kdb_why
> db> x/s version
> version:FreeBSD 13.0-CURRENT r339638 PHO-GENERIC\012
> db>
> --
> Peter
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: virtualbox 5.2.20 triggers panic with FreeBSD 12.0-ALPHA10 r339432

[Matthew D. Fuller]

On Fri, Oct 19, 2018 at 03:47:40PM -0700 I heard the voice of
Don Lewis, and lo! it spake thus:
>
> The first is that when I attempt to start a Virtualbox VM, the
> system panics.

Perhaps https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230460


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: drm2 in base

[Matthew Macy]

On Fri, Sep 28, 2018 at 1:22 PM Warner Losh  wrote:
>
> On Fri, Sep 28, 2018 at 2:02 PM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
> > On Fri, Sep 28, 2018 at 02:47:39PM -0500, Matthew D. Fuller wrote:
> > > On Fri, Sep 28, 2018 at 11:00:02AM -0700 I heard the voice of
> > > Steve Kargl, and lo! it spake thus:
> > > >
> > > > I have a radeon HD 6450 video card (CAICOS firmware), and have been
> > > > informed that the hardware is too old for graphics/drm-stable-kmod
> > > > and that I should use graphics/drm-legacy-kmod.
> > >
> > > Well, please don't tell that to the 6450 I've got running on
> > > drm-next-kmod (which also spent some time on drm-stable)...
> > >
> >
> > See the URL I posted.
> >
> > How did you get around the "fence_wait returned with error -512"
> > messages filling /var/log/messages.
> >
>
> Ah, that thread...  OK. I'm back with you...
>
>
> > It also does not get around the problem that
> > drm-legacy-kmod has been advertised as the drop-in
> > replacement for those that use drm2 and have older
> > hardware.
> >
>
> It should be. The fact that it's not is concerning and should be
> addressed...


Bug reports are addressed as they come in. If issues haven't come up
it likely reflects a scarcity of users.

-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: drm2 in base

[Matthew D. Fuller]

On Fri, Sep 28, 2018 at 01:01:02PM -0700 I heard the voice of
Steve Kargl, and lo! it spake thus:
>
> How did you get around the "fence_wait returned with error -512"
> messages filling /var/log/messages.

Well, I never got them "filling" in a flooding sense.  I did get
regular bursts of them for a while (often video-related, I think), but
they never caused any visible problem.

The last I see in old messages files now is from July.  That might
have been when I switched it from stable->next?  Looking at the
mssages file, shortly after the reboot shortly following the last
fence, I see

Jul 20 21:19:47 cepheus pkg: drm-stable-kmod-g20180619_1 deinstalled
Jul 20 21:19:48 cepheus pkg-static: drm-next-kmod-4.11.g20180619_1 installed

and I haven't seen one since.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: drm2 in base

[Matthew D. Fuller]

On Fri, Sep 28, 2018 at 11:00:02AM -0700 I heard the voice of
Steve Kargl, and lo! it spake thus:
> 
> I have a radeon HD 6450 video card (CAICOS firmware), and have been
> informed that the hardware is too old for graphics/drm-stable-kmod
> and that I should use graphics/drm-legacy-kmod.  

Well, please don't tell that to the 6450 I've got running on
drm-next-kmod (which also spent some time on drm-stable)...


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4

[Matthew Macy]

On Sat, Sep 8, 2018 at 11:03 Cy Schubert  wrote:

> In message , Jakob
> Alvermar
> k writes:
> >
> > Total MFU MRUAnon Hdr L2Hdr
> Other
> >   ZFS ARC667M186M168M 13M   3825K 0K295M
> >
> >  ratehits  misses   total hits total
> > misses
> >   arcstats  : 99%   65636 605 167338494
> 9317074
> >   arcstats.demand_data  : 57% 431 321 13414675
> 2117714
> >   arcstats.demand_metadata  : 99%   65175 193 152969480
> 5344919
> >   arcstats.prefetch_data:  0%   0  30 3292   401344
> >   arcstats.prefetch_metadata: 32%  30  61 951047  1453097
> >   zfetchstats   :  9% 1191077 612582 55041789
> >   arcstats.l2   :  0%   0   0 00
> >   vdev_cache_stats  :  0%   0   0 00
> >
> >
> >
> >
> > This is while a 'make -j8 buildworld' (it has 8 cores) is going.
>
> Overall you have a 94% hit ratio.
>
> slippy$ bc
> scale=4
> 167338494/(167338494+9317074)
> .9472
> slippy$
>
>
> It could be better.
>
> Why is your ZFS ARC so small? Before I answer this I will discuss my
> experience first.
>
> My machines are seeing something similar to this:
>
>   Total MFU MRUAnon Hdr   L2Hdr
> Other
>  ZFS ARC   4274M   2329M   1394M 17M 82M  0K
> 445M
>
> ratehits  misses   total hits total
> misses
>  arcstats  : 97% 614  13866509066
> 51853442
>  arcstats.demand_data  :100%  96   0107658733
> 3101522
>  arcstats.demand_metadata  : 97% 516  13755890353
> 48080146
>  arcstats.prefetch_data:  0%   0   0   327613
> 225688
>  arcstats.prefetch_metadata:100%   2   0  2632367
> 446086
>  zfetchstats   :  6%   6  80  2362709
> 294731645
>  arcstats.l2   :  0%   0   00
>  0
>  vdev_cache_stats  :  0%   0   00
>  0
>
> This is what you should see. This is with -CURRENT built two days ago.
>
> cwsys$ uname -a
> FreeBSD cwsys 12.0-ALPHA5 FreeBSD 12.0-ALPHA5 #51 r338520M: Thu Sep  6
> 17:44:35 PDT 2018 root@cwsys:/export/obj/opt/src/svn-current/amd64.a
> md64/sys/BREAK  amd64
> cwsys$
>
> Top reports:
>
> CPU:  0.3% user, 89.9% nice,  9.5% system,  0.3% interrupt,  0.0% idle
> Mem: 678M Active, 344M Inact, 175M Laundry, 6136M Wired, 168M Buf, 598M
> Free
> ARC: 4247M Total, 2309M MFU, 1386M MRU, 21M Anon, 86M Header, 446M Other
>  3079M Compressed, 5123M Uncompressed, 1.66:1 Ratio
> Swap: 20G Total, 11M Used, 20G Free
>
> This is healthy. It's running a poudriere build.
>
> My laptop:
>
>Total MFU MRUAnon Hdr   L2Hdr
> Other
>  ZFS ARC   3175M   1791M872M 69M165M  0K
> 277M
>
> ratehits  misses   total hits total
> misses
>  arcstats  : 99%3851  26 89082984
> 5101207
>  arcstats.demand_data  : 99% 345   2  6197930
> 340186
>  arcstats.demand_metadata  : 99%3506  24 81391265
> 4367755
>  arcstats.prefetch_data:  0%   0   011507
>  30945
>  arcstats.prefetch_metadata:  0%   0   0  1482282
> 362321
>  zfetchstats   :  2%  12 576   113185
> 38564546
>  arcstats.l2   :  0%   0   00
>  0
>  vdev_cache_stats  :  0%   0   00
>  0
>
> Similar results after working on a bunch of ports in four VMs last
> night, testing various combinations of options while Heimdal in base is
> private, hence the large ARC remaining this morning.
>
> Currently on the laptop top reports:
>
> CPU:  0.2% user,  0.0% nice,  0.0% system,  0.0% interrupt, 99.8% idle
> Mem: 376M Active, 1214M Inact, 5907M Wired, 464M Buf, 259M Free
> ARC: 3175M Total, 1863M MFU, 803M MRU, 69M Anon, 160M Header, 280M Other
>  2330M Compressed, 7881M Uncompressed, 3.38:1 Ratio
> Swap: 22G Total, 22G Free
>
> This is also healthy.
>
> Now for questions:
>
> Do you have any UFS filesystems? Top will report buf. What is that at?
>
> Some background: My /, /usr, and /var are UFS (these are old
> installations which when I install a new machine I dump | rsh
> new-machine restore, change a couple of entries in rc.conf and fstab,
> rsync ports (/usr/local, /var/db...) and boot (I'm terribly impatient).
> Hence the legacy.
>
> I have noticed that when writing a lot to UFS, increasing the size of
> the UFS buffer cache, my ARC will reduce to 1 GB or even less. But this
> is during a -j8 installworld to /, a test partition, an i386 partition
> and a number of VMs on UFS on a zpool and other VMs using ZFS on 

Re: drm / drm2 removal in 12

[Matthew Macy]

Please just stop responding to this person or we're going to have to
migrate to moderated lists. You're legitimizing the voice of one
person who project members have spend hours of their time (some even
in person) trying to explain the time tradeoffs of supporting
graphics. For some reason he isn't capable of understanding the
technical issues and he isn't capable of constructively engaging the
project.

Thank you for your understanding.
-M



On Sun, Aug 26, 2018 at 3:33 PM Larry Rosenman  wrote:
>
> On Mon, Aug 27, 2018 at 06:21:57AM +0800, blubee blubeeme wrote:
> >
> > You seem to miss the point where the you avoid breaking the system for any
> > users not on the bleeding edge.
> >
> > You technically adept guys can keep on hacking away, jumping through hoops
> > and building your stuff as you see fit.
> > Nobody will come take your steal your code away in the night. Feel free to
> > keep on working on it, until implementing it
> > doesn't break "old users" do the engineering work and improve your
> > implementation.
> >
> > There are so many seemingly dead code projects around this linuxkpi stuff
> > that you guys just pump out code and abandon
> > inconsistent lack of documentation, lack of testing, it's just a huge mess.
> >
> > Work on cleaning all that stuff up and bring something sensible to the
> > table, you cannot put onus on the core team to maintain
> > that mess going forward because you're not capable of doing it yourselves.
>
> If you don't like breakage, don't run HEAD/-CURRENT.  If it's not out in
> HEAD/-CURRENT, we (the project, speaking as a ports committer) can't
> move forward.
>
>
> --
> Larry Rosenman https://people.FreeBSD.org/~ler/
> Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
> US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ifnet use after free

[Matthew Macy]

On Sat, Aug 25, 2018 at 12:10 PM Kristof Provost  wrote:

> You may be right about that. With memguard (on ifnet) it implicates pf:
>
> pfi_cleanup_vnet() at pfi_cleanup_vnet+0xa4/frame 0xfe084f775320
> vnet_pf_uninit() at vnet_pf_uninit+0x85f/frame 0xfe084f7757c0
> vnet_destroy() at vnet_destroy+0x12c/frame 0xfe084f7757f0
> prison_deref() at prison_deref+0x29d/frame 0xfe084f775830
> sys_jail_remove() at sys_jail_remove+0x28a/frame 0xfe084f775880
> amd64_syscall() at amd64_syscall+0x28c/frame 0xfe084f7759b0
> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe084f7759b0
> --- syscall (508, FreeBSD ELF64, sys_jail_remove), rip = 0x8003130da, rsp
> = 0x7fffe848, rbp = 0x7fffe8d0 ---
>
> I’ll investigate that. Sorry for the noise.
> Thanks for the pointer to memguard. Very useful.
>
>
And thank you for updating me.
-M



> Kristof
>
> On 25 Aug 2018, at 19:44, Matthew Macy wrote:
>
> I'll take a look. But it's likely to not be the OP's issue. For future
> reference memguard on the memory type in question is extremely useful in
> catching use after free.
>
> -M
>
> On Sat, Aug 25, 2018 at 05:51 Kristof Provost  wrote:
>
>> On 25 Aug 2018, at 0:47, Kristof Provost wrote:
>>
>> On 25 Aug 2018, at 0:26, Matthew Macy wrote:
>>
>> On Fri, Aug 24, 2018 at 15:25 Shawn Webb 
>> wrote:
>>
>> Hey All,
>>
>> Somewhere in the last month or so, a use after free was introduced. I
>> don't have the time right now to bisect the commits and figure out
>> which commit introduced the breakage. Attached is the core.txt (which
>> seems nonsensical because the dump is reporting on a different
>> thread). If the core.txt gets scrubbed, I've posted it here:
>> https://gist.github.com/796ea88cec19a1fd2a85f4913482286a
>>
>> Do you have any guidance on how to reproduce? The hardenedbsd rev isn’t
>> useful - the svn commit that it’s based against is what is needed.
>>
>> For what it’s worth, it’s not a hardenedbsd thing. I’ve been chasing the
>> same one (same offset, same allocation size, same most recent user).
>> Something gets set to zero/NULL. 8 bytes on amd64, so presumably a pointer.
>>
>> I currently only trigger it on a development branch, but I’ll see if I
>> can clean that up into something I can share tomorrow.
>>
>> In my test scenario it happens after shutdown of a vnet jail with a few
>> interfaces in it (including a pfsync interface which will disappear with
>> the jail), and new jails are started. It’s pretty reliable.
>>
>> At a guess something’s wrong with the delayed cleanup of ifnets and vnet
>> shutdown.
>>
>> I see this:
>>
>> Memory modified after free 0xf800623ab000(2040) val=0 @ 
>> 0xf800623ab398
>> panic: Most recently used by ifnet
>>
>> cpuid = 7
>> time = 1535199812
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
>> 0xfe008c8e13c0
>> vpanic() at vpanic+0x1a3/frame 0xfe008c8e1420
>> panic() at panic+0x43/frame 0xfe008c8e1480
>> mtrash_ctor() at mtrash_ctor+0x81/frame 0xfe008c8e14a0
>> uma_zalloc_arg() at uma_zalloc_arg+0x72c/frame 0xfe008c8e1510
>> malloc() at malloc+0x9a/frame 0xfe008c8e1560
>> if_alloc() at if_alloc+0x23/frame 0xfe008c8e1590
>> epair_clone_create() at epair_clone_create+0x239/frame 0xfe008c8e1610
>> if_clone_createif() at if_clone_createif+0x4a/frame 0xfe008c8e1660
>> ifioctl() at ifioctl+0x852/frame 0xfe008c8e1750
>> kern_ioctl() at kern_ioctl+0x2ba/frame 0xfe008c8e17b0
>> sys_ioctl() at sys_ioctl+0x15e/frame 0xfe008c8e1880
>> amd64_syscall() at amd64_syscall+0x28c/frame 0xfe008c8e19b0
>> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe008c8e19b0
>> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80047b74a, rsp = 
>> 0x7fffe208, rbp = 0x7fffe250 ---
>> KDB: enter: panic
>> [ thread pid 1426 tid 100466 ]
>> Stopped at  kdb_enter+0x3b: movq$0,kdb_why
>> db>
>>
>> It does require a couple of bug fixes in pfsync to trigger. You can get
>> them from the pfsync_vnet branch in
>> https://github.com/kprovost/freebsd/tree/pfsync_vnet
>>
>> After that:
>> kldload pfsync
>> pkg install scapy
>> cd /usr/tests/sys/netpfil/pf
>> kyua test
>>
>> It should panic reliably.
>>
>> Regards,
>> Kristof
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ifnet use after free

[Matthew Macy]

I'll take a look. But it's likely to not be the OP's issue. For future
reference memguard on the memory type in question is extremely useful in
catching use after free.

-M

On Sat, Aug 25, 2018 at 05:51 Kristof Provost  wrote:

> On 25 Aug 2018, at 0:47, Kristof Provost wrote:
>
> On 25 Aug 2018, at 0:26, Matthew Macy wrote:
>
> On Fri, Aug 24, 2018 at 15:25 Shawn Webb 
> wrote:
>
> Hey All,
>
> Somewhere in the last month or so, a use after free was introduced. I
> don't have the time right now to bisect the commits and figure out
> which commit introduced the breakage. Attached is the core.txt (which
> seems nonsensical because the dump is reporting on a different
> thread). If the core.txt gets scrubbed, I've posted it here:
> https://gist.github.com/796ea88cec19a1fd2a85f4913482286a
>
> Do you have any guidance on how to reproduce? The hardenedbsd rev isn’t
> useful - the svn commit that it’s based against is what is needed.
>
> For what it’s worth, it’s not a hardenedbsd thing. I’ve been chasing the
> same one (same offset, same allocation size, same most recent user).
> Something gets set to zero/NULL. 8 bytes on amd64, so presumably a pointer.
>
> I currently only trigger it on a development branch, but I’ll see if I can
> clean that up into something I can share tomorrow.
>
> In my test scenario it happens after shutdown of a vnet jail with a few
> interfaces in it (including a pfsync interface which will disappear with
> the jail), and new jails are started. It’s pretty reliable.
>
> At a guess something’s wrong with the delayed cleanup of ifnets and vnet
> shutdown.
>
> I see this:
>
> Memory modified after free 0xf800623ab000(2040) val=0 @ 0xf800623ab398
> panic: Most recently used by ifnet
>
> cpuid = 7
> time = 1535199812
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe008c8e13c0
> vpanic() at vpanic+0x1a3/frame 0xfe008c8e1420
> panic() at panic+0x43/frame 0xfe008c8e1480
> mtrash_ctor() at mtrash_ctor+0x81/frame 0xfe008c8e14a0
> uma_zalloc_arg() at uma_zalloc_arg+0x72c/frame 0xfe008c8e1510
> malloc() at malloc+0x9a/frame 0xfe008c8e1560
> if_alloc() at if_alloc+0x23/frame 0xfe008c8e1590
> epair_clone_create() at epair_clone_create+0x239/frame 0xfe008c8e1610
> if_clone_createif() at if_clone_createif+0x4a/frame 0xfe008c8e1660
> ifioctl() at ifioctl+0x852/frame 0xfe008c8e1750
> kern_ioctl() at kern_ioctl+0x2ba/frame 0xfe008c8e17b0
> sys_ioctl() at sys_ioctl+0x15e/frame 0xfe008c8e1880
> amd64_syscall() at amd64_syscall+0x28c/frame 0xfe008c8e19b0
> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe008c8e19b0
> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80047b74a, rsp = 
> 0x7fffe208, rbp = 0x7fffe250 ---
> KDB: enter: panic
> [ thread pid 1426 tid 100466 ]
> Stopped at  kdb_enter+0x3b: movq$0,kdb_why
> db>
>
> It does require a couple of bug fixes in pfsync to trigger. You can get
> them from the pfsync_vnet branch in
> https://github.com/kprovost/freebsd/tree/pfsync_vnet
>
> After that:
> kldload pfsync
> pkg install scapy
> cd /usr/tests/sys/netpfil/pf
> kyua test
>
> It should panic reliably.
>
> Regards,
> Kristof
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: drm / drm2 removal in 12

[Matthew Macy]

Hi Owen -
I understand that you're enthusiastic and you just want what's best for the
project. However, there's a couple of points I hope you'll take to heart.
First, please read what you sent and think about the tone and word choice.
It's extremely negative and critical - you're actively alienating people on
the list. You're not going to be successful engaging any open source
community or workplace if you choose to communicate like this. Second, this
is a volunteer project. One needs to establish a track record of producing
patches and working with developers to get them committed. Regardless of
how sound your technical position is - you're going to have a hard time
being acknowledged if there is no contribution to match.

Best wishes.
-M


On Fri, Aug 24, 2018 at 4:07 PM blubee blubeeme  wrote:

>
>
> On Sat, Aug 25, 2018 at 6:26 AM Warner Losh  wrote:
>
>> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy  wrote:
>>
>> > On Fri, Aug 24, 2018 at 14:53 Ali  wrote:
>> >
>> > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote:
>> > > > Just in case anyone misses the change to UPDATING:
>> > > >
>> > > > 20180821:
>> > > > drm and drm2 have been removed. Users on powerpc, 32-bit
>> > > hardware,
>> > > > or with GPUs predating Radeon and i915 will need to install
>> the
>> > > > graphics/drm-legacy-kmod. All other users should be able to
>> use
>> > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
>> > > > graphics/drm-next-kmod, graphics/drm-devel-kmod.
>> > > > Note that this applies only to 12.
>> > >
>> > > I see that The removal of drm and drm2 has been reverted on svn. Could
>> > > you please kindly share the reasons behind the re-inclusion?
>> > >
>> >
>> >
>> > I can’t really give the blow by blow of internal project drama, but the
>> > gist of it is that “best practices” (which are not yet actually
>> documented
>> > anywhere that I’ve seen) were not followed with regards to the
>> deprecation
>> > process. Warner and others believe that we can address the objectives of
>> > the drm removal (improving the user experience and communicating that
>> > drm/drm2 are _completely_ unsupported apart from continuing to compile)
>> > through less disruptive means.
>> >
>>
>> Just so.
>>
>> Our only continued frustration is that we were never given any guidance by
>> > RE or core on said “best practices” when the discussion was taking
>> place in
>> > May and then those groups behaved as if this were a surprise when the
>> > removal happened. I’m cautiously optimistic that this well expedite
>> > improving communications on those matters.
>> >
>>
>> All the problems that are exposed by this aren't technical. This one is
>> social, but no less important.
>>
>> Warner
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
>> "
>>
>
> I've been watching this debacle for quite some time now and I'd just like
> to ask why the rush?
>
> The graphics team is working very hard to destroy the stability of FreeBSD
> just so that they can force their uncooked work down users throats.
>
> The Linuxkpi is unstable at best, alpha level software that's constantly
> in need of someone to go and fix something on FreeBSD because Linux devs
> decided to make some changes or implement a new feature.
>
> This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM
> Goals
>
>- Move DRM headers to a similar location as Linux
>-
>
>Use kmalloc() instead of malloc(9)
>- Use kref
>-
>
>Use idr and get rid of drm_gem_names.c
>- Use PCI API
>- Use Linux locking primitives
>
> is garbage, if you want to use develop Linux code and use Linux then go do
> that on Linux.
>
> Are these guys insane and please avoid the nonsense about you're doing
> this in your spare time.
>
> If you cannot devote the resources to do something right then don't do it
> at all.
>
> Keep that stuff in to yourself or anyone crazy enough to follow those
> steps to get it up and running, you guys cannot expect to contaminate the
> entire FreeBSD project for this mess.
>
> This is nonsense and I hope that more people who see it as such would say
> so and stop having these guys forcing this crap; it's maintenance hell who
> will maintain it if they decide to leave?
>
> Best,
> Owen
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ifnet use after free

[Matthew Macy]

On Fri, Aug 24, 2018 at 15:25 Shawn Webb  wrote:

> Hey All,
>
> Somewhere in the last month or so, a use after free was introduced. I
> don't have the time right now to bisect the commits and figure out
> which commit introduced the breakage. Attached is the core.txt (which
> seems nonsensical because the dump is reporting on a different
> thread). If the core.txt gets scrubbed, I've posted it here:
> https://gist.github.com/796ea88cec19a1fd2a85f4913482286a
>

Do you have any guidance on how to reproduce? The hardenedbsd rev isn’t
useful - the svn commit that it’s based against is what is needed.

Thanks.
-M



> I'm running HardenedBSD 12-CURRENT/amd64, commit 6091fec317a.
>
> FreeBSD hbsd-dev-laptop 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #4
> 6091fec317a(hardened/current/master)-dirty: Thu Aug 23 18:37:45 EDT
> 2018
> shawn@hbsd-dev-laptop:/usr/obj/usr/src/amd64.amd64/sys/LATT-SEC  amd64
>
> Thanks,
>
> --
> Shawn Webb
> Cofounder and Security Engineer
> HardenedBSD
>
> Tor-ified Signal:+1 443-546-8752
> Tor+XMPP+OTR:latt...@is.a.hacker.sx
> GPG Key ID:  0x6A84658F52456EEE
> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: drm / drm2 removal in 12

[Matthew Macy]

On Fri, Aug 24, 2018 at 14:53 Ali  wrote:

> On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote:
> > Just in case anyone misses the change to UPDATING:
> >
> > 20180821:
> > drm and drm2 have been removed. Users on powerpc, 32-bit
> hardware,
> > or with GPUs predating Radeon and i915 will need to install the
> > graphics/drm-legacy-kmod. All other users should be able to use
> > one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
> > graphics/drm-next-kmod, graphics/drm-devel-kmod.
> > Note that this applies only to 12.
>
> I see that The removal of drm and drm2 has been reverted on svn. Could
> you please kindly share the reasons behind the re-inclusion?
>


I can’t really give the blow by blow of internal project drama, but the
gist of it is that “best practices” (which are not yet actually documented
anywhere that I’ve seen) were not followed with regards to the deprecation
process. Warner and others believe that we can address the objectives of
the drm removal (improving the user experience and communicating that
drm/drm2 are _completely_ unsupported apart from continuing to compile)
through less disruptive means. I am only acting as a lightning rod and
representative of the graphics team and so have done an inadequate job of
tracking their activities with respect to project timelines. As a result of
this misunderstanding Johannes Lundberg will be sponsored for a bit and
will be able to be involved in internal discussions that impact his work.

Our only continued frustration is that we were never given any guidance by
RE or core on said “best practices” when the discussion was taking place in
May and then those groups behaved as if this were a surprise when the
removal happened. I’m cautiously optimistic that this well expedite
improving communications on those matters.


Cheers.
-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: priority of paths to kernel modules?

[Matthew Macy]

No we're not. x86 and PPC will be disconnected from the build in a
subsequent commit during the freeze. Warner was simply too tired to
communicate this adequately and still meet the timeline that RE wanted.

And take heart. Even if Warner weren't trying to balance the needs of RE
and the graphics team + user base on post-2013 hardware - the graphics
doesn't _have_ to support 12.x. it's well within the team's rights to
simply declare 12.x as unsupported. The team is welcome to simply say we
support 11.x and 13.x. The failing was largely in that "expected" processes
are not documented and not well communicated.

Warner is acting in good faith. He's just trying to balance many demands in
a compressed time period.

Cheers.
-M





On Fri, Aug 24, 2018 at 01:06 Johannes Lundberg  wrote:

> Hi
>
> Since we now stuck with drm2 in base for a few more years I have an idea
> would make things much smoother for many of us, hugely reduce the amount of
> bug reports we get and I think would be beneficial in other ways too.
>
> Current I run with something like this in /boot/loader.conf
>
>
> module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays"
>
> So I expect modules to be loaded in that order, with /boot/ LAST.
>
> However, if you look at this
> sysctl kern.module_path
> kern.module_path:
> /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays
>
> /boot/kernel is inserted first and probably modules in /boot/kernel have
> the highest priority. This is also proven by everyone wanting to use
> drm*kmods that get drm.ko from base loaded instead of the installed in
> /boot/modules.
>
> Please correct me if I'm wrong but if my understanding is correct this is a
> flaw and /boot/ should be inserted last so that any overlays or
> custom modules have higher priority than the default ones.
>
> I can imagine this is also useful when building custom modules and you
> don't want to overwrite or delete the default one in /boot/kernel...
>
> Cheers
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Native Encryption for ZFS on FreeBSD CFT

[Matthew Macy]

Hi Thomas,

Alan believes that, even with dedup disabled, the ZFS native encryption
support is vulnerable to watermarking attacks. I don't have enough exposure
to crypto to pass any judgement and was hoping that you'd share your point
of view. Thanks in advance.

-M



On Wed, Aug 22, 2018 at 12:42 PM Alan Somers  wrote:

> Only encrypting L0 blocks also leaks a lot of information.  That means
> that, if encryption is set to anything but "off", watermarking attacks will
> still be possible based on the size and sparsity of a file.  Because I
> believe that with any encryption mode, ZFS turns continuous runs of zeros
> into holes.  And I don't see anything in zio_crypt.c that addresses that.
> -Alan
>
> On Wed, Aug 22, 2018 at 1:23 PM Sean Fagan  wrote:
>
>> On Aug 22, 2018, at 12:20 PM, Alan Somers  wrote:
>> > ]That doesn't answer the question about what happens when dedup is
>> turned off.  In that case, is the HMAC still used as the IV?  If so, then
>> watermarking attacks are still possible.  If ZFS switches to a random IV
>> when dedup is off, then it would probably be ok.
>>
>> From the same file:
>>
>>  * Initialization Vector (IV):
>>
>>  * An initialization vector for the encryption algorithms. This is used
>> to
>>  * "tweak" the encryption algorithms so that two blocks of the same data
>> are
>>  * encrypted into different ciphertext outputs, thus obfuscating block
>> patterns.
>>  * The supported encryption modes (AES-GCM and AES-CCM) require that an
>> IV is
>>  * never reused with the same encryption key. This value is stored
>> unencrypted
>>  * and must simply be provided to the decryption function. We use a 96
>> bit IV
>>  * (as recommended by NIST) for all block encryption. For non-dedup
>> blocks we
>>  * derive the IV randomly. The first 64 bits of the IV are stored in the
>> second
>>  * word of DVA[2] and the remaining 32 bits are stored in the upper 32
>> bits of
>>  * blk_fill. This is safe because encrypted blocks can't use the upper 32
>> bits
>>  * of blk_fill. We only encrypt level 0 blocks, which normally have a
>> fill count
>>  * of 1. The only exception is for DMU_OT_DNODE objects, where the fill
>> count of
>>  * level 0 blocks is the number of allocated dnodes in that block. The
>> on-disk
>>  * format supports at most 2^15 slots per L0 dnode block, because the
>> maximum
>>  * block size is 16MB (2^24). In either case, for level 0 blocks this
>> number
>>  * will still be smaller than UINT32_MAX so it is safe to store the IV in
>> the
>>  * top 32 bits of blk_fill, while leaving the bottom 32 bits of the fill
>> count
>>  * for the dnode code.
>>
>>
>> Sean
>>
>>
>>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Native Encryption for ZFS on FreeBSD CFT

[Matthew Macy]

Fixed. Pull.
bc2b257d1082112cc27e56db793f5c569f603bec

On Wed, Aug 22, 2018 at 12:10 AM Matthew Macy  wrote:

> Yes. I _just_ rebased and broke world in the process. Fix coming up
> momentarily.
> -M
>
> On Wed, Aug 22, 2018 at 12:06 AM Outback Dingo 
> wrote:
>
>> of course interesting work, but unfortunately, and as you know me,
>> what would i say next
>>
>> cc -target x86_64-unknown-freebsd12.0
>> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
>> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe
>> -I/usr/src/sys/cddl/compat/opensolaris
>> -I/usr/src/cddl/compat/opensolaris/include
>> -I/usr/src/cddl/compat/opensolaris/lib/libumem
>> -I/usr/src/cddl/contrib/opensolaris/lib/libzpool/common
>> -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
>> -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lua
>> -I/usr/src/sys/cddl/contrib/opensolaris/common/zfs
>> -I/usr/src/sys/cddl/contrib/opensolaris/uts/common
>> -I/usr/src/cddl/contrib/opensolaris/head
>> -I/usr/src/cddl/contrib/opensolaris/lib/libnvpair
>> -I/usr/src/cddl/contrib/opensolaris/lib/libcmdutils
>> -DWANTS_MUTEX_OWNED -I/usr/src/lib/libpthread/thread
>> -I/usr/src/lib/libpthread/sys -I/usr/src/lib/libthr/arch/amd64/include
>> -g -DDEBUG=1 -DZFS_DEBUG=1   -DNEED_SOLARIS_BOOLEAN -g -MD
>> -MF.depend.freebsd_crypto.o -MTfreebsd_crypto.o -std=iso9899:1999
>> -fstack-protector-strong -Wno-pointer-sign -Wno-unknown-pragmas
>> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
>> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
>> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
>> -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum
>> -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments  -c
>> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c
>> -o freebsd_crypto.o
>>
>> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:19:
>> warning: tentative definition of variable with internal linkage has
>> incomplete non-array type 'struct mtx'
>> [-Wtentative-definition-incomplete-type]
>> static struct mtx freebsd_crypto_mutex;
>>   ^
>>
>> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:15:
>> note: forward declaration of 'struct mtx'
>> static struct mtx freebsd_crypto_mutex;
>>   ^
>>
>> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:63:35:
>> error: expected identifier
>> MTX_SYSINIT(freebsd_crypto_mutex, _crypto_mutex, "FreeBSD ZFS
>> Crypto mutex", MTX_DEF);
>>   ^
>>
>> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:63:1:
>> warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
>> MTX_SYSINIT(freebsd_crypto_mutex, _crypto_mutex, "FreeBSD ZFS
>> Crypto mutex", MTX_DEF);
>> ^
>>
>> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:19:
>> error: tentative definition has type 'struct mtx' that is never
>> completed
>> static struct mtx freebsd_crypto_mutex;
>>   ^
>>
>> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:15:
>> note: forward declaration of 'struct mtx'
>> static struct mtx freebsd_crypto_mutex;
>>   ^
>> 2 warnings and 2 errors generated.
>> *** Error code 1
>> On Wed, Aug 22, 2018 at 4:28 AM Matthew Macy  wrote:
>> >
>> > On Tue, Aug 21, 2018 at 6:55 PM Matthew Macy  wrote:
>> >
>> > > To anyone with an interest in native encryption in ZFS please test the
>> > > projects/zfs-crypto-merge-0820 branch in my freebsd repo:
>> > > https://github.com/mattmacy/networking.git
>> > >
>> > >
>> > Oh and I neglected to state that this work is being supported by iX
>> Systems
>> > and the tree is all built on work done by Sean Fagan at iX Systems.
>> Please
>> > keep him in the loop on any problems encountered.
>> > Thanks.
>> >
>> >
>> >
>> > > ( git clone  https://github.com/mattmacy/networking.git -b
>> > > projects/zfs-crypto-merge-0820 )
>> > >
>> > > The UI is quite close to the Oracle Solaris ZFS crypto with minor
>> > > differences for specifying key location.
>> > >
>> > > Please note that once a feature is enabled on a pool it can't be
>> > > disabled. This means that if you enable en

Re: Native Encryption for ZFS on FreeBSD CFT

[Matthew Macy]

Yes. I _just_ rebased and broke world in the process. Fix coming up
momentarily.
-M

On Wed, Aug 22, 2018 at 12:06 AM Outback Dingo 
wrote:

> of course interesting work, but unfortunately, and as you know me,
> what would i say next
>
> cc -target x86_64-unknown-freebsd12.0
> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe
> -I/usr/src/sys/cddl/compat/opensolaris
> -I/usr/src/cddl/compat/opensolaris/include
> -I/usr/src/cddl/compat/opensolaris/lib/libumem
> -I/usr/src/cddl/contrib/opensolaris/lib/libzpool/common
> -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
> -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lua
> -I/usr/src/sys/cddl/contrib/opensolaris/common/zfs
> -I/usr/src/sys/cddl/contrib/opensolaris/uts/common
> -I/usr/src/cddl/contrib/opensolaris/head
> -I/usr/src/cddl/contrib/opensolaris/lib/libnvpair
> -I/usr/src/cddl/contrib/opensolaris/lib/libcmdutils
> -DWANTS_MUTEX_OWNED -I/usr/src/lib/libpthread/thread
> -I/usr/src/lib/libpthread/sys -I/usr/src/lib/libthr/arch/amd64/include
> -g -DDEBUG=1 -DZFS_DEBUG=1   -DNEED_SOLARIS_BOOLEAN -g -MD
> -MF.depend.freebsd_crypto.o -MTfreebsd_crypto.o -std=iso9899:1999
> -fstack-protector-strong -Wno-pointer-sign -Wno-unknown-pragmas
> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum
> -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments  -c
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c
> -o freebsd_crypto.o
>
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:19:
> warning: tentative definition of variable with internal linkage has
> incomplete non-array type 'struct mtx'
> [-Wtentative-definition-incomplete-type]
> static struct mtx freebsd_crypto_mutex;
>   ^
>
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:15:
> note: forward declaration of 'struct mtx'
> static struct mtx freebsd_crypto_mutex;
>   ^
>
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:63:35:
> error: expected identifier
> MTX_SYSINIT(freebsd_crypto_mutex, _crypto_mutex, "FreeBSD ZFS
> Crypto mutex", MTX_DEF);
>   ^
>
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:63:1:
> warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
> MTX_SYSINIT(freebsd_crypto_mutex, _crypto_mutex, "FreeBSD ZFS
> Crypto mutex", MTX_DEF);
> ^
>
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:19:
> error: tentative definition has type 'struct mtx' that is never
> completed
> static struct mtx freebsd_crypto_mutex;
>   ^
>
> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/freebsd_crypto.c:62:15:
> note: forward declaration of 'struct mtx'
> static struct mtx freebsd_crypto_mutex;
>   ^
> 2 warnings and 2 errors generated.
> *** Error code 1
> On Wed, Aug 22, 2018 at 4:28 AM Matthew Macy  wrote:
> >
> > On Tue, Aug 21, 2018 at 6:55 PM Matthew Macy  wrote:
> >
> > > To anyone with an interest in native encryption in ZFS please test the
> > > projects/zfs-crypto-merge-0820 branch in my freebsd repo:
> > > https://github.com/mattmacy/networking.git
> > >
> > >
> > Oh and I neglected to state that this work is being supported by iX
> Systems
> > and the tree is all built on work done by Sean Fagan at iX Systems.
> Please
> > keep him in the loop on any problems encountered.
> > Thanks.
> >
> >
> >
> > > ( git clone  https://github.com/mattmacy/networking.git -b
> > > projects/zfs-crypto-merge-0820 )
> > >
> > > The UI is quite close to the Oracle Solaris ZFS crypto with minor
> > > differences for specifying key location.
> > >
> > > Please note that once a feature is enabled on a pool it can't be
> > > disabled. This means that if you enable encryption support on a pool
> > > you will never be able to import it in to a ZFS without encryption
> > > support. For this reason I would strongly advise against using this on
> > > any pool that can't be easily replaced until this change has made its
> > > way in to HEAD after the freeze has been lifted.
> > >
> > >
> > > By way of background the original ZoL commit can be found at:
> > >
> > >
> https://github.com/zfsonli

Re: Native Encryption for ZFS on FreeBSD CFT

[Matthew Macy]

On Tue, Aug 21, 2018 at 20:22 Alan Somers  wrote:

> On Tue, Aug 21, 2018 at 9:13 PM Sean Fagan  wrote:
>
>> On Aug 21, 2018, at 8:11 PM, Alan Somers  wrote:
>> > The last time I looked (which was a long time ago), Oracle's ZFS
>> encryption looked extremely vulnerable to watermarking attacks.  Did
>> anybody ever fix that?
>>
>> This isn’t Oracle’s implementation, but I don’t know how compatible or
>> not it is with it.
>>
>> Sean.
>>
>
> It wasn't just an implementation problem, it was in the design.  IIRC,
> Oracle's encryption allowed encrypted blocks to be deduplicated.  There's
> pretty much no way to defend against watermarking attacks with such a
> design.  Does the new encryption design have the same flaw?
>

I would ask the original developer that question (see the commit I linked
to). The current dedup  Implementation is terrible, so there are very few
users of it.

-M



>
> -Alan
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Native Encryption for ZFS on FreeBSD CFT

[Matthew Macy]

On Tue, Aug 21, 2018 at 6:55 PM Matthew Macy  wrote:

> To anyone with an interest in native encryption in ZFS please test the
> projects/zfs-crypto-merge-0820 branch in my freebsd repo:
> https://github.com/mattmacy/networking.git
>
>
Oh and I neglected to state that this work is being supported by iX Systems
and the tree is all built on work done by Sean Fagan at iX Systems. Please
keep him in the loop on any problems encountered.
Thanks.



> ( git clone  https://github.com/mattmacy/networking.git -b
> projects/zfs-crypto-merge-0820 )
>
> The UI is quite close to the Oracle Solaris ZFS crypto with minor
> differences for specifying key location.
>
> Please note that once a feature is enabled on a pool it can't be
> disabled. This means that if you enable encryption support on a pool
> you will never be able to import it in to a ZFS without encryption
> support. For this reason I would strongly advise against using this on
> any pool that can't be easily replaced until this change has made its
> way in to HEAD after the freeze has been lifted.
>
>
> By way of background the original ZoL commit can be found at:
>
> https://github.com/zfsonlinux/zfs/pull/5769/commits/5aef9bedc801830264428c64cd2242d1b786fd49
>
> Thanks in advance.
> -M
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Native Encryption for ZFS on FreeBSD CFT

[Matthew Macy]

To anyone with an interest in native encryption in ZFS please test the
projects/zfs-crypto-merge-0820 branch in my freebsd repo:
https://github.com/mattmacy/networking.git

( git clone  https://github.com/mattmacy/networking.git -b
projects/zfs-crypto-merge-0820 )

The UI is quite close to the Oracle Solaris ZFS crypto with minor
differences for specifying key location.

Please note that once a feature is enabled on a pool it can't be
disabled. This means that if you enable encryption support on a pool
you will never be able to import it in to a ZFS without encryption
support. For this reason I would strongly advise against using this on
any pool that can't be easily replaced until this change has made its
way in to HEAD after the freeze has been lifted.


By way of background the original ZoL commit can be found at:
https://github.com/zfsonlinux/zfs/pull/5769/commits/5aef9bedc801830264428c64cd2242d1b786fd49

Thanks in advance.
-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

drm / drm2 removal in 12

[Matthew Macy]

Just in case anyone misses the change to UPDATING:

20180821:
drm and drm2 have been removed. Users on powerpc, 32-bit hardware,
or with GPUs predating Radeon and i915 will need to install the
graphics/drm-legacy-kmod. All other users should be able to use
one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
graphics/drm-next-kmod, graphics/drm-devel-kmod.

Note that this applies only to 12.

-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic excl->shared for an AF_LOCAL socket

[Matthew Macy]

On Sun, Aug 19, 2018 at 4:32 PM Rick Macklem  wrote:

> Hi,
>
> PR#230752 shows a witness panic() for "excl->shared" on a vnode lock.
> In this case, the kernel RPC code is trying to do a soconnect() on an
> AF_LOCAL
> socket. The code is unp_connectat() looks like is does a straightforward
> namei()/lookup(), so I am surprised to see this.
>
> Does anyone know if AF_LOCAL (unix domain) sockets are somehow handled
> differently for namei()/lookup() which might cause this?
>
> I've requested more info from the reporter w.r.t. when this happens.
> (I'd guess when the nfsuserd is terminating or has terminated or ???)
>
> Thanks for any help with this, rick
>

I don't know what's special in this case, but I did revamp the locking
there several months back so I'll take a look next weekend.
-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Sharing compiled builds between multiple 12-CURRENT boxes.

[Matthew Seaman]

On 19/08/2018 01:55, Shane Ambler wrote:
>> I run 12-CURRENT on few machines, some more powerful that other (all
>> of them x86_64, march varies). 

> You can use freebsd-update by setting up your own update server
> https://www.freebsd.org/doc/en/articles/freebsd-update-server

freebsd-upgrade(8) only works for releases, and not 12-CURRENT as the OP
specified.

    Cheers,

Matthew





signature.asc
Description: OpenPGP digital signature

Re: kernel build failure

[Matthew Macy]

On Mon, Aug 13, 2018 at 5:33 PM Rick Macklem  wrote:

> Rodney W. Grimes wrote:
> >> On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:
> >>
> >> > Sorry guys, last time I touched ZFS I tried to push to make it an
> option to
> >> > statically link and was actually told that it wasn't something anyone
> else
> >> > wanted. The issue comes from ZFS not being in NOTES and thus not in
> LINT.
> >>
> >> If consensus is that "options ZFS" is no longer valid, then maybe
> >> UPDATING should reflect the fact.
> >>
> >> I can live with loading zfs.ko and opensolaris.ko at boot time, but I
> >> think this is a step backwards.
> >
> >Please no, I can think of no sound reason that you should be
> >forced to use modules.
> I thought that ZFS was required to be a module because of the licensing
> terms (they didn't want any CDDL code in the core kernel)?
>

It can't be in _GENERIC_ for that reason. There's no reason it can't be in
LINT or end users can't configure a CDDL tainted kernel.
-M




> rick
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel build failure

[Matthew Macy]

On Sun, Aug 12, 2018 at 3:25 PM Warner Losh  wrote:

>
>
> On Sun, Aug 12, 2018, 3:40 PM Matthew Macy  wrote:
>
>> Sorry guys, last time I touched ZFS I tried to push to make it an option
>> to
>> statically link and was actually told that it wasn't something anyone else
>> wanted. The issue comes from ZFS not being in NOTES and thus not in LINT.
>>
>
> LINT is generated from NOTES automatically...
>

Yes, hence the "and thus not in LINT"




> Warner
>
> -M
>>
>> On Sun, Aug 12, 2018 at 12:46 PM Trond Endrestøl <
>> trond.endres...@fagskolen.gjovik.no> wrote:
>>
>> > On Sun, 12 Aug 2018 16:51+0200, Trond Endrestøl wrote:
>> >
>> > > On Sun, 12 Aug 2018 09:37-0400, Michael Butler wrote:
>> > >
>> > > > Is anyone else seeing this when building a new kernel with ZFS
>> > compiled in?
>> > > >
>> > > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vers.o
>> > > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/kernel
>> > > > --- kernel ---
>> > > > linking kernel
>> > > > ld: error: undefined symbol: dbuf_stats_init
>> > > > >>> referenced by dbuf.c
>> > > > >>>   dbuf.o:(dbuf_init)
>> > > >
>> > > > ld: error: undefined symbol: dbuf_stats_destroy
>> > > > >>> referenced by dbuf.c
>> > > > >>>   dbuf.o:(dbuf_fini)
>> > > > *** [kernel] Error code 1
>> > >
>> > > I was just about to create a thread of my own.
>> > >
>> > > I suspect r337670 didn't add everything
>> > > cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c depends on. See
>> > > lines 652 and 697.
>> > >
>> > > Meanwhile, I'll attempt to revert to r337669.
>> >
>> > r337669 builds and runs.
>> >
>> > Looking further into r337670, it seems
>> > cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dbuf.h added prototypes
>> > for dbuf_stats_init() and dbuf_stats_destroy(), but no implementation
>> > can be found in any of the files affected by r337670.
>> >
>> > --
>> > Trond.
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
>> "
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel build failure

[Matthew Macy]

Sorry guys, last time I touched ZFS I tried to push to make it an option to
statically link and was actually told that it wasn't something anyone else
wanted. The issue comes from ZFS not being in NOTES and thus not in LINT.

-M

On Sun, Aug 12, 2018 at 12:46 PM Trond Endrestøl <
trond.endres...@fagskolen.gjovik.no> wrote:

> On Sun, 12 Aug 2018 16:51+0200, Trond Endrestøl wrote:
>
> > On Sun, 12 Aug 2018 09:37-0400, Michael Butler wrote:
> >
> > > Is anyone else seeing this when building a new kernel with ZFS
> compiled in?
> > >
> > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/vers.o
> > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/kernel
> > > --- kernel ---
> > > linking kernel
> > > ld: error: undefined symbol: dbuf_stats_init
> > > >>> referenced by dbuf.c
> > > >>>   dbuf.o:(dbuf_init)
> > >
> > > ld: error: undefined symbol: dbuf_stats_destroy
> > > >>> referenced by dbuf.c
> > > >>>   dbuf.o:(dbuf_fini)
> > > *** [kernel] Error code 1
> >
> > I was just about to create a thread of my own.
> >
> > I suspect r337670 didn't add everything
> > cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c depends on. See
> > lines 652 and 697.
> >
> > Meanwhile, I'll attempt to revert to r337669.
>
> r337669 builds and runs.
>
> Looking further into r337670, it seems
> cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dbuf.h added prototypes
> for dbuf_stats_init() and dbuf_stats_destroy(), but no implementation
> can be found in any of the files affected by r337670.
>
> --
> Trond.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ci.freebsd.org 's FreeBSD-head-{amd64, i386}-test started failing after -r337332 (last good), inp_gcmoptions involved

[Matthew Macy]

Thanks I'll take a look.

On Sat, Aug 11, 2018 at 10:41 AM Li-Wen Hsu  wrote:

> With the VMs images on artifact.ci.freebsd.org, I can reproduce this with:
>
> root@:/usr/tests/sys/netinet # kyua debug
> fibs_test:slaac_on_nondefault_fib6
> fib is 1
> fib is 2
> net.inet6.ip6.forwarding: 0 -> 1
> net.inet6.ip6.rfc6204w3: 0 -> 1
> /sbin/pfctl
> /sbin/ipf
> ipf: IP Filter: v5.1.2 (608)
> setfib 1 ifconfig epair0a inet6 2001:db8:115e:fc32::2/64 fib 1
> setfib 2 ifconfig epair0b inet6 -ifdisabled accept_rtadv fib 2 up
> Executing command [ ifconfig epair0b ]
> Executing co
>
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer = 0x20:0x80ded513
> stack pointer   = 0x28:0xfe0012158860
> frame pointer   = 0x28:0xfe00121588a0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 0 (softirq_0)
> [ thread pid 0 tid 100013 ]
> Stopped at  inp_gcmoptions+0xe3:movqll+0x33f(%rax),%r9
> db> bt
> Tracing pid 0 tid 100013 td 0xf800031de000
> inp_gcmoptions() at inp_gcmoptions+0xe3/frame 0xfe00121588a0
> epoch_call_task() at epoch_call_task+0x21a/frame 0xfe00121588f0
> gtaskqueue_run_locked() at gtaskqueue_run_locked+0x139/frame
> 0xfe0012158940
> gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x88/frame
> 0xfe0012158970
> fork_exit() at fork_exit+0x84/frame 0xfe00121589b0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe00121589b0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> db>
>
>
> Li-Wen
>
> On Mon, Aug 6, 2018 at 9:53 AM Alan Somers  wrote:
> >
> > I can't reproduce the failure.  On my VM, with a kernel from Aug-2, the
> test passes.  But it sure seems to be consistent in Jenkins.
> >
> > On Sun, Aug 5, 2018 at 6:59 PM, Matthew Macy  wrote:
> >>
> >> That looks like it is tied to changes I made 3 months ago. I won't be
> at my desk until the end of the week, but if it's consistent I can take a
> look.
> >>
> >> -M
> >>
> >> On Sun, Aug 5, 2018 at 17:57 Li-Wen Hsu  wrote:
> >>>
> >>> On Sun, Aug 5, 2018 at 6:23 PM Mark Millard  wrote:
> >>> >
> >>> > amd64: #8493 was for -r337342 and #8492 (last good) was for -r337332
> .
> >>> > more recent builds also failed. -r337342 and laster also failed for
> >>> > i386.
> >>> >
> >>> > All but a sys/gettimeofday.2 change after -r337332 through -r337342
> >>> > are from Brad Davis. It is unclear to me how the changes matches up
> >>> > with the below example (from the log for amd64). It might not?
> >>> >
> >>> > For example (i386 is similar):
> >>> >
> >>> > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/8493/consoleText
> >>> >
> >>> >
> sys/netinet/fibs_test:subnet_route_with_multiple_fibs_on_same_subnet  ->
> >>> >
> >>> > Fatal trap 9: general protection fault while in kernel mode
> >>> > cpuid = 0; apic id = 00
> >>> > instruction pointer = 0x20:0x80ded213
> >>> > stack pointer   = 0x28:0xfe002648c960
> >>> > frame pointer   = 0x28:0xfe002648c9a0
> >>> > code segment= base 0x0, limit 0xf, type 0x1b
> >>> > = DPL 0, pres 1, long 1, def32 0, gran 1
> >>> > processor eflags= interrupt enabled, resume, IOPL = 0
> >>> > current process = 0 (softirq_0)
> >>> > [ thread pid 0 tid 100013 ]
> >>> > Stopped at  inp_gcmoptions+0xe3:movqll+0x33f(%rax),%r9
> >>>
> >>> I think this is because we are trying to enable more tests:
> >>> https://github.com/freebsd/freebsd-ci/pull/25
> >>>
> >>> I'm looking into that.  If I cannot resolve this quickly I will revert
> >>> it temporarily.
> >>>
> >>> Li-Wen
> >>>
> >>> --
> >>> Li-Wen Hsu 
> >>> https://lwhsu.org
> >>> ___
> >>> freebsd-current@freebsd.org mailing list
> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >>> To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
> >
> >
>
>
> --
> Li-Wen Hsu 
> https://lwhsu.org
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic after ifioctl/if_clone_destroy

[Matthew Macy]

The struct thread is typesafe. The problem is that the link is no longer
typesafe now that it’s not part of the thread. Thanks for pointing this
out. I’ll commit a fix later today.

-M



On Mon, Aug 6, 2018 at 02:39 Hans Petter Selasky  wrote:

> Hi Matthew,
>
> On 08/06/18 10:02, Hans Petter Selasky wrote:
> > - if ((tdwait = TAILQ_FIRST(>er_tdlist)) != NULL &&
> > - TD_IS_RUNNING(tdwait->et_td)) {
>
> At least the TD_IS_RUNNING() check is invalid. The "tdwait" structure is
> in the control of the other CPU and "tdwait->et_td" might be invalid at
> any time, so accessing any members here is not a good idea.
>
> It is pretty clear that the epoch was exited during the loop:
>
>  etd->et_td = (void*)0xDEADBEEF;
>
> fault virtual address   = 0xdeadc2ff
> fault code  = supervisor read data, page not present
>
>
> If you remove the TD_IS_RUNNING() check I'm not sure how useful this
> loop will be ...
>
> --HPS
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ci.freebsd.org 's FreeBSD-head-{amd64, i386}-test started failing after -r337332 (last good), inp_gcmoptions involved

[Matthew Macy]

That looks like it is tied to changes I made 3 months ago. I won't be at my
desk until the end of the week, but if it's consistent I can take a look.

-M

On Sun, Aug 5, 2018 at 17:57 Li-Wen Hsu  wrote:

> On Sun, Aug 5, 2018 at 6:23 PM Mark Millard  wrote:
> >
> > amd64: #8493 was for -r337342 and #8492 (last good) was for -r337332 .
> > more recent builds also failed. -r337342 and laster also failed for
> > i386.
> >
> > All but a sys/gettimeofday.2 change after -r337332 through -r337342
> > are from Brad Davis. It is unclear to me how the changes matches up
> > with the below example (from the log for amd64). It might not?
> >
> > For example (i386 is similar):
> >
> > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/8493/consoleText
> >
> > sys/netinet/fibs_test:subnet_route_with_multiple_fibs_on_same_subnet  ->
> >
> > Fatal trap 9: general protection fault while in kernel mode
> > cpuid = 0; apic id = 00
> > instruction pointer = 0x20:0x80ded213
> > stack pointer   = 0x28:0xfe002648c960
> > frame pointer   = 0x28:0xfe002648c9a0
> > code segment= base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags= interrupt enabled, resume, IOPL = 0
> > current process = 0 (softirq_0)
> > [ thread pid 0 tid 100013 ]
> > Stopped at  inp_gcmoptions+0xe3:movqll+0x33f(%rax),%r9
>
> I think this is because we are trying to enable more tests:
> https://github.com/freebsd/freebsd-ci/pull/25
>
> I'm looking into that.  If I cannot resolve this quickly I will revert
> it temporarily.
>
> Li-Wen
>
> --
> Li-Wen Hsu 
> https://lwhsu.org
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic after ifioctl/if_clone_destroy

[Matthew Macy]

If you could give me a self-contained reproducer that would expedite a fix.

Thanks.
-M

On Sun, Aug 5, 2018 at 08:36 Roman Bogorodskiy  wrote:

> Running -CURRENT r336863 on amd64. Get the following panic right after
> (or during) boot:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 04
> fault virtual address   = 0xdeadc2ff
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80bd7858
> stack pointer   = 0x28:0xfe008b445580
> frame pointer   = 0x28:0xfe008b4455c0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 903 (libvirtd)
>
> Traceback is:
>
> (kgdb) #0  doadump (textdump=0) at pcpu.h:230
> #1  0x8043dc7b in db_dump (dummy=,
> dummy2=, dummy3=,
> dummy4=) at /usr/src/sys/ddb/db_command.c:574
> #2  0x8043da49 in db_command (cmd_table=)
> at /usr/src/sys/ddb/db_command.c:481
> #3  0x8043d7c4 in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:534
> #4  0x804409ef in db_trap (type=,
> code=) at /usr/src/sys/ddb/db_main.c:252
> #5  0x80bdd513 in kdb_trap (type=12, code=0, tf= out>)
> at /usr/src/sys/kern/subr_kdb.c:693
> #6  0x810769f1 in trap_fatal (frame=0xfe008b4454c0,
> eva=3735929599)
> at /usr/src/sys/amd64/amd64/trap.c:884
> #7  0x81076b12 in trap_pfault (frame=0xfe008b4454c0,
> usermode=) at pcpu.h:230
> #8  0x8107611a in trap (frame=0xfe008b4454c0)
> at /usr/src/sys/amd64/amd64/trap.c:427
> #9  0x810518ac in calltrap ()
> at /usr/src/sys/amd64/amd64/exception.S:230
> #10 0x80bd7858 in epoch_block_handler_preempt (
> global=, cr=0xfe00760c3a00,
> arg=) at /usr/src/sys/kern/subr_epoch.c:256
> #11 0x803994fd in ck_epoch_synchronize_wait (
> global=0xf800030c5680,
> cb=0x80bd77a0 , ct=0x0)
> at /usr/src/sys/contrib/ck/src/ck_epoch.c:407
> #12 0x80bd7630 in epoch_wait_preempt (epoch=0xf800030c5680)
> at /usr/src/sys/kern/subr_epoch.c:389
> #13 0x80c983bf in if_delgroup (ifp=0xf80003aab800,
> groupname=0xf80005ff5e00 "bridge") at /usr/src/sys/net/if.c:1514
> #14 0x80c9f2b2 in if_clone_destroyif (ifc=0xf80005ff5e00,
> ifp=0xf80003aab800) at /usr/src/sys/net/if_clone.c:325
> #15 0x80c9f0d5 in if_clone_destroy (name=0xfe008b4458d0
> "virbr0")
> at /usr/src/sys/net/if_clone.c:288
> #16 0x80c9a2c3 in ifioctl (so=0xf80007edca38, cmd=2149607801,
> data=, td=)
> at /usr/src/sys/net/if.c:3053
> #17 0x80c04259 in kern_ioctl (td=0xf80007c1a580,
> fd=, com=,
> data=) at file.h:330
> #18 0x80c03f2e in sys_ioctl (td=0xf80007c1a580,
> uap=0xf80007c1a940) at /usr/src/sys/kern/sys_generic.c:712
> #19 0x81077401 in amd64_syscall (td=0xf80007c1a580, traced=0)
> at subr_syscall.c:135
> #20 0x8105218d in fast_syscall_common ()
> at /usr/src/sys/amd64/amd64/exception.S:500
> #21 0x0008028f4c0a in ?? ()
>
>
> Previous frame inner to this frame (corrupt stack?)
>
>
> Current language:  auto; currently minimal
>
>
> (kgdb)
>
> It looks like panic happens during network interfaces related
> operations. Couple of dmesg lines before panic:
>
> Aug  5 19:02:42 romashka rtsold[585]:  interface
> bridge0 removed
> Aug  5 19:02:42 romashka kernel: bridge0: Ethernet address:
> 02:af:41:48:c7:00
> Aug  5 19:02:42 romashka kernel: bridge0: changing name to 'virbr-ab'
> Aug  5 19:02:42 romashka kernel: tap0: Ethernet address: 00:bd:8d:11:f7:00
> Aug  5 19:02:42 romashka kernel: tap0: link state changed to UP
> Aug  5 19:02:42 romashka kernel: tap0: changing name to 'virbr-ab-nic'
> Aug  5 19:02:42 romashka kernel: virbr-ab-nic: promiscuous mode enabled
> Aug  5 19:02:42 romashka kernel: virbr-ab: link state changed to UP
> Aug  5 19:02:42 romashka rtsold[585]:  interface
> tap0 removed
> Aug  5 19:02:43 romashka dnsmasq[1047]: setting --bind-interfaces option
> because of OS limitations
> Aug  5 19:02:43 romashka dnsmasq[1047]: warning: no upstream servers
> configured
> Aug  5 19:02:43 romashka kernel: virbr-ab-nic: link state changed to DOWN
> Aug  5 19:02:43 romashka kernel: virbr-ab: link state changed to DOWN
> Aug  5 19:02:43 romashka kernel: bridge1: Ethernet address:
> 02:af:41:48:c7:01
> Aug  5 19:02:43 romashka kernel: bridge1: changing name to 'virbr0'
> Aug  5 19:02:43 romashka rtsold[585]:  interface
> bridge1 removed
> Aug  5 19:02:43 romashka kernel: tap1: Ethernet address: 00:bd:53:14:f7:01
> Aug  5 19:02:43 romashka kernel: tap1: link state changed to UP
> Aug  5 19:02:43 romashka kernel: tap1: changing name to 'virbr0-nic'
> Aug  5 19:02:43 romashka kernel: virbr0: link state changed to UP
> Aug  5 

Re: [PATCH] Recent libm additions

[Matthew Macy]

On Sun, Jul 15, 2018 at 12:43 PM, Montgomery-Smith, Stephen
 wrote:
> On 07/15/2018 02:09 PM, Warner Losh wrote:
>> I'm not saying that he has a lock. I'm saying he's are domain expert and
>> many mistakes can be avoided by talking to him.
>>
>> I'm saying we have history here, and that history, while poorly documented,
>> wasn't followed. To the extent it is poorly documented, we should fix that.
>>
>> Warner
>>
> I agree that we should document the process.  Maybe also include
> freebsd-numerics@ on these discussions, as that is why it was created.
>
> But I'm really glad these changes were committed.  I have found the
> people tend to drag their feet a lot on numerics issues.
>
> Has anyone done an analysis of the OpenBSD powl functions from an
> accuracy point of view?  That is, to test how many ULP of error these
> functions have?  If not, I could give it a go, although not for several
> months because life is very busy.

They're also used by Julia. You might ask there first.
-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [PATCH] Recent libm additions

[Matthew Macy]

On Sun, Jul 15, 2018 at 11:33 AM, Steve Kargl
 wrote:
> On Sun, Jul 15, 2018 at 12:06:47PM -0600, Ian Lepore wrote:
>>
>> On the other hand, what information is there for someone to know that
>> Steve should be involved in a review? There is nothing in MAINTAINERS.
>> The review was on phab for almost a month, and phab is supposedly the
>> preferred way to do reviews these days.
>>
>> Steve is no longer a committer, but that doesn't preclude him having a
>> phab account and participating in reviews. If he doesn't like using
>> phab (and I can certainly understand that POV), an entry in MAINTAINERS
>> would still be helpful, unless we have a rule that only committers can
>> be listed in there.
>>
>
> Patch should be sent the the freebsd-numeric mailing list.
> phab appear after I was forced to hand in my commit bit, so
> I don't have a phab account.

Anyone can have a phab account.

-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [PATCH] Recent libm additions

[Matthew Macy]

On Sun, Jul 15, 2018 at 10:17 AM, Steve Kargl
 wrote:
> On Sun, Jul 15, 2018 at 11:00:41AM -0600, Ian Lepore wrote:
>> On Sun, 2018-07-15 at 08:06 -0700, Steve Kargl wrote:
>> > Index: ld80/e_powl.c
>> > ===
>> > --- ld80/e_powl.c   (revision 336304)
>> > +++ ld80/e_powl.c   (working copy)
>> > @@ -77,6 +77,7 @@
>> >  #include
>> >
>> >  #include "math_private.h"
>> > +#include "polevll.c"
>>
>> If a file contains inline function definitions and is intended only to
>> be included into another file and not compiled separately, shouldn't
>> its name be spelled polevll.h ?
>>
>
> Well, actually, the functions in polevll.c should have been copied
> into ld80/e_powl.c, and polevall.c should never have been committed.
> Unfortunately, the code was not reviewed for correctness.  I've
> made the minimum changes to address the two issues I've noted.
> Feel free to either copy the functions and delete the polevall.c
> or rename it.
>


In the bug report you cite, Chris Lattner states: "This is actually an
unspecified feature of C99 (whether it supports the _Imaginary type).
It is desirable to support this, but not a regression.

I'm more than happy to commit these changes, but neither including a
.c file nor compensating for the absence of a gcc feature in clang is
a correctness fix. In the future you might wish to subscribe to phab
reviews so that you can be notified when changes like this are under
consideration. Thank you for your input.

-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [PATCH] Recent libm additions

[Matthew Macy]

On Sun, Jul 15, 2018 at 10:55 AM, Warner Losh  wrote:
> On Sun, Jul 15, 2018, 11:23 AM K. Macy  wrote:
>
>> >
>> > Well, actually, the functions in polevll.c should have been copied
>> > into ld80/e_powl.c, and polevall.c should never have been committed.
>> > Unfortunately, the code was not reviewed for correctness.
>>
>> That is not correct. Please stop repeating it. Bruce Evans and John
>> Baldwin were both looped in. Neither made this observation.
>>
>
> Steve is the fp guy these days. And it wasn't reviewed by him. He's mad you
> cut him out of the loop. Arguing about pedantic points of process does no
> one any good.

Thanks for the tip. I'm sorry. I was under the impression that he gave
up his bit: https://reviews.freebsd.org/rD46886

So we have a maintainer who has opted to not have a bit. So be it.

Nonetheless, reviews.freebsd.org is the established channel by which
the project does code reviews. I stand by my recommendation and will
add him to reviews in the future.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: atomic changes break drm-next-kmod?

[Matthew Macy]

This seems like a clang inline asm bug. Could you try building the port
with a recent gcc against an unpatched HEAD?

On Tue, Jul 3, 2018 at 15:38 Pete Wright  wrote:

>
>
> On 07/03/2018 15:29, John Baldwin wrote:
> > That seems like kgdb is looking at the wrong CPU.  Can you use
> > 'info threads' and look for threads not stopped in 'sched_switch'
> > and get their backtraces?  You could also just do 'thread apply
> > all bt' and put that file at a URL if that is easiest.
> >
>
>
> sure thing John - here's a gist of "thread apply all bt"
>
> https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed
>
> cheers!
> -pete
>
> --
> Pete Wright
> p...@nomadlogic.org
> @nomadlogicLA
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: atomic_testandclear_, atomic_testandset_

[Matthew Macy]

On Sun, Jun 24, 2018 at 01:42 Konstantin Belousov 
wrote:

> On Sat, Jun 23, 2018 at 01:38:07PM -0700, Matthew Macy wrote:
> > It turns out ck already has equivalent primitives. Pardon the noise.
> Why not to add trivial cmpset-based implementations to the lacking
> arches ?  If maintainers prefer proper ll/cs assembly, they would
> have the time to do it properly without ultimatum.



Good point.

>
>
> It is useful to utilize consistent atomic(9) KPI across kernel.
>


Agreed

>
> >
> > -M
> >
> > On Sat, Jun 23, 2018 at 12:18 Matthew Macy  wrote:
> >
> > > The functions in the subject are both documented in atomic(9) and are
> > > implemented by every arch except sparc64 and MIPS. I have some code in
> > > review that uses them that I intend to commit once the various design
> > > issues are addressed. Please implement them so that those targets can
> > > remain part of universe.
> > >
> > > Thanks in advance.
> > > -M
> > >
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: atomic_testandclear_, atomic_testandset_

[Matthew Macy]

It turns out ck already has equivalent primitives. Pardon the noise.

-M

On Sat, Jun 23, 2018 at 12:18 Matthew Macy  wrote:

> The functions in the subject are both documented in atomic(9) and are
> implemented by every arch except sparc64 and MIPS. I have some code in
> review that uses them that I intend to commit once the various design
> issues are addressed. Please implement them so that those targets can
> remain part of universe.
>
> Thanks in advance.
> -M
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

atomic_testandclear_, atomic_testandset_

[Matthew Macy]

The functions in the subject are both documented in atomic(9) and are
implemented by every arch except sparc64 and MIPS. I have some code in
review that uses them that I intend to commit once the various design
issues are addressed. Please implement them so that those targets can
remain part of universe.

Thanks in advance.
-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Page fault in udp_usrreq.c:823

[Matthew Macy]

I made changes this morning / early afternoon.
-M

On Thu, Jun 21, 2018 at 6:41 PM, Cy Schubert  wrote:
> Like as of now?
>
> The last panic occurred this morning after a build last night.
>
>
> --
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  http://www.FreeBSD.org
>
> The need of the many outweighs the greed of the few.
>
>
> In message  il.com>
> , Matthew Macy writes:
>> Try updating. It should be fixed.
>>
>> On Thu, Jun 21, 2018 at 6:14 PM, Cy Schubert  wrot
>> e:
>> > In message <20180620090957.ga...@x2.osted.lan>, Peter Holm writes:
>> >> 20180620 10:32:47 all (1/1): udp.sh
>> >> Kernel page fault with the following non-sleepable locks held:
>> >> shared rw udpinp (udpinp) r = 0 (0xf80bbc808d78) locked @ netinet/in_p
>> cb.
>> >> c:2398
>> >> stack backtrace:
>> >> #0 0x80c00733 at witness_debugger+0x73
>> >> #1 0x80c01b11 at witness_warn+0x461
>> >> #2 0x81075763 at trap_pfault+0x53
>> >> #3 0x81074d7a at trap+0x2ba
>> >> #4 0x8105076c at calltrap+0x8
>> >> #5 0x80dd21b0 at udp_ctlinput+0x50
>> >> #6 0x80d3081d at icmp_input+0x96d
>> >> #7 0x80d316d7 at ip_input+0x3f7
>> >> #8 0x80cc0a92 at netisr_dispatch_src+0xa2
>> >> #9 0x80ca3ebe at ether_demux+0x16e
>> >> #10 0x80ca5377 at ether_nh_input+0x427
>> >> #11 0x80cc0a92 at netisr_dispatch_src+0xa2
>> >> #12 0x80ca437f at ether_input+0x8f
>> >> #13 0x80cbc500 at iflib_rxeof+0xc90
>> >> #14 0x80cb6b6f at _task_fn_rx+0x7f
>> >> #15 0x80bdd209 at gtaskqueue_run_locked+0x139
>> >> #16 0x80bdcf88 at gtaskqueue_thread_loop+0x88
>> >> #17 0x80b54514 at fork_exit+0x84
>> >>
>> >>
>> >> Fatal trap 12: page fault while in kernel mode
>> >> cpuid = 10; apic id = 0a
>> >> fault virtual address = 0x8
>> >> fault code  = supervisor read data, page not present
>> >> instruction pointer = 0x20:0x80dd2423
>> >> stack pointer = 0x0:0xfe4a5500
>> >> frame pointer = 0x0:0xfe4a55a0
>> >> code segment  = base 0x0, limit 0xf, type 0x1b
>> >>= DPL 0, pres 1, long 1, def32 0, gran 1
>> >> processor eflags = interrupt enabled, resume, IOPL = 0
>> >> current process  = 0 (if_io_tqg_10)
>> >> [ thread pid 0 tid 100069 ]
>> >> Stopped at  udp_common_ctlinput+0x263:  cmpq$0,0x8(%rax)
>> >> db>
>> >>
>> >> Details @ https://people.freebsd.org/~pho/stress/log/udp_usrreq.txt
>> >>
>> >> --
>> >> Peter
>> >> ___
>> >> freebsd-current@freebsd.org mailing list
>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>> >>
>> >
>> > This is surprisingly similar to my panic. Twice since June 19.
>> >
>> > slippy# kgdb /boot/kernel/kernel vmcore.3
>> > GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD]
>> > Copyright (C) 2018 Free Software Foundation, Inc.
>> > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.
>> > html>
>> > This is free software: you are free to change and redistribute it.
>> > There is NO WARRANTY, to the extent permitted by law.  Type "show
>> > copying"
>> > and "show warranty" for details.
>> > This GDB was configured as "x86_64-portbld-freebsd12.0".
>> > Type "show configuration" for configuration details.
>> > For bug reporting instructions, please see:
>> > <http://www.gnu.org/software/gdb/bugs/>.
>> > Find the GDB manual and other documentation resources online at:
>> > <http://www.gnu.org/software/gdb/documentation/>.
>> > For help, type "help".
>> > Type "apropos word" to search for commands related to "word"...
>> > Reading symbols from /boot/kernel/kernel...Reading symbols from
>> > /usr/lib/debug//boot/kernel/kernel.debug...done.
>> > done.
>> >
>> > Unread portion of the kernel message buffer:
>> > Copyright (c) 1992-2018 The FreeBSD Project.
>> > Copyright (c) 1979, 1980, 1983,

Re: Page fault in udp_usrreq.c:823

[Matthew Macy]

Try updating. It should be fixed.

On Thu, Jun 21, 2018 at 6:14 PM, Cy Schubert  wrote:
> In message <20180620090957.ga...@x2.osted.lan>, Peter Holm writes:
>> 20180620 10:32:47 all (1/1): udp.sh
>> Kernel page fault with the following non-sleepable locks held:
>> shared rw udpinp (udpinp) r = 0 (0xf80bbc808d78) locked @ netinet/in_pcb.
>> c:2398
>> stack backtrace:
>> #0 0x80c00733 at witness_debugger+0x73
>> #1 0x80c01b11 at witness_warn+0x461
>> #2 0x81075763 at trap_pfault+0x53
>> #3 0x81074d7a at trap+0x2ba
>> #4 0x8105076c at calltrap+0x8
>> #5 0x80dd21b0 at udp_ctlinput+0x50
>> #6 0x80d3081d at icmp_input+0x96d
>> #7 0x80d316d7 at ip_input+0x3f7
>> #8 0x80cc0a92 at netisr_dispatch_src+0xa2
>> #9 0x80ca3ebe at ether_demux+0x16e
>> #10 0x80ca5377 at ether_nh_input+0x427
>> #11 0x80cc0a92 at netisr_dispatch_src+0xa2
>> #12 0x80ca437f at ether_input+0x8f
>> #13 0x80cbc500 at iflib_rxeof+0xc90
>> #14 0x80cb6b6f at _task_fn_rx+0x7f
>> #15 0x80bdd209 at gtaskqueue_run_locked+0x139
>> #16 0x80bdcf88 at gtaskqueue_thread_loop+0x88
>> #17 0x80b54514 at fork_exit+0x84
>>
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 10; apic id = 0a
>> fault virtual address = 0x8
>> fault code  = supervisor read data, page not present
>> instruction pointer = 0x20:0x80dd2423
>> stack pointer = 0x0:0xfe4a5500
>> frame pointer = 0x0:0xfe4a55a0
>> code segment  = base 0x0, limit 0xf, type 0x1b
>>= DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags = interrupt enabled, resume, IOPL = 0
>> current process  = 0 (if_io_tqg_10)
>> [ thread pid 0 tid 100069 ]
>> Stopped at  udp_common_ctlinput+0x263:  cmpq$0,0x8(%rax)
>> db>
>>
>> Details @ https://people.freebsd.org/~pho/stress/log/udp_usrreq.txt
>>
>> --
>> Peter
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>
>
> This is surprisingly similar to my panic. Twice since June 19.
>
> slippy# kgdb /boot/kernel/kernel vmcore.3
> GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD]
> Copyright (C) 2018 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later  html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-portbld-freebsd12.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /boot/kernel/kernel...Reading symbols from
> /usr/lib/debug//boot/kernel/kernel.debug...done.
> done.
>
> Unread portion of the kernel message buffer:
> Copyright (c) 1992-2018 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-CURRENT #355 r335477M: Thu Jun 21 05:26:35 PDT 2018
> root@slippy:/export/obj/opt/src/svn-current/amd64.amd64/sys/BREAK
> amd64
> FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on
> LLVM 6.0.0)
> VT(vga): text 80x25
> module_register: cannot register mmc/mmcsd from kernel; already loaded
> from mmcsd.ko
> Module mmc/mmcsd failed to register: 17
> CPU: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz (2294.83-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x206a7  Family=0x6  Model=0x2a  Stepping=7
>   Features=0xbfebfbff GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>   Features2=0x1dbae3bf 3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,XSAVE,OSXSAVE,A
> VX>
>   AMD Features=0x28100800
>   AMD Features2=0x1
>   XSAVE Features=0x1
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> real memory  = 8589934592 (8192 MB)
> avail memory = 8080965632 (7706 MB)
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
> random: unblocking device.
> ioapic0  irqs 0-23 on motherboard
> random: entropy device external interface
> module_register_init: MOD_LOAD (vesa, 0x8097b700, 0) error 19
> kbd1 at kbdmux0
> nexus0
> vtvga0:  on motherboard
> cryptosoft0:  on motherboard
> acpi0:  on motherboard
> acpi0: Power Button (fixed)
> cpu0:  on acpi0
> hpet0:  iomem 0xfed0-0xfed003ff on 

Base FreeBSD-lld package dependency problems...

[Matthew Seaman]

Here's a little glitch with packaged base I stumbled upon.

On a freshly pkg upgrade'd 12-current machine, I see:

codling:/usr/home/matthew:# pkg info -dr FreeBSD-lld-12.0.s20180609030436
FreeBSD-lld-12.0.s20180609030436
Depends on :
FreeBSD-runtime-12.0.s20180609030436

So, no dependencies except the runtime.

But look at this:

codling:/usr/home/matthew:# pkg autoremove
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 2 packages:

Installed packages to be REMOVED:
FreeBSD-libefivar-12.0.s20180609030436
FreeBSD-libregex-12.0.s20180609030436

Number of packages to be removed: 2

Proceed with deinstalling packages? [y/N]: y
[1/2] Deinstalling FreeBSD-libefivar-12.0.s20180609030436...
[1/2] Deleting files for FreeBSD-libefivar-12.0.s20180609030436: 100%
[2/2] Deinstalling FreeBSD-libregex-12.0.s20180609030436...
[2/2] Deleting files for FreeBSD-libregex-12.0.s20180609030436: 100%


codling:/usr/home/matthew:# pkg install -f FreeBSD-lld
Updating base repository catalogue...
base repository is up to date.
Updating ports repository catalogue...
ports repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 3 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
FreeBSD-libefivar: 12.0.s20180609030436 [base]
FreeBSD-libregex: 12.0.s20180609030436 [base]

Installed packages to be REINSTALLED:
FreeBSD-lld-12.0.s20180609030436 [base]

Number of packages to be installed: 2
Number of packages to be reinstalled: 1

Proceed with this action? [y/N]: y
[1/3] Reinstalling FreeBSD-lld-12.0.s20180609030436...
[1/3] Extracting FreeBSD-lld-12.0.s20180609030436: 100%
[2/3] Installing FreeBSD-libefivar-12.0.s20180609030436...
[2/3] Extracting FreeBSD-libefivar-12.0.s20180609030436: 100%
[3/3] Installing FreeBSD-libregex-12.0.s20180609030436...
[3/3] Extracting FreeBSD-libregex-12.0.s20180609030436: 100%

Looks like FreeBSD-lld might need to register dependencies on
FreeBSD-libefivar and FreeBSD-libregex?  Or perhaps its some other
package that needs libefivar and libregex?

Cheers,

Matthew



signature.asc
Description: OpenPGP digital signature

Re: rust broken?

[Matthew Macy]

On Thu, Jun 7, 2018 at 10:33 Michael Butler 
wrote:

> Ah - I'll re-enable that to see if it makes a difference ..
>


It's not a question of enabling. It doesn't explicitly use the 11 symbols.
Rust developers assume that every OS has a frozen ABI like Linux. The rust
from rustup will only work on 11. This is why you need to use the port /
pkg.

-M


> I missed that in the comparison between my two build environments :-(
>
> Michael
>
> On 06/07/18 13:21, Matthew Macy wrote:
> >
> > Rustup uses the 11 ABI.
> >
> > On Thu, Jun 7, 2018 at 10:11 Alan Somers  > <mailto:asom...@freebsd.org>> wrote:
> >
> > Can you reproduce the problem using rust installed from rustup
> > instead of
> > from Ports?  If so, you should file a bug report with the Rust
> > developers.
> > Hint: when using Rustup, you'll have to use vresion 1.26.1 instead of
> > 1.26.0.
> > -Alan
> >
> > On Thu, Jun 7, 2018 at 9:44 AM, Michael Butler
> > mailto:i...@protected-networks.net>>
> > wrote:
> >
> > > In response to a Firefox update, I tried to build the new version.
> > > However, rust now fails with a core-dump in the build process.
> > >
> > > checking for libffi > 3.0.9... yes
> > > checking MOZ_FFI_CFLAGS... -I/usr/local/lib/libffi-3.2.1/include
> > > checking MOZ_FFI_LIBS... -L/usr/local/lib -lffi
> > > checking for rustc... /usr/local/bin/rustc
> > > checking for cargo... /usr/local/bin/cargo
> > > checking rustc version...
> > > DEBUG: Executing: `/usr/local/bin/rustc --version --verbose`
> > > DEBUG: The command returned non-zero exit status -12.
> > > DEBUG: Its output was:
> > > DEBUG: | rustc 1.26.0
> > > DEBUG: | binary: rustc
> > > DEBUG: | commit-hash: unknown
> > > DEBUG: | commit-date: unknown
> > > DEBUG: | host: x86_64-unknown-freebsd
> > > DEBUG: | release: 1.26.0
> > > ERROR: Command `/usr/local/bin/rustc --version --verbose` failed
> with
> > > exit status -12.
> > >
> > > Attempts to rebuild rust (and cargo) from the bootstrap files fail
> in
> > > similar fashion.
> > >
> > > On a machine running a SVN r334538 kernel but more recent
> > user-land, it
> > > builds successfully. With (the only difference being) a kernel at
> SVN
> > > r334748, it does not.
> > >
> > > Any hints/thoughts?
> > >
> > > imb
> > > ___
> > > freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org>
> > mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to
> > "freebsd-current-unsubscr...@freebsd.org
> > <mailto:freebsd-current-unsubscr...@freebsd.org>"
> > >
> > ___
> > freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org>
> > mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to
> > "freebsd-current-unsubscr...@freebsd.org
> > <mailto:freebsd-current-unsubscr...@freebsd.org>"
> >
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"