01:40:42 Hello everybody! May somebody point out please where is the main bsdconfig or sade repository? I can't find them anywhere, but I want to inspect a bit these tools to look for improvements. 03:49:03 `which bsdconfig` so i would start in usr.sbin/bsdconfig 04:24:20 hernan604: df -h 04:24:59 Ohh my bad. I just found out that bsdconfig diskmgmt (or sade), really points to bsdinstall partedit. Had to take a closer look. Thank you rtprio 09:14:15 under freebsd, does kevent() can do the job that prctl(PR_SET_PDEATHSIG, SIGHUP) does under linux? 09:16:39 When the parent process of the process calling this function dies, the child process will receive the SIGHUP signal. 09:20:15 ohmyplan9: you might want procctl(2) instead 09:20:49 thanks. i'll man it 09:20:49 well, you probably want EVFILT_PROC with NOTE_EXIT then if you want it as kevent() 09:21:34 ohmyplan9: i'm looking at PROC_PDEATHSIG_CTL, looks to be equivalent of that linux call as you describe it 09:23:11 thank you very much . My first time porting software to FreeBSD, a very simple, zero-configuration software that turns a process into a daemon 10:50:49 mzar: the blocklist patch stuff is still ongoing, https://github.com/jlduran/freebsd-src/pull/105 10:52:12 thanks for the info, FYI: I am still relying on my solution and it works fine 10:54:07 yeah I'm testing this but TBH preferred the original 1-line patch we had too 10:54:37 I get why this is being done differently tho, bumping upstream version now has the changed behaviour and that needs to be accommodated 10:55:42 we should pick it with all the drawbacks 12:02:15 mzar: FYI, Yesterday I updated all OpenVPN clients from FreeBSD 14.1 to 14.2 - all reported VPN issues have gone away. I suspect the problem (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285340) was another manifestation of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280036 despite DCO not being in use (at the time; I'm now using DCO). 12:09:49 dvl: interesting, I almost forgot about that one 15:57:27 dvl: looks like my client ovpn speedup was imaginary 15:57:47 f451: oh no. why? 15:58:38 no idea, but htere's not a lot of documentation. mayve it needs freebsd with ovpn loaded and configured on both sides? 15:59:10 this is a commercial vpn. i can only modify the .ovpn file client side 16:06:47 Anyone been successful doing a PCI passthrough to Linux for a nvidia GPU ? In lspci on the Linux side I can see the card is detected but the nvidia driver itself doesn't seem to be picking up on any devices. Also came across https://github.com/Beckhoff/freebsd-src/commits/phab/corvink/15.0/nvidia-wip/ - is that the best shot? 16:07:02 dvl: also found that device ovpn0 is on the server config, so am guessing the hwole speedup thing is dependent on both ends running freebsd & openvpn 16:08:36 f451: It is not dependent upon both ends running DCO. DCO affects only your encryption of the stream. It decides whether the code library does it or if the CPU does it. 16:09:43 f451: so, yes, enabling DCO on one end only can improve speed. In my test, my laptop (MacBook) is connected and not using DCO. My OpenVPN server is FreeBSD & DCO enabled. 16:09:47 ok thats good. must be something else then 16:10:13 f451: go through the post again and make sure your FreeBSD client checks all the boxes. 16:11:00 have you been able to try dco-client-enabled only? 16:12:08 f451: I have not tried that, no. 16:12:37 i have some baremetal i can test it on 16:12:46 it'll take a while ;) 16:24:33 f451: I have posted here results without encryption, with encryption on one end and encryption on both ends few weeks ago, pleace check the backlog if you are curious 16:27:21 mzar: when you say with and without encryption, do you mean DCO, or something else? 16:41:02 you are 100% right dvl. I meant in-kernel encryption aka DCO 16:41:55 mzar: Got it. I'm new to DCO and my only use case is OpenVPN. I suppose, given it's a gateway, I should look at other usage. 16:42:57 DCO was created to speedup OpenVPN which was behind the competitors 16:43:52 o0x1eef: yes works for me and yes thats the best shot, just apply the patch to the latest release 16:44:10 what's really amazing, Linux had experimental DCO a lot earlier that ours, but it was FreeBSD that had first DCO working in regular RELEASE 16:44:53 getz: Thanks! I'm hopeful :) 16:46:25 o0x1eef: please report back if it works, I heard that some specific nvidia cards had issues with the vm rebooting but I couldnt find details on what card etc 16:46:36 +1 16:47:26 and if its just the bhyve identifier needed now then it could maybe be a tuneable or an option to bhyve and we wouldnt need the patch 16:48:43 Sounds good. Ready to reboot and give it a try 16:57:40 getz: Unfortunately it was not successful :( Although, it did pick up the audio card, it didn't pick up the GPU associated with it. I also tried to just pass through the GPU, and no luck. 'lspci' still identifies the card. Card: AD104 [GeForce RTX 4070 SUPER] 16:58:23 lspci will still identify the card even when it's passed through 17:00:48 I might try play around with the diff to see if I can make any sense of what goes wrong. But it works for audio at least. 17:03:47 o0x1eef: in loader.conf you got pptdevs="" and then you pass it through to bhyve right? 17:05:29 In /boot/loader.conf we have vmm_load="YES", hw.vmm.amdvi.enable=1, and pptdevs="1/0/0" related to this. pcfconf -va confirms it is passed through. And then I pass 1/0/0 to bhyve. Notice anything incorrect there? 17:06:08 pciconf -lv * :) 17:09:36 o0x1eef: which id do you assign to be inside bhyve? 17:09:57 it could be already assigned if you chose 1/0/0 in bhyve 17:11:01 These are the args I pass (via vm-bhyve): '-s 0,hostbridge -s 31,lpc -s 0:4:0,ahci-hd,/var/vm/eel.home.network/disk0 -s 0:5:0,passthru,1/0/0 -s 0:6:0,fbuf,tcp=0.0.0.0:5900' 17:11:54 I'm not sure how audio would come through but not the GPU if it was a configuration issue ? I did see the audio recongized on boot in Linux's dmesg. But nothing for the gfx card. 17:12:46 o0x1eef: what do you see inside the vm? anything at 0:6:0? Also check your dmesg to make sure its KVMKVMKVM instead of BHYVE 17:15:55 https://gist.github.com/0x1eef/a80ad2bd80bea4f7c607d9f5af05c449 17:17:01 [ 1.440888] systemd[1]: Detected virtualization bhyve. 18:00:20 is systemd offended ? 18:19:52 getz: Thanks a lot for the help. I think it was a PEBKAC problem :) I uninstalled the nvidia 570 server driver and tried again with nvidia-driver-530 - it works. 18:20:04 sweet 18:20:27 it appears that the identifier hack is no longer needed so thats nice 18:21:10 +1