Happy New Year, everyone!!!

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?

Does illumos have a more expanded documentations to F_QUOTACTL, F_REVOKE and F_HASREMOTELOCKS?

It seems to not be included in the fcntl manual page documentation

iprog4u: Changing an existing NIC driver or building a new NIC driver?

Building a new one for Realtek 8125.

So not modifying rge... okay. You'll need to create new source (usr/src/uts/common/io/<driver-name>)

Or modifying any other Realtek driver to include what is needed to get this one up and running. Pretty green to driver development.

The rge(4D) driver has some realtek GigE parts. Lemme look up the 8125...

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.

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.

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.

I don't know if other OSes fold their 8125 support into the same driver that supports 8169 and its peers or not.

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.

More specifically it seemed to be entries for the 2.5G but also for 1G and another one or two speeds.

I see source for re(4D) that seems to match our rge(4D), but I saw no mention of the 8125 part.

(Doing a fresh pull of my local freebsd git repo now just to be sure...)

iprog4u: What driver drives 8125 in FreeBSD?

realtek-re-kmod -- I had to install the 2nd most recent package to get it to work.

100.something did not work but the one prior did.

Oh hell...

Fun stuff eh?

it's a driver from Realtek, not something with FreeBSD source you can poke around in...

Yeah... that's gonna be special. :(

Correct and there is little to no info about on it.

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?

Yeah... you want 2.5, get the Intel I225 or I226 (drivable with igc(4D)). Realtek's opacity makes Broadcom look open by comparison.

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.)

Sorry I can't be of more immediate assistance.

Lol, understood. One last shot, someone else looked into this: illumos.org/issues/13729

→ BUG 13729: Driver issue with Realtek RTL8125 (New)

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."

YEah... that comment was from me.

Ha, just noticed the lineup of nicks there.

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?

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?

I can make NO promises there, however. HW vendors can be wily. :(

Well you were still very helpful and I appreciate the direction.

Thanks.

[illumos-gate] 17013 it is a new year for prototypes, 2025 -- Toomas Soome <tsoome⊙mc>

/var/tmp cleanups are now covered with patches, should clean /tmp as well...

[illumos-gate] 17011 ZTS: functional/mount scripts are not removing /var/tmp/testdir.X dirs -- Toomas Soome <tsoome⊙mc>

Thanks for cleaning all of those tests up tsoome.

yw. we do need ability to probe (at least to the extent) the changes we need to have...

ofc cleaning up leftovers is cosmetical:D

but being able to use the test suite more easily is great

at least to the point where re-reading those scripts will reveal stupid bugs

like writing 32-bit ints to 64-bit ones:D

[illumos-gate] 17005 ZTS: mmp_pool_destroy should remove MMP_DIR -- Toomas Soome <tsoome⊙mc>

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.

and some of them just don't work in a VM anyway

l2arc ones are all hit and miss, but l2arc updates need some prerequisites to land first.

some mmp tests are just not ported and the reason is, there is chunk of code to produce mmp related kstats missing...

who was it who was most looking into 2038 stuff?

was that danmcd?

# IPD 14 illumos and Y2038

right, but writing the ipd and doing anything about it are sometimes different

yep.

it's got a bunch of large-scale thoughts, but nobody in there seems to have looked at time32_t consumers except UFS

which is probably the least important of them

(compared to lastlog, utmp being spicy, pci hotplug being confusing...)

it looks like vHCI too

and: ./uts/common/os/sunndi.c:781: (ndi_dc_return_ap_state) ap_state32.ap_last_change = (time32_t)ap->ap_last_change;

nfsv3 nfslog.

that last one might be SYSCALL32, actually, which are fine

(the hotplug last_change isn't)

tsoome: I think NFS is mostly syscall32-y too?

or is it like UFS where the timestamps are explicitly 32bit?

I was just browsing quick 'git grep time32_t' :)

yeah, you have to click through to make sure it's not only for kernel supporting 32bit processes :)

which have their own problems

I was looking at things that screw even 64bit processes on 64bit systems, at least potentially

because I think a lot of thinking so far has been they're pretty much fine

(outside of utmp, lastlog, etc.)

I'm not sure what some of this is doing with time32_t, it might not actually be storing _time_ in there

which is its own can of worms :\

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

(you can blame alanc for making me look again)

:(

second one is cheating, I didn't even make it to /time.*32/ yet

btw, I believe github.com/illumos/illumos-gate/blo…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

oh, but that's because we fixed illumos.org/opensolaris/bugdb/bug.html#!4246033 in snv_170, didn't realize it was so late

→ OpenSolaris issue 4246033: 64-bit mktime() with Olson zoneinfo timezones and dates past 1/19/2038 problem (Fix Understood)

Also, searches would be much easier if people wrote 2038 in commments instead of 2039: github.com/illumos/illumos-gate/blo…mmon/fs/zfs/zfs_vnops.c#L3147-L3158

illumos.org/opensolaris/bugdb/bug.html#!4372494 should be a simple matter of converting to LP64

→ OpenSolaris issue 4372494: *find* find does not traverse directories warped into the future. (Defer)

same for illumos.org/opensolaris/bugdb/bug.html#!4372497

→ OpenSolaris issue 4372497: *rm* rm does not remove files warped into the future. (Defer)

and just FYI 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

that is the same trick I worry some stuff is doing with an actual time32_t