01:36:30 Happy New Year, everyone!!! 01:51:22 Happy New Year! @rmustacc, after actually following the instructions I was able to compile Illumos-gate under OmniOS using the /opt/onbld/env/omnios-illumos-gate template. What could I change in the illumos.sh to iterate towards building drivers for this NIC? 02:35:15 Does illumos have a more expanded documentations to F_QUOTACTL, F_REVOKE and F_HASREMOTELOCKS? 02:35:50 It seems to not be included in the fcntl manual page documentation 04:42:14 iprog4u: Changing an existing NIC driver or building a new NIC driver? 04:42:47 Building a new one for Realtek 8125. 04:43:22 So not modifying rge... okay. You'll need to create new source (usr/src/uts/common/io/) 04:43:25 Or modifying any other Realtek driver to include what is needed to get this one up and running. Pretty green to driver development. 04:43:51 The rge(4D) driver has some realtek GigE parts. Lemme look up the 8125... 04:44:39 My understanding is it is fairly recent hardware. Was able to get their FreeBSD drivers working under 14.2. Not much else in the way of docs or spec material. 04:44:49 Okay so it's a 2.5GigE realtek. I don't know enough about that device to know how close it is to the devices that rge(4D) supports. 04:47:10 If it's an incremental change from say the 8169 & friends in rge(4D) you could alter rge to also support 8125. I've a feeling it might not be that simple, in which case you'll have to bring up a new driver. 04:48:23 I don't know if other OSes fold their 8125 support into the same driver that supports 8169 and its peers or not. 04:49:11 While luck is generally on my side I would assume that it would not be in this case. Not a C expert but when I looked at the FreeBSD driver it did appear to be another version of existing hardware/drivers/not sure what correct nomenclature is there. 04:50:32 More specifically it seemed to be entries for the 2.5G but also for 1G and another one or two speeds. 04:50:48 I see source for re(4D) that seems to match our rge(4D), but I saw no mention of the 8125 part. 04:51:05 (Doing a fresh pull of my local freebsd git repo now just to be sure...) 04:53:58 iprog4u: What driver drives 8125 in FreeBSD? 04:54:35 realtek-re-kmod -- I had to install the 2nd most recent package to get it to work. 04:54:54 100.something did not work but the one prior did. 04:55:06 Oh hell... 04:55:19 Fun stuff eh? 04:55:21 it's a driver from Realtek, not something with FreeBSD source you can poke around in... 04:55:34 Yeah... that's gonna be special. :( 04:55:37 Correct and there is little to no info about on it. 04:58:03 Les sigh. With a small army of these mini-pc's one could build their own mini-cloud...if the NICs worked. So would it be better to just pick hardware that is supported or could one realistically embark on building this? 04:59:51 Yeah... you want 2.5, get the Intel I225 or I226 (drivable with igc(4D)). Realtek's opacity makes Broadcom look open by comparison. 05:01:04 For mini-PCs, there doesn't seem to be a lot of choice. (And like I mentioned, the Broadcom ones MIGHT not help you much either.) 05:01:18 Sorry I can't be of more immediate assistance. 05:01:19 Lol, understood. One last shot, someone else looked into this: https://www.illumos.org/issues/13729 05:01:20 → BUG 13729: Driver issue with Realtek RTL8125 (New) 05:01:49 Specifically, "Take a look at $UTS/common/io/rge and notice that there are values for 8169, but none for 8125. You will need to examine what's there in rge_main.c, rge_chip.c, rge.h, and maybe more, and augment them with 8125 values. That will at least get you 1GigE support." 05:02:15 YEah... that comment was from me. 05:02:40 Ha, just noticed the lineup of nicks there. 05:02:40 I mean, if you can get rge to detect 8125 and treat it like one of the GigE parts, maybe you can at least get GigE? 05:03:18 Maybe that's Good Enough for the short term? My advice there stands. Look for 8169 detection, and see if recognizing 8125 and acting like it's an 8169 will help? 05:03:31 I can make NO promises there, however. HW vendors can be wily. :( 05:04:29 Well you were still very helpful and I appreciate the direction. 05:05:15 Thanks. 07:16:36 [illumos-gate] 17013 it is a new year for prototypes, 2025 -- Toomas Soome 09:04:27 /var/tmp cleanups are now covered with patches, should clean /tmp as well... 20:00:00 [illumos-gate] 17011 ZTS: functional/mount scripts are not removing /var/tmp/testdir.X dirs -- Toomas Soome 20:02:45 Thanks for cleaning all of those tests up tsoome. 20:03:56 yw. we do need ability to probe (at least to the extent) the changes we need to have... 20:04:30 ofc cleaning up leftovers is cosmetical:D 20:04:49 but being able to use the test suite more easily is great 20:05:19 at least to the point where re-reading those scripts will reveal stupid bugs 20:06:07 like writing 32-bit ints to 64-bit ones:D 20:07:16 [illumos-gate] 17005 ZTS: mmp_pool_destroy should remove MMP_DIR -- Toomas Soome 20:07:18 Yeah.. I have a reasonable framework for spinning up a pretty large VM with a load of disks and running the ZFS testsuite now, but it's still a bit painful with some tests being a bit flakey. 20:08:08 and some of them just don't work in a VM anyway 20:08:40 l2arc ones are all hit and miss, but l2arc updates need some prerequisites to land first. 20:09:51 some mmp tests are just not ported and the reason is, there is chunk of code to produce mmp related kstats missing... 20:10:45 who was it who was most looking into 2038 stuff? 20:10:48 was that danmcd? 20:11:36 # IPD 14 illumos and Y2038 20:12:39 right, but writing the ipd and doing anything about it are sometimes different 20:13:16 yep. 20:14:22 it's got a bunch of large-scale thoughts, but nobody in there seems to have looked at time32_t consumers except UFS 20:14:34 which is probably the least important of them 20:15:11 (compared to lastlog, utmp being spicy, pci hotplug being confusing...) 20:15:25 it looks like vHCI too 20:15:43 and: ./uts/common/os/sunndi.c:781: (ndi_dc_return_ap_state) ap_state32.ap_last_change = (time32_t)ap->ap_last_change; 20:15:53 nfsv3 nfslog. 20:16:19 that last one might be SYSCALL32, actually, which are fine 20:16:40 (the hotplug last_change isn't) 20:17:12 tsoome: I think NFS is mostly syscall32-y too? 20:17:47 or is it like UFS where the timestamps are explicitly 32bit? 20:18:13 I was just browsing quick 'git grep time32_t' :) 20:18:38 yeah, you have to click through to make sure it's not only for kernel supporting 32bit processes :) 20:18:48 which have their own problems 20:19:01 I was looking at things that screw even 64bit processes on 64bit systems, at least potentially 20:19:07 because I think a lot of thinking so far has been they're pretty much fine 20:19:12 (outside of utmp, lastlog, etc.) 20:19:31 I'm not sure what some of this is doing with time32_t, it might not actually be storing _time_ in there 20:19:36 which is its own can of worms :\ 20:20:43 and stuff like, the only thing I can find done with cn_last_change that's useful is it gets assigned to the (big enough) hp_last_change 20:21:54 (you can blame alanc for making me look again) 20:42:12 https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/cron/elm.c#L65 20:43:18 :( 20:43:31 https://github.com/illumos/illumos-gate/blob/be043fa09e31603f2a89ace77471c4de9fe0d8b9/usr/src/uts/common/sys/bufmod.h#L125 20:44:10 second one is cheating, I didn't even make it to /time.*32/ yet 20:46:37 btw, I believe https://github.com/illumos/illumos-gate/blob/master/usr/src/man/man3c/strftime.3c#L796-L798 is wrong, left over from before the move to zic version 2 expanded timestamps from 32 to 64-bit in zic files 20:48:01 oh, but that's because we fixed https://illumos.org/opensolaris/bugdb/bug.html#!4246033 in snv_170, didn't realize it was so late 20:48:02 → OpenSolaris issue 4246033: 64-bit mktime() with Olson zoneinfo timezones and dates past 1/19/2038 problem (Fix Understood) 20:51:46 Also, searches would be much easier if people wrote 2038 in commments instead of 2039: https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/fs/zfs/zfs_vnops.c#L3147-L3158 20:53:55 https://illumos.org/opensolaris/bugdb/bug.html#!4372494 should be a simple matter of converting to LP64 20:53:56 → OpenSolaris issue 4372494: *find* find does not traverse directories warped into the future. (Defer) 20:54:44 same for https://illumos.org/opensolaris/bugdb/bug.html#!4372497 20:54:45 → OpenSolaris issue 4372497: *rm* rm does not remove files warped into the future. (Defer) 20:58:57 and just FYI https://github.com/illumos/illumos-gate/blob/master/usr/src/head/shadow.h#L64 while 32-bit is days since 1970, not seconds, so you have ~5.8 million years before it runs out 21:19:30 that is the same trick I worry some stuff is doing with an actual time32_t