07:30:26 <nerozero> happy owner of intel i9 - 32 core cpu, ruct compile time - 2h 11m, llvm - 3h gcc12 - 3h 10m; total bild time - 4h
07:31:29 <nerozero> poudriere 8 parallel builds
07:31:38 <angry_vincent> notice, that rust builds also including of special version of llvm ( bundled )
07:31:50 <nerozero> ^^ exactly
07:32:14 <nerozero> on my older machine it takes usulally 2 days for entire port tree
07:32:26 * nerozero crying
07:33:34 <nerozero> btw can I limit cpu core count used by the compiler ?
07:33:46 <nerozero> something like setting affinity?
07:34:07 <RhodiumToad> several ways, depending
07:34:14 <nerozero> usually i'm doing nice -n 9
07:34:45 <nerozero> RhodiumToad, heard about cpuset but looks like it doing something else ...
07:34:50 <RhodiumToad> poudriere's default is to ask individual port builds to use only one cpu, but some build scripts use more anyway
07:35:16 <nerozero> that is what i'm trying to avoid
07:35:39 <RhodiumToad> what exactly do you want then?
07:35:59 <nerozero> limit cpu usage say only 4
07:36:20 <RhodiumToad> 4 per individual worker, or 4 total?
07:36:49 <nerozero> 4 cpu core window for everything poudriere's doing
07:36:54 <angry_vincent> maybe with cpuset?
07:37:20 <nerozero> cpuset ( if i understood correctly ) reserve cores for specific task
07:37:28 <RhodiumToad> not quite
07:37:45 <nerozero> never worked, read only manual and has 0 experience
07:37:52 <RhodiumToad> it restricts a process and descendents to a specific set of cores
07:38:11 <nerozero> so it is affinity right ?
07:38:19 <RhodiumToad> other processes can still use those cores
07:38:21 <nerozero> is it work same way as nice do ?
07:38:45 <nerozero> any child process takes same rules ?
07:39:02 <RhodiumToad> the main problem is that at least historically, most things that detected the number of cpus to decide how many jobs to run didn't pay attention to cpuset
07:39:15 <RhodiumToad> yes, child processes inherit the limitation
07:40:29 <RhodiumToad> basically, if you run poudriere under a cpuset limiting it to 4 cpus, you might also need to specify -J 4 and also set MAKE_JOBS_NUMBER_LIMIT=4 in a make.conf file
07:40:56 <nerozero> my worries is that while compiling some ports, when all cpu cores are used cpu temperature ( core temperatures reported by coretemp ) is ~80 c)
07:41:07 <RhodiumToad> I say "might" because I've not tried recently
07:41:38 <nerozero> RhodiumToad, thank you for detailed answer, I will try and reply results here
07:41:58 <nerozero> probably on this weekends
07:44:16 <nerozero> https://imgur.com/9Rneu55
07:44:17 <VimDiesel> Title: Ksnip Screenshot - Imgur
07:45:39 <Mystified> hi Guys, can you please share your knowledeg, please !  Hardware. Mac Mini Late 2011 i7-2nd Gen, Network issues. Network, Wlan I have issues broadcom B4331, ethernet is Broadcom tigon. TG3 .  The Goal. To use this as a home media server. I have Linux installed a gentoo flavour ( Redcore), drivers worked out of the box. The issue is using the linux drivers I have droputs, regardless if I disable each of the network device,
07:45:44 <Mystified>  even tried usb wifi, still the same issues. My question is if switch to Freebsd, is bsd drivers the same as linux, & will likely to have the same issues. I'm just wondering that Freebsd code is closer to Mac, that it may work better with bsd than linux? Your thoughts would be appreciated, thanks kindly !
07:46:57 <angry_vincent> nerozero: is it physical 32 core cpu, or hyperthreading?
07:47:19 <Mystified> me 64 bit
07:47:44 <Mystified> baremetal
07:48:24 <nerozero> Mystified, under bsd try ifconfig <interfacename> -tso
07:49:00 <nerozero> bsd doesn't supports tso well, so in my case it was the cause of loosing packets and random disconnects
07:49:20 <Mystified> I'haven't tried freebsd yet, I do Have a copy of live nomad, I could try that.
07:50:03 <nerozero> angry_vincent, https://www.intel.com/content/www/us/en/products/sku/230496/intel-core-i913900k-processor-36m-cache-up-to-5-80-ghz/specifications.html
07:50:05 <VimDiesel> Title: Intel® Core™ i9-13900K Processor
07:50:07 <nerozero> that is the cpu
07:51:01 <nerozero> Mystified, you are asking question in FreeBSD channel, I would suggest to find appropriate channel to your system
07:52:11 <Mystified> nerozero: exactly the same, I'm looking to purchase, usb ethernet port to see ifit will work.
07:54:37 <nerozero> Mystified, try to look into this thread: https://forums.freebsd.org/threads/broadcom-bcm4313.74040/
07:54:38 <VimDiesel> Title: Solved - Broadcom BCM4313 | The FreeBSD Forums
07:54:46 <nerozero> maybe u find something useful
07:55:22 <Mystified> nerozero: I'm going install freebsd, hopefully see if it works, but you suggest an appropiate channel, are suggesting there may be other channels. ie. broadcom network or mac devices repurposed channels. If so, I'm happy to hear your suggest ions
07:55:49 <Mystified> thanks nerozero: :)
08:02:36 <RhodiumToad> rwp: for what it's worth I just tried booting the 13.2 release raw VM image, and all the expected files have their schg flags set
08:29:25 <RhodiumToad> rwp: and I also tried a fresh 13.2 install from the release image and that has the schg bits too
08:30:32 <nerozero> RhodiumToad, what is "schg bit" about ? I had just updated the system to 13.2
08:30:50 <RhodiumToad> nerozero: this is from a discussion last night
08:31:10 <nerozero>  any special I should be worry about ?
08:31:16 <RhodiumToad> nothing to do with you
08:31:24 <nerozero> :) ok thanks :)
12:37:59 <danel1> Hey guys :) We're facing a kernel panic with FreeBSD 12.4 and have reported a bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270816
12:38:01 <VimDiesel> Title: 270816 – kernel panic in sym_hipd.c
12:38:32 <danel1> Sadly there wasn't a reaction until now and we're kinda stuck without further help.. Is there any way to push this issues or provide further information?
12:40:34 <RhodiumToad> that looks like a fairly old driver?
12:41:44 <yuripv> danel1: is it vmware vm with "lsilogic" adapter?
12:42:05 <danel1> Nope. It's a VM running on OpenStack (based on Ubuntu).
12:42:26 <yuripv> and you don't have an option to use another emulated adapter?
12:47:04 <RhodiumToad> surely you could be using virtio-blk or virtio-scsi
12:49:36 <danel1> as i understand correct, this would lead to an other driver that would be used instead of the LSI driver which "uses" the code from "sym_hipd.c"?
12:53:00 <RhodiumToad> sys/dev/sym is the symbios / LSI scsi driver, its sole purpose is to interact with LSI hardware; if the emulated hardware doesn't behave exactly like physical hardware it could easily cause issues.
12:54:07 <RhodiumToad> if you can have the VM present disks as virtio devices instead, then the LSI driver would never be used
12:55:21 <RhodiumToad> I'm assuming that this is emulated hardware rather than, say, passthrough of a physical device
13:06:48 <danel1> Yeah that kinda makes sense.. good catch.. let me take a look and verify
13:24:59 <nerozero> hi, could somebody give me a hint, what is a proper way to create tap interface in rc.conf ?
13:30:19 <RhodiumToad> nerozero: cloned_interfaces="tap0 tap1"   (for as many as you want)
13:30:46 <nerozero> RhodiumToad, I thought that was only for bridges ....
13:30:50 <nerozero> thanks!
13:30:51 <RhodiumToad> nerozero: and then  ifconfig_tap0="..."   to configure the interface
13:31:04 <nerozero> the rest is clear, thank you
13:31:18 <RhodiumToad> remember that you can only have one cloned_interfaces line, so it needs to have everything in it
13:32:17 <nerozero> RhodiumToad, :) yes
13:33:46 <nerozero> Is it a good idea to rename interface to give them a better context ?
13:34:06 <nerozero> like ifconfig_re1_name="if_public0"
13:35:18 <nerozero> in case of big numbers of interfaces it is difficult to remember which interface doing what...
13:35:52 <CrtxReavr> nerozero, I think that's squarely in the opinion catagory.
13:36:22 <CrtxReavr> I do not, but I could see scenarios where it might be advantageous.
13:37:52 <nerozero> CrtxReavr, on one machine i have a bhyve virtualization and it cause quite a big mess, so i'm thinking to make some order by give a proper name to interface
13:38:30 <nerozero> is there some better naming way for that ?
13:39:28 <CrtxReavr> nerozero, not up to me to dictate a naming policy for you.
13:39:33 <nerozero> watching 3 pages of interface listing with standard names quite difficult to digest ;)
13:40:02 <nerozero> CrtxReavr, just asking for recommendations
13:41:30 <CrtxReavr> I mean. . . one thing I've always liked about FreeBSD is NIC names conveyed the type of device. . . em0, xl0, sf0, etc. . . those names had meaning, as opposed to linux, where everything was ethX.
13:42:17 <nerozero> in my case I'm having qiote a lot of tap0..tap15 ...
13:42:41 <CrtxReavr> If renaming those interfaces looks like an advantage to you, then do it. . . just think about who else may be sharing in the admin of this implementation and relevant support/documentation issues.
13:43:12 <nerozero> thank you !
16:13:01 <tykling> what is the right way to get always last in rcorder when booting and always first when shutting down, I see securelevel uses "REQUIRE: adjkerntz ipfw pf sysctl_lastload" so I was just going to go with "REQUIRE: securelevel" - thoughts?
16:14:53 <nmz> What is the latest RELEASE 13.1 and how to check?
16:17:32 <yuripv> nmz: what do you mean by "latest"?
16:21:08 <paulf> You mean P8 or P9?
16:21:10 <otis> nmz: 13.1-RELEASE-p7. but the latest production release is 13.2
16:21:14 <paulf> freebsd-version?
16:21:27 <nmz> It seems I'm on 13.1 p6, didn't know there was a p7 until I got a warning that my version was deprecated
16:21:34 <otis> nmz: freebsd-version -kru
16:21:36 <nmz> the P's
16:22:16 <yuripv> you can check the current patch level in e.g. https://cgit.freebsd.org/src/tree/sys/conf/newvers.sh?h=releng/13.1#n57
16:22:18 <VimDiesel> Title: newvers.sh « conf « sys - src - FreeBSD source tree
16:22:57 <paulf> Since 13.2 is out, you'll get warnings to upgrade
16:25:02 <nmz> ok thanks
16:25:17 <nmz> so upgrade straight to 13.2 and not p7?
16:26:02 <paulf> I'm waiting a few more months before upgrading
16:27:55 * meena is waiting for her bike build server to materialise
16:27:56 <otis> nmz: yes, the upgrade directly to 13.2.
16:49:42 <jrm> otis: Will you be able to join the GSoC meeting tomorrow?
16:50:01 <otis> jrm: yes, i'm counting with it.
16:50:56 <jrm> Nice.  It should be short.  Google requests that we begin with such a meeting.
16:58:12 <rwp> RhodiumToad, Hmm...  "Curiouser and curiouser", said Alice.  I'll install a pristine VM here and then compare that against my system.  In a bit...
17:04:13 <rustyaxe> Curiousity, it kills more than just cats.
17:05:25 <parv> Only fair if dogs are also killed
17:06:24 <rustyaxe> curiousity used to be a leading cause of death of humans too :P
17:06:38 <parv> Humans, eh
17:07:52 <rustyaxe> look at their experiments with the atom
17:23:53 <jrm> otis: Some GSoC contributors and mentors hang out in #freebsd-soc here on Libera.Chat.
17:30:22 <rwp> Curiosity is why I will install it in a VM.  That way if there is a problem it can only be a virtual problem. :-)
17:31:27 <rwp> It seems my desktop has drifted somehow from what happens with a fresh install.  Maybe it was the fresh install of 12 and then upgrade to 13.  But that's the issue RhodiumToad and I are discussing.  My system does not have schg (immutable file) flags set on files that a pristine 13 install has set.
17:39:33 <johnjaye> rwp: i'm using freebsd in a vm right now!
17:43:38 <rwp> Shh! We don't want it to know it is living in a simulation. :-)
18:25:37 <meena> rwp: I'm pretty, and sure, that 12 has schg