there was a deliberate decision to avoid using the freebsd code originally

(and tbh looking at it, I can understand why, it looks vide coded before that was even a thing -- more than once I've been scratching my head trying to figure something out to discover there's three functions in some file to do the same thing in slightly different ways, and two of them are dead code)

No worries; just wanted to make sure you were aware of it. We've got $100k of E810 cards sitting here, ready to be used.. so we're going to get this into production shape sooner than later. Similarly, I've began porting NVMf, and RDMA, you'll find them in the same location

i mean, the driver works.. just it's a single RX ring right now, and getting RSS to work is a bit like pee-wee's breakfast machine

Wait, there's an E810 driver?

it's not merged yet

sigh, think i40e might be acting up again

@jbk, yeah, I'm keeping an eye on your branch for sure!

Smithx10: w/ those changes?

Im on joyent_20260522T154557Z

Are there a few more I might need? I might be jumping the gun, I just checked err_nodescs (since last time it was an issue) and saw the CNs that the guests with the issues had err_nodescs.

but... the descriptor count was still changing for those that had nodescs, so I dont think its frozen*

code.illumos.org/c/illumos-gate/+/4719 should fix all of that

→ CODE REVIEW 4719: 18075 i40e could be smarter allocating memory for packets (NEW) | illumos.org/issues/18075

aside from the extra warning emitted, it's the same thing we've been running for 2ish years now?

because we were having the same problem w/ jumbo frames and vnic creation taking minutes (if not hours)

e810 has the same limitation (that ends up requiring a similar solution)

though I tried to improve it on e810 based on some archaeology to better explain the behavior

(also the e810 includes some reporting, so if it happens, you will see an error in /var/adm/messages that tells you it's happened)

hey there, got a quick question, does anyone know of a proper explanation of how illumos "projects" work in terms of resource control and stuff? I have a multi-user illumos system where users login via shell, and I wanna know potential restrictions I can put across all users that are part of a group, if that makes sense

i know the man pages are there obviously but I am having a hard time comprehending the greater idea. I know it's to do with resource controls and it spans across users as a total rather than per-user in the project

i think the main thing i'm having trouble with is figuring out what all one can do with it (like, examples of use cases). i *could* ask an LLM but i prefer hearing stuff from a real human, whether it be a blog post or quick message here.

(I'm on OmniOS, but I am posting here since it's not a distro-specific question I think)

operz: I assume you've read project(5); the one thing I use it for is setting shares for the FSS scheduler. I have a "batch" project: "batch:100:Batch Jobs:*:*:project.cpu-shares=(privileged,0,none)" and set BUILD_PROJECT='batch' in my nightly env file while building illumos gate, while my normal project has project.cpu-shares=(privileged,100,none)

operz: and you're correct that this isn't distro-specific

and net effect of this is that the system remains responsive for interactive use despite 0% idle time.

jbk: just making sure I'm not misremembering, i801 != ICE, right?

the only intel 801 I'm aware of is for smbus, not networking

(the sea of numbers and every thing having 5 different names though doesn't help for clarity :P)

the E810 (not 801) though is ice

(see 5 different names)

ah, so that's why '810' perked my ears.

. o O ( I before E except after C ... ICE... oh bother. )

[illumos-gate] 18415 Update to tzdata 2026d -- Robert Mustacchi <rm⊙fo>

As an fyi for folks, the above has changes that are coming into effect Nov 1 so you want to consider roll out.

oh goodie.

The one I'm waiting for is the one that turns off DST changes for USA.

though since the total population of the Northwest Territories covered in the 2026d update is only around 45k people, you might not have any users that notice it

@nomad as my grandpa use to say, "Wish in one hand, sh*t in the other... see which one fills up faster."

though it looks like it maybe removed some aliases (just looking at the diff)

like America/{Chicago,New_York,Denver,Los_Angeles} ?

No, it shouldn't have.

There are a bunch of historical names that were aliased to those that now are their own zones.

jbk: See the section on backward-compat names in iana.org/time-zones/releases/2026d.

ahh.. so probably irrelevant to anyone that doesn't need to calculate timespans that cross the 1st half of the 20th century :)

(like the many entries for Indiana are because of differences in timezones that go back to the 1800s, and only are relevant if you need to work with times that include that span

:D

there's an entire wikipeida page on indiana time zones :)

[illumos-gate] 18412 libproc checks core files for an ELF OSABI that is never set -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 18403 zpool: things get messy with 0 columns -- Toomas Soome <tsoome⊙mc>

with 0 columns, does that lead to infinite output? :)

not infinite in terms of real infinity, but still close enough

data type is int there.

[illumos-gate] 18325 vioif: add support for VIRTIO_NET_CTRL_MAC -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 18343 smbios_info_boot needs to check table size -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 18344 smbios_info_contains() needs work -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 18345 smbios_info_extprocessor missing apicid validation -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 18347 smbios_info_system can erroneously set uuid -- Robert Mustacchi <rm⊙fo>