trying to copy over to /boot/efi/

no go

anyone have alfonso siciliano's ear? re sysctltui, it needs 1 feature not listed in the update: search. put in a search query, and any sysctl in the whole mib that matches query is listed, in its hierarchy

having someone's ear would be evidence of a crime of mutilation.

Thanks for everyone helping out with my issue. It has been narrowed down to being a problem with SMP on my specific processor. I am going to try a different processor on my next day off...

SponiX: have you tried updating your bios? Assuming you have an update available.

kenrap: last BIO/UEFI update for this board was 2017

How's that so when your bios version data is "07/10/2019"?

LOL .. Maybe I am wrong on that

Anyway, I do have the "latest" one ever published for the board already installed

okay, I can boot FreeBSD up fine on this chip as long as Hyper Threading is disabled

SponiX, I normally disable Hyperthreading anyway for performance reasons. When I benchmarked CAD simulators they were about 5%-10% slower with HT on than off. Faster with HT off. So no loss to disable it.

rwp: it is a bit of a loss for me compiling software, so I will likely follow up with additional information added to my bug report, and hope it gets resolved. BUT, I am glad to have a booting FreeBSD without it in the mean time

Ouch, was hoping it won't be a SMP issue. But 20 (real) cores is still plenty

are jail resource constraints as accurate as vm resource constraints? asking because i wanna optimize some server software i run so i want to create a bunch of different instances of it with different build settings etc and see which variant runs most efficiently

and i have 1 big server to use for it so i gotta divvy that up somehow

What do you mean when you say "... as accurate as vm resource constraints?" ?

What are you comparing when looking for a difference in accurate results here.

i want to load test variant, then load test other variant, and go through each, and see how many requests/s each variant can handle. and i want to limit each variant to 1 core and some slice of ram

so if i base it on bhyve vms, each vm will get 1 cpu core to use, or if i base it on jails, each jail would get 1 core

but i just didn't know if i can limit a jail to exactly 1 core and xGB ram like i can do with bhyve vms

kerneldove: cpuset(1) might be of help

i read about that skull. if i go with jails for it, can you mix cpuset and rctl?

and how would i decide if i want to use cpuset with rctl or not?

well, that's weird. Installed on a new disk, set up samba to move configs over, attached the old disk, and now it boots the old disk. I cannot boot the old disk alone. I can ssh in, samba is running, but now my zraid won't show up.

nevermind, imported the zraid, working now. Now I have a weird hobbled system, but it's up for now.

kerneldove: i don't really have experience with it. I only tried (and failed) to limit memory for a jail once. but you definitely can assign a cpuset to a specific jail

or rather: specific jails

divlamir: Yeah, and I can continue to follow up on my bug report from FreeBSD itself now that this is figured out

SponiX: Might be a BIOS/UEFI bug, you can try switching between the two boot methods, if you have you boot drive setup to boot bothways

Check for BIOS updates too

divlamir: this is an X99 board from 2015 -- It has the latest bios published for it :P

I did try booting BIOS also. still does the same thing

Out of ideas for now. A verbose boot? Maybe it won't give much more info, given it's interrupted so early, but still..

I will attach FreeBSD 14.3 inxi dmesg and anything else they ask for. And see if the bug report gets any traction

In the mean time I'll be back and forth between Fedora 42 and FreeBSD 14.3

I probably won't do CURRENT until I can have all my cores for building, OR beefy18 finishes pkg builds for it, so I can have some binary support

SponiX: I'm missing an argument for how does using CURRENT relates to building it with all cores? You'd often cross-platform-build it for low performance platforms.

regis: right now 15 Current/Pre-release doesn't have any binary packages available to it like 14.3 does. It will be several more days before beefy18 finishes its package builds and they are published

So, if I installed current again, I myself would be building packages for days again. and I don't have the motivation to do that. So, I can just continue with 14.3 and its binary pkg support to do my stuff

SponiX: Binary packages can be (as I understand but have no experience around) "cross"-build for low performance platform on a buffy hardware using other platform.

I mean, I don't imagine mis-using raspberry PI to build LLVM :(

SponiX: man.freebsd.org/cgi/man.cgi?poudriere

for resource limiting proc usage of a jail, what's the difference between using cpuset and rctl to get the job done?