Are the illumos.org servers down?

seem to be working for me (at least the main site)

Has anyone tried very very recent illumos-gate on a machine with i40e(4D) or igc(4D) ?

do not have such hw:(

ixgbe was ok, however

danmcd_ pmooney I can't seem to get a vm to boot either on bloody now when switching to e1000, I know that worked fine a few weeks ago as I was using that as one of the workarounds for virtio being broken with MTU > 1500 until I figured out the MTU was the issue.

It seems to just segfault once (windows in this case) tries to bring up the nic

I replied on the ml too

sjorge: can you gist me the backtrace from that core?

pmooney blackdot.be/static/core.bhyve.21770.gz

I actually know how to grab the stack, just forgot

that's a NULL pointer alright

sorry, I've been wrapped up in other things today

will try to look at this later

@danmcd: I have an HP Z6G4 with an i40e (Intel X722). It was detected but not working. It was also complaining about an outdated NVM image. So I updated the BIOS and the X722 firmware but that seem to have killed my NVMe disk.

wow, well

that took a turn

I cannot boot or access it anymore. Maybe related to the new BIOS 2.95. I'll have to test it in another system.

even if you boot off alternate media it doesn't see it?

I can't remember exactly. I have already removed it. IIRC it was detected but not usable.

I think that was about the nvme, not the nic

The nic is onboard.

X722 is definitely onboard some mobos. I don't know what gen the HP Z6G4 is... hang on.

I think Woodstock and rmustacc are the nvme experts

honestly, far more concerned about that than the nic

NVME yes. It Does Not Help that "NVM" is also used by Intel i40e to describe its firmware. :(

I'm not kidding...

There's no way an i40e NVM image could get pushed into NMVe firmware right? I mean formats and checksums, no?

Yes, the non-working NVMe disk was unexpected.

The updates have been done under Windows 11 with packages provided by HP.

Also, the warning should NOT have halted i40e attach operations.

After that I wanted to run OI again but that wasn't possible. I have Windows 11 on a separate NVMe. The Z6 has two sockets for NVMe.

X722 has a known issue with duplicate inbound packets ( fenix illumos#13230 ) but it should detect/attach/move-bits.

BUG 13230: i40e has duplicate traffic when used with bhyve/snoop running (New)

↳ illumos.org/issues/13230

hm.. how is this even working...

LIBSCF isn't set anywhere I can find

it's not

is there an existing bug for that?

not sure how I missed that among everything

I don't think so?

oh ok

but I bet you see -I/inc in your build.log

IIRC dladm reported link is up.

i do

jbk: yeah, file/fix a bug? :)

(you'd want to either remove or aim it correctly) :)

→ BUG 17211: Tools svccfg build missing LIBSCF (New)

but ... why it is building?

is it picking up headers from buildhost?

unclear, that's why I said it either needs aiming properly or the argument removed

i think it might be picking up the buildhost headers...

then yeah, it needs aiming properly, but I have and had tools that check for that

so I'm confused how I fucked up, sorry.

*shrug* i'm just happy I'm not confused :)

or at least I hope I'm not

trying to remember what I called the tool

Oh, the tool checks the other way.

fuck

we were a bit behind in merging upstream, and the changes for native build broke stuff, so i've just been helping get things fixed up and ran across that

(broke some of our stuff -- i.e. usual merge issues)

I'm pretty sure I ran them buy andyjs

s/buy/by/

but yeah, there's much more work needed there to finish up

yeah, but I don't think he actually applied them

but I haven't yet worked out how to do it

we had been kinda busy with some other stuff and got a bit behind

we have a small change in libscf (to denote a service is global zone only) and so it choked because it couldn't find the #define

(we build on omnios, so we kinda do a semi-cross compile)

right, I would love to land the changes from the arm gate that make that an _actual_ cross compile

because it would make your life so much better (or at least more correct)

but so much to do

basically, the ADJUNCT_PROTO should be a real sysroot, passed as --sysroot, and respected as such. (and smartos should work out what to do about their problems there).

because that's literally what we're trying to do there, even on x86

it happening to be non-fatal when it goes wrong currently causes more problems than it solves :\

I have a question though: DDI_DEVICE_ATTR_V1 is the FMA bits if I recall. Does using _V1 but not having FMA opt me into a fault-management state that is different from using _V0 and FMA not existing?

[illumos-gate] 17160 afe: variable dereferenced before check -- Toomas Soome <tsoome⊙mc>

it looks like it might not?

[illumos-gate] 17168 ibtl: unsigned 'ibtf_errlevel' is never less than zero. -- Toomas Soome <tsoome⊙mc>

It looks like wacki is gone. Is there any more information on the NVMe issue?