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.

`which bsdconfig` so i would start in usr.sbin/bsdconfig

hernan604: df -h

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

under freebsd, does kevent() can do the job that prctl(PR_SET_PDEATHSIG, SIGHUP) does under linux?

When the parent process of the process calling this function dies, the child process will receive the SIGHUP signal.

ohmyplan9: you might want procctl(2) instead

thanks. i'll man it

well, you probably want EVFILT_PROC with NOTE_EXIT then if you want it as kevent()

ohmyplan9: i'm looking at PROC_PDEATHSIG_CTL, looks to be equivalent of that linux call as you describe it

thank you very much . My first time porting software to FreeBSD, a very simple, zero-configuration software that turns a process into a daemon

mzar: the blocklist patch stuff is still ongoing, jlduran/freebsd-src #105

thanks for the info, FYI: I am still relying on my solution and it works fine

yeah I'm testing this but TBH preferred the original 1-line patch we had too

I get why this is being done differently tho, bumping upstream version now has the changed behaviour and that needs to be accommodated

we should pick it with all the drawbacks

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 (bugs.freebsd.org/bugzilla/show_bug.cgi?id=285340) was another manifestation of bugs.freebsd.org/bugzilla/show_bug.cgi?id=280036 despite DCO not being in use (at the time; I'm now using DCO).

dvl: interesting, I almost forgot about that one

dvl: looks like my client ovpn speedup was imaginary

f451: oh no. why?

no idea, but htere's not a lot of documentation. mayve it needs freebsd with ovpn loaded and configured on both sides?

this is a commercial vpn. i can only modify the .ovpn file client side

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 github.com/Beckhoff/freebsd-src/commits/phab/corvink/15.0/nvidia-wip - is that the best shot?

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

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.

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.

ok thats good. must be something else then

f451: go through the post again and make sure your FreeBSD client checks all the boxes.

have you been able to try dco-client-enabled only?

f451: I have not tried that, no.

i have some baremetal i can test it on

it'll take a while ;)

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

mzar: when you say with and without encryption, do you mean DCO, or something else?

you are 100% right dvl. I meant in-kernel encryption aka DCO

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.

DCO was created to speedup OpenVPN which was behind the competitors

o0x1eef: yes works for me and yes thats the best shot, just apply the patch to the latest release

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

getz: Thanks! I'm hopeful :)

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

+1

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

Sounds good. Ready to reboot and give it a try

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]

lspci will still identify the card even when it's passed through

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.

o0x1eef: in loader.conf you got pptdevs="" and then you pass it through to bhyve right?

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?

pciconf -lv * :)

o0x1eef: which id do you assign to be inside bhyve?

it could be already assigned if you chose 1/0/0 in bhyve

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'

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.

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

[ 1.440888] systemd[1]: Detected virtualization bhyve.

is systemd offended ?

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.

sweet

it appears that the identifier hack is no longer needed so thats nice

+1