02:09:34 <Guest1554> I'm trying to build a debug version of SmartOS release-20210812 using the instructions here: https://github.com/TritonDataCenter/smartos-live/tree/release-20210812#building-smartos When running ./configure -d, it's complaining because gcc49 is not available in the https://pkgsrc.joyent.com/packages/SmartOS/2021Q4 repo
02:12:18 <Guest1554> Anyone know if gcc49 is required or if it would be safe to remove the gcc49 install from the configure script?
02:14:44 <Guest1554> I've removed gcc49 and am attempting a "gmake live" now
14:38:50 <Smithx10> @rmustacc  @danmcd  https://gist.github.com/Smithx10/b279c7626422045b59e6fe9e1ff4d25f  debug build from https://github.com/TritonDataCenter/illumos-joyent/pull/444/commits  I believe.... 
14:57:31 <rmustacc> Smithx10: Is the mlxcx link up?
14:58:12 <Smithx10> rmustacc:  bumpped https://gist.github.com/Smithx10/b279c7626422045b59e6fe9e1ff4d25f
14:58:45 <rmustacc> Do you know what's physicaly connected there?
14:58:51 <Smithx10> yes
14:58:56 <Smithx10> 1 sec
14:59:23 <rmustacc> There's something we can print with mdb -k.
15:01:03 <rmustacc> But if it requires the extended bits, we'll have to add more logic.
15:01:11 <Smithx10> https://store.nvidia.com/en-us/networking/store/product/mcp7h50-v003r26/nvidia-dac-splitter-cable-ethernet-200gbe-to-2x100gbe-3m   https://store.nvidia.com/en-us/networking/store/product/msn3700-vs2fc/nvidia-spectrum-2-200gbe-1u-open-ethernet-switch/
15:04:33 <rmustacc> OK. I think grabbing something out of mdb will help.
15:04:48 <rmustacc> I'll have to remind myself of the driver structure here. Can I get back to you in 5-10m?
15:05:03 <Smithx10> sure, take your time
15:20:57 <rmustacc> Smithx10: In mdb -k something roughly like: *mlxcx_softstate::walk softstate | ::print mlxcx_t mlx_ports[0]->mlp_oper_status mlx_ports[0]->mlp_ext_oper_proto
15:22:46 <Smithx10> https://gist.github.com/Smithx10/4804091241222150e79a3d1bd80b42e8
15:23:01 <rmustacc> You need the leading *
15:23:20 <Smithx10> https://gist.github.com/Smithx10/4804091241222150e79a3d1bd80b42e8
15:23:47 <rmustacc> Hmm. Ah. can you change the '->' to a '.'?
15:24:00 <rmustacc> Sorry, mostly guessing at this without it in front of me makes it awkward.
15:24:30 <Smithx10> https://gist.github.com/Smithx10/4804091241222150e79a3d1bd80b42e8
15:25:03 <rmustacc> Hmm, ok. I'll need to look at what Dan did. Thanks.
15:25:13 <Smithx10> np
15:25:21 <rmustacc> Can you also add mlp_oper_proto?
15:33:32 <Smithx10> https://gist.github.com/Smithx10/4804091241222150e79a3d1bd80b42e8
15:35:57 <rmustacc> OK, thanks.
15:36:13 <rmustacc> I'll follow up with Dan on some bits here at some point.
15:36:30 <rmustacc> But based on what you have the dladm output makes sense.
15:36:34 <rmustacc> But we can do better.
15:38:07 <rmustacc> We'll need to add some logic to query the cable type on newer systems.
15:38:32 <rmustacc> I think it makes more sense for mlxcx for arekinath and danmcd to sort out their changes and get that landed. Then I'll need to redo this on top of that.
15:56:46 <rmustacc> I'm wondering if anyone has some SFP based i40e available at all.
15:57:07 <Smithx10> me
15:57:08 <Smithx10> lol
15:58:43 <rmustacc> Dan built a platform that does the same media stuff for i40e. Maybe mind running that as well? >_>
16:08:22 <Smithx10> I'm not sure I have a platform for that
16:41:31 <gitomat> [illumos-gate] 15489 cfgadm_plugins: the comparison will always evaluate as 'true' -- Toomas Soome <tsoome⊙mc>
16:44:43 <rmustacc> Smithx10: There was one on the mailing list actually.
16:44:49 <rmustacc> I can get a link, one sec.
17:04:11 <rmustacc> Smithx10: https://kebe.com/~danmcd/webrevs/ipd39/ has some bits that are mostly there.
17:08:25 <Smithx10> rmustacc:  20230305T162732Z is booting up
17:09:03 <rmustacc> Thank you!
17:10:53 <gitomat> [illumos-gate] 15526 Update tzdata to 2023c -- Andy Fiddaman <illumos⊙fn>
17:19:48 <Smithx10> @rmustacc  booted,  what should I run?
17:22:02 <rmustacc> dladm show-linkprop -p media,state
17:22:58 <Smithx10> https://gist.github.com/Smithx10/4804091241222150e79a3d1bd80b42e8
17:23:52 <rmustacc> Thanks! I assume you are using a 25GBASE-CR transceiver.
17:24:00 <rmustacc> XXV710?
17:24:25 <Smithx10>                         value='Ethernet Controller XXV710 for 25GbE SFP28'
18:24:42 <jbk> hmm... it seems like ping ignores the data_size parameter if specified
18:27:47 <rmustacc> It seems to be honoring it in a brief test I'm doing?
18:30:42 <rmustacc> I see it confirmed in snoop, latency increase, and even generating fragments if I ask nicely.
18:33:38 <jbk> hrm.. with more recent bits, now this system is flooding /var/adm/messages about xhci stop endpoint command in the wrong state
18:34:00 <rmustacc> Are you seeing issues?
18:34:05 <rmustacc> Or just log messages.
18:34:29 <jbk> just lots of NOTICE
18:34:30 <rmustacc> Sometimes the message is correct and follows from the circumstance, but not actually an actionable problem.
18:35:30 <jbk> even if it's correct, emitting it 300,000+ times feels excessive
18:35:51 <rmustacc> I'm a little surprised it's happening that frequently.
18:36:13 <rmustacc> But yes, someone else mentioned to me they were looking at cleaning up the expected case.
18:36:16 <rmustacc> *cases
18:36:37 <rmustacc> If you're not using libusb, I'd only expect that to really happen on pipe open/close so driver attach/detach.
18:39:49 <jbk> ahh.. it looks like it's some cheap KVM (at least if the slot# from the message agrees with ::xhci_device)
20:05:32 <danmcd> @rmustacc the one I build for Smithx10 ONLY had mlxcx in it.
20:06:19 <Smithx10> Yeah I bounced and tested the i40e separate now that I have all the disk spaces on the boot pool
20:08:31 <danmcd> Been out most of the day today.
20:08:49 <danmcd> @rmustacc do NOT hold up your mlxcx work for media.  It works fine for non-CX-6 parts.
20:09:06 <danmcd> Smithx10 has a media part we don't yet have a corresponding value for in your nemo/mac updates:
20:09:10 <danmcd> +       case MLXCX_EXTPROTO_100GAUI_2_100GBASE_CR2_KR2:
20:09:10 <danmcd> +       case MLXCX_EXTPROTO_100GAUI_1_100GBASE_CR_KR:
20:09:11 <danmcd> +               /* No type for 100G AUI as far as I can see. */
20:09:12 <danmcd>                 return (ETHER_MEDIA_UNKNOWN);
20:09:41 <danmcd> He's sporting the MLXCX_EXTPROTO_100GAUI_2_100GBASE_CR2_KR2 which doesn't have, AFAICT, a corresponding media type in your framework.  If I"m wrong, I'll gladly fix this.
20:09:53 <danmcd> THIS IS NOT A STOPPER FOR mlxcx support for IPD 39 going back immediately.
20:09:58 <danmcd> Repeat, THIS IS NOT A STOPPER!
20:19:27 <rmustacc> I have a bunch of other testing, so don't worry. I wasn't taking it that way.
20:19:41 <rmustacc> The problem is that for the extended types we need to get additional information to decode it.
20:20:05 <rmustacc> It's telling us the electrical interface between it and possibly a phy which is there, but that's not what we'll need to do.
20:20:29 <rmustacc> That's why I would find it easier to rebase on top of it and just implement it and add those additiona pieces that came in with the extended proto.
20:20:36 <rmustacc> You need to ask the cable type and use that to choose either CR or KR.
20:59:53 <jbk> this almost certainly would rely on implementation details, but if HW doesn't have any real DMA restrictions, DMA mapping say a 10k chunk of kernel should really only take at most 4 cookies right?
21:00:05 <jbk> err chunk of kernel memory
21:03:13 <rmustacc> Not necessairily.
21:04:11 <rmustacc> Imagine a case where someone wants say 3000 byte DMA items and those are all filling up (like a NIC descriptor).
21:04:27 <rmustacc> The kernel is free to give you several 1k regions for your 10k chunk.
21:04:54 <rmustacc> If you need a guarantee you need to express it in the DMA attributes.
21:05:05 <rmustacc> Otherwise you should assume that, while unlikely, it can take a lot of cookies.
21:06:27 <rmustacc> It is extremely unlikely you'll ever get a 16 byte DMA region as 16 1-byte cookies. But if you need a guarantee, you need to express constraints.
21:11:06 <jbk> even when mapping (not allocating new memory)? assuming the device can handle 64-bit addresses
21:12:05 <rmustacc> If you want to assume something it must be expressed in your constraints.
21:12:49 <rmustacc> It is extremely unlikely, but assume, no.
21:13:11 <jbk> i guess i should say assume in that if it exceeds that, it could be considered rare enough to be able to say 'that goes through the slow(er) path'
21:13:58 <rmustacc> I guess I'd just measure and see what happens in practice. A lot changes due to fragmentation, etc.
21:14:12 <rmustacc> You can just constrain yourself to your fast path until that proves not to be reasonable.
21:19:36 <jbk> unrelated: is dlstat deliberately undocumented (despite being in /usr/sbin -- i thought we usually tucked away non-documented stuff elsewhere)
21:19:39 <jbk> ?
21:20:19 <rmustacc> No. Just didn't get it in the original manual page drop.
21:20:29 <rmustacc> Someone needs to write something from scratch, not using the arc materials.
22:24:58 <jbk> it'd probably be nice to add a -h or -? to it as well.. trying to discover the subcommands is actually a bit of a challenge
22:45:37 <gitomat> [illumos-gate] 15442 Want datalink media observability -- Robert Mustacchi <rm⊙fo>
22:45:37 <gitomat> [illumos-gate] 15447 cxgbe MAC_PROP_MEDIA support -- Robert Mustacchi <rm⊙fo>