02:15:03 <Guest7> Are the illumos.org servers down?
03:14:25 <jbk> seem to be working for me (at least the main site)
04:40:49 <danmcd> Has anyone tried very very recent illumos-gate on a machine with i40e(4D) or igc(4D) ?
08:23:57 <tsoome_> do not have such hw:(
08:24:40 <tsoome_> ixgbe was ok, however
11:05:13 <sjorge> 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.
11:05:25 <sjorge> It seems to just segfault once (windows in this case) tries to bring up the nic
11:05:35 <sjorge> I replied on the ml too
14:09:35 <pmooney> sjorge: can you gist me the backtrace from that core?
16:31:25 <sjorge> pmooney http://blackdot.be/static/core.bhyve.21770.gz
16:31:57 <sjorge> https://gist.github.com/sjorge/630ef7642c41f6c711bf443b43a84866
16:32:11 <sjorge> I actually know how to grab the stack, just forgot
17:53:46 <pmooney> that's a NULL pointer alright
17:54:28 <pmooney> sorry, I've been wrapped up in other things today
17:54:31 <pmooney> will try to look at this later
20:02:44 <wacki> @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.
20:06:28 <richlowe> wow, well
20:06:32 <richlowe> that took a turn
20:08:42 <wacki> I cannot boot or access it anymore. Maybe related to the new BIOS 2.95. I'll have to test it in another system.
20:09:28 <jbk> even if you boot off alternate media it doesn't see it?
20:11:26 <wacki> I can't remember exactly. I have already removed it. IIRC it was detected but not usable.
20:11:44 <richlowe> I think that was about the nvme, not the nic
20:30:47 <wacki> The nic is onboard.
20:35:14 <danmcd> X722 is definitely onboard some mobos.  I don't know what gen the HP Z6G4 is... hang on.
20:35:19 <richlowe> I think Woodstock and rmustacc are the nvme experts
20:35:26 <richlowe> honestly, far more concerned about that than the nic
20:35:44 <danmcd> NVME yes.  It Does Not Help that "NVM" is also used by Intel i40e to describe its firmware.  :(
20:37:43 <danmcd> I'm not kidding... 
20:37:44 <danmcd> https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/io/i40e/i40e_main.c#L1308-L1323
20:38:11 <danmcd> There's no way an i40e NVM image could get pushed into NMVe firmware right?  I mean formats and checksums, no?
20:38:21 <wacki> Yes, the non-working NVMe disk was unexpected.
20:38:55 <wacki> The updates have been done under Windows 11 with packages provided by HP.
20:38:59 <danmcd> Also, the warning should NOT have halted i40e attach operations.
20:40:05 <wacki> 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.
20:40:10 <danmcd> X722 has a known issue with duplicate inbound packets ( fenix illumos#13230 ) but it should detect/attach/move-bits.
20:40:11 <fenix> BUG 13230: i40e has duplicate traffic when used with bhyve/snoop running (New)
20:40:11 <fenix> ↳ https://www.illumos.org/issues/13230
20:40:19 <jbk> hm.. how is this even working...
20:40:20 <jbk> https://github.com/illumos/illumos-gate/blob/master/usr/src/tools/svc/svccfg/Makefile#L36
20:40:25 <jbk> LIBSCF isn't set anywhere I can find
20:40:59 <richlowe> it's not
20:41:25 <jbk> is there an existing bug for that?
20:41:26 <richlowe> not sure how I missed that among everything 
20:41:30 <richlowe> I don't think so?
20:41:33 <jbk> oh ok
20:41:36 <richlowe> but I bet you see -I/inc in your build.log
20:41:37 <wacki> IIRC dladm reported link is up.
20:41:40 <jbk> i do
20:41:55 <richlowe> jbk: yeah, file/fix a bug? :)
20:42:12 <richlowe> (you'd want to either remove or aim it correctly) :)
20:45:00 <jbk> https://www.illumos.org/issues/17211
20:45:01 <fenix> → BUG 17211: Tools svccfg build missing LIBSCF (New)
20:46:05 <tsoome> but ... why it is building?
20:47:03 <tsoome> is it picking up headers from buildhost?
20:47:26 <richlowe> unclear, that's why I said it either needs aiming properly or the argument removed
20:47:55 <jbk> i think it might be picking up the buildhost headers...
20:49:08 <richlowe> then yeah, it needs aiming properly, but I have and had tools that check for that
20:49:18 <richlowe> so I'm confused how I fucked up, sorry.
20:49:39 <jbk> *shrug* i'm just happy I'm not confused :)
20:49:46 <jbk> or at least I hope I'm not
20:49:51 <richlowe> trying to remember what I called the tool
20:50:18 <richlowe> Oh, the tool checks the other way.
20:50:19 <richlowe> fuck
20:50:58 <jbk> 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
20:51:37 <jbk> (broke some of our stuff -- i.e. usual merge issues)
20:51:37 <richlowe> I'm pretty sure I ran them buy andyjs
20:51:41 <richlowe> s/buy/by/
20:51:51 <richlowe> but yeah, there's much more work needed there to finish up
20:52:03 <jbk> yeah, but I don't think he actually applied them
20:52:06 <richlowe> but I haven't yet worked out how to do it
20:52:14 <jbk> we had been kinda busy with some other stuff and got a bit behind
20:53:47 <jbk> 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
20:54:03 <jbk> (we build on omnios, so we kinda do a semi-cross compile)
20:54:27 <richlowe> right, I would love to land the changes from the arm gate that make that an _actual_ cross compile
20:54:42 <richlowe> because it would make your life so much better (or at least more correct)
20:54:45 <richlowe> but so much to do
20:55:36 <richlowe> 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).
20:55:47 <richlowe> because that's literally what we're trying to do there, even on x86
20:56:07 <richlowe> it happening to be non-fatal when it goes wrong currently causes more problems than it solves :\
20:57:44 <richlowe> 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?
22:12:51 <gitomat> [illumos-gate] 17160 afe: variable dereferenced before check -- Toomas Soome <tsoome⊙mc>
22:12:56 <jbk> it looks like it might not?
22:14:28 <gitomat> [illumos-gate] 17168 ibtl: unsigned 'ibtf_errlevel' is never less than zero. -- Toomas Soome <tsoome⊙mc>
22:15:25 <rmustacc> It looks like wacki is gone. Is there any more information on the NVMe issue?