I'm trying to build a debug version of SmartOS release-20210812 using the instructions here: github.com/TritonDataCenter/smartos…e/release-20210812#building-smartos When running ./configure -d, it's complaining because gcc49 is not available in the pkgsrc.joyent.com/packages/SmartOS/2021Q4 repo

Anyone know if gcc49 is required or if it would be safe to remove the gcc49 install from the configure script?

I've removed gcc49 and am attempting a "gmake live" now

@rmustacc @danmcd gist.github.com/Smithx10/b279c7626422045b59e6fe9e1ff4d25f debug build from TritonDataCenter/illumos-joyent #444/commits I believe....

Smithx10: Is the mlxcx link up?

rmustacc: bumpped gist.github.com/Smithx10/b279c7626422045b59e6fe9e1ff4d25f

Do you know what's physicaly connected there?

yes

1 sec

There's something we can print with mdb -k.

But if it requires the extended bits, we'll have to add more logic.

store.nvidia.com/en-us/networking/s…able-ethernet-200gbe-to-2x100gbe-3m store.nvidia.com/en-us/networking/s…um-2-200gbe-1u-open-ethernet-switch

OK. I think grabbing something out of mdb will help.

I'll have to remind myself of the driver structure here. Can I get back to you in 5-10m?

sure, take your time

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

You need the leading *

Hmm. Ah. can you change the '->' to a '.'?

Sorry, mostly guessing at this without it in front of me makes it awkward.

Hmm, ok. I'll need to look at what Dan did. Thanks.

np

Can you also add mlp_oper_proto?

OK, thanks.

I'll follow up with Dan on some bits here at some point.

But based on what you have the dladm output makes sense.

But we can do better.

We'll need to add some logic to query the cable type on newer systems.

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.

I'm wondering if anyone has some SFP based i40e available at all.

me

lol

Dan built a platform that does the same media stuff for i40e. Maybe mind running that as well? >_>

I'm not sure I have a platform for that

[illumos-gate] 15489 cfgadm_plugins: the comparison will always evaluate as 'true' -- Toomas Soome <tsoome⊙mc>

Smithx10: There was one on the mailing list actually.

I can get a link, one sec.

Smithx10: kebe.com/~danmcd/webrevs/ipd39 has some bits that are mostly there.

rmustacc: 20230305T162732Z is booting up

Thank you!

[illumos-gate] 15526 Update tzdata to 2023c -- Andy Fiddaman <illumos⊙fn>

@rmustacc booted, what should I run?

dladm show-linkprop -p media,state

Thanks! I assume you are using a 25GBASE-CR transceiver.

XXV710?

value='Ethernet Controller XXV710 for 25GbE SFP28'

hmm... it seems like ping ignores the data_size parameter if specified

It seems to be honoring it in a brief test I'm doing?

I see it confirmed in snoop, latency increase, and even generating fragments if I ask nicely.

hrm.. with more recent bits, now this system is flooding /var/adm/messages about xhci stop endpoint command in the wrong state

Are you seeing issues?

Or just log messages.

just lots of NOTICE

Sometimes the message is correct and follows from the circumstance, but not actually an actionable problem.

even if it's correct, emitting it 300,000+ times feels excessive

I'm a little surprised it's happening that frequently.

But yes, someone else mentioned to me they were looking at cleaning up the expected case.

*cases

If you're not using libusb, I'd only expect that to really happen on pipe open/close so driver attach/detach.

ahh.. it looks like it's some cheap KVM (at least if the slot# from the message agrees with ::xhci_device)

@rmustacc the one I build for Smithx10 ONLY had mlxcx in it.

Yeah I bounced and tested the i40e separate now that I have all the disk spaces on the boot pool

Been out most of the day today.

@rmustacc do NOT hold up your mlxcx work for media. It works fine for non-CX-6 parts.

Smithx10 has a media part we don't yet have a corresponding value for in your nemo/mac updates:

+ case MLXCX_EXTPROTO_100GAUI_2_100GBASE_CR2_KR2:

+ case MLXCX_EXTPROTO_100GAUI_1_100GBASE_CR_KR:

+ /* No type for 100G AUI as far as I can see. */

return (ETHER_MEDIA_UNKNOWN);

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.

THIS IS NOT A STOPPER FOR mlxcx support for IPD 39 going back immediately.

Repeat, THIS IS NOT A STOPPER!

I have a bunch of other testing, so don't worry. I wasn't taking it that way.

The problem is that for the extended types we need to get additional information to decode it.

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.

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.

You need to ask the cable type and use that to choose either CR or KR.

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?

err chunk of kernel memory

Not necessairily.

Imagine a case where someone wants say 3000 byte DMA items and those are all filling up (like a NIC descriptor).

The kernel is free to give you several 1k regions for your 10k chunk.

If you need a guarantee you need to express it in the DMA attributes.

Otherwise you should assume that, while unlikely, it can take a lot of cookies.

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.

even when mapping (not allocating new memory)? assuming the device can handle 64-bit addresses

If you want to assume something it must be expressed in your constraints.

It is extremely unlikely, but assume, no.

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'

I guess I'd just measure and see what happens in practice. A lot changes due to fragmentation, etc.

You can just constrain yourself to your fast path until that proves not to be reasonable.

unrelated: is dlstat deliberately undocumented (despite being in /usr/sbin -- i thought we usually tucked away non-documented stuff elsewhere)

?

No. Just didn't get it in the original manual page drop.

Someone needs to write something from scratch, not using the arc materials.

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

[illumos-gate] 15442 Want datalink media observability -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 15447 cxgbe MAC_PROP_MEDIA support -- Robert Mustacchi <rm⊙fo>