Generally ok with this. I would like to know if the malloc thing can be addressed during init or if that is required by your upcoming changes.

I'm planning to commit this soon unless a serious objection is raised.

Is there a way to vendor the alt toolchains? It is imperative this doesn't start downloading from the internet outside of the fetch step, the same standards things like Cargo, Maven, etc have in ports. As long as that is addressed I think the overall concept is fine now -- it will be awkward if we have to patch Go but hopefully that is not common.

@markj go ahead and commit the initialization and style changes. I need a moment to think about the threading, so I would ask that goes in a separate commit, which you are free to do as well. Is there any reason not to use _int variant over long? This should MFC back to 32 bit platforms which seem to generate different code vs x86 for whatever it's worth. The driver is also "upstream" for RTEMS and other smaller systems.

In D50388#1149945, @jrtc27 wrote:

Or, like WITNESS or MALLOC_PRODUCTION, on in HEAD and off in stable branches?

In D50128#1149830, @kgalazka wrote:

In D50128#1147046, @kbowling wrote:

I would be somewhat curious why we need to serialize like this. Note that nothing else prodding the swfw in ixgbe is explicitly locked or asserted.

I was thinking about ixgbe_if_init and ixgbe_config_link. IIRC under the hood it does couple of MDIO reads and writes. The SWFW semaphore is hold for individual accesses, but not during whole operation. Without CTX lock writes from mdio bus may interfere with that and bringing link up may fail.

Please reupload with context (git diff -U9999). It also seems to not be based on FreeBSD main.

To add to what @erj said, multi-arch build is a requirement the same as on other OS projects. We have to provide some advance notice to drop things and this should be MFC'd back to 13 and 14. See build(7), 'make universe' or 'make kernels' is enough. I don't see anything off hand that is problematic, and there is no expectation on Intel for validation for odd platforms. But it has to build everywhere it currently does.

I do see the improvement here for the drm maintainers not having to deal with all this, but I'd like someone with more ports infra experience to evaluate the implementation.

The first change seems sensible.

I'm generally fine with what is here, it seems logical to me.

I would be somewhat curious why we need to serialize like this. Note that nothing else prodding the swfw in ixgbe is explicitly locked or asserted.

Fix DBUS, reported as https://github.com/bitcoin/bitcoin/issues/32464

Looks good

See the actual commit message from that https://reviews.freebsd.org/R9:a52de44df1a6534adec66174ee68d03444738907

It will be helpful, especially early on, to add a fully formatted commit message to the review description so we can have a look and make sure you have the git config right.

In general this looks fine aside from the cleanups you noted..

In D50053#1141698, @junchoon_dec.sakura.ne.jp wrote:

In D50053#1141632, @kbowling wrote:

In D50053#1141606, @ashafer wrote:

I think a better idea would be to adjust the patch I made for disabling GSP. That patch was pretty heavy handed and turned off a global which enabled GSP. I think instead we could make the patch default only the sysctl value to zero, disabling GSP by default but allowing users to enable it by setting the tunable in loader.conf. That would prevent us from having to have a build option and prevent users from having to compile things themselves.

I agree with this recommendation. This should be a tunable kind of thing since we need package users to be able to try both settings.

So OPTIONify is not needed, unless any case which need global disabling of GSP.
If such a case exists, keeping OPTIONifying but enable by default, with flipping the default for the tunable.
3 entries of OPTIONS_SINGLE would be wanted in that case.

Enable GSP firmware support
Disable GSP firmware support via tunable (default)

and

Globally disable GSP firmware support

to avoid confusions.

If not, simply changing patch to flip the tunable and edit pkg-message (actually, files/pkg-message.in) to tell anyone having problem with the ports default to flip it via tunable is sufficient.
In this case, if we can't edit summary of this revier, I need to abandon this and open a new review. Not sure at this moment.

In D50053#1141606, @ashafer wrote:

I think a better idea would be to adjust the patch I made for disabling GSP. That patch was pretty heavy handed and turned off a global which enabled GSP. I think instead we could make the patch default only the sysctl value to zero, disabling GSP by default but allowing users to enable it by setting the tunable in loader.conf. That would prevent us from having to have a build option and prevent users from having to compile things themselves.

In rGbceec3d80a3caf9249e24247fb937674bf5b46b5#728222, @kbowling wrote:

In rGbceec3d80a3caf9249e24247fb937674bf5b46b5#728134, @jeroen.steinvoorte_mep-info.com wrote:

Any update on this matter? What can I do to help?

If you have time, take a look at the commit in question and see if you can find out what might be going wrong logically to the best of your ability.

Also can you share you exact hw string like dev.igb.0.%desc or whatever device it is. I have a fear/suspicion there is some NIC hardware dependency in the NICs link state machine so it might not be purely a driver issue. Which means it becomes a choice of who to make happy. But I haven't had time to sit down and test this on some of my many my hardware combinations yet.. so there is also a chance I just didn't test correctly with the link resets you mentioned. It may be a few weeks with my current workload.

In rGbceec3d80a3caf9249e24247fb937674bf5b46b5#728134, @jeroen.steinvoorte_mep-info.com wrote:

Any update on this matter? What can I do to help?

A couple minor nits but overall looks good

In D49906#1137930, @adamw wrote:

In D49906#1137925, @kbowling wrote:

Is this really feasible? At first contact I would think this will create a lot of different problems than whatever supporting multiple versions currently does. Some projects have elaborate dependencies (i.e. multimedia/navidrome which I maintain) and we could get into common situations where it is either difficult to update go with a clean exp-run or we have to make a choice to regularly lose ports because tracking a modern version is more important.

The point is that Go now builds the same regardless of which version you use. If the go.mod says to use a newer version, it builds the stdlib from that version and links it in. And if go.mod says to use an older version, go restricts its feature set to behave exactly as that old version would.

So, whether we have one Go version in the tree or ten, the output will be exactly the same. There's literally no difference between Go versions anymore, so we gain nothing by having multiple in the tree.

Is this really feasible? At first contact I would think this will create a lot of different problems than whatever supporting multiple versions currently does. Some projects have elaborate dependencies (i.e. multimedia/navidrome which I maintain) and we could get into common situations where it is either difficult to update go with a clean exp-run or we have to make a choice to regularly lose ports because tracking a modern version is more important.

Committed as e86781da6b600e8096a42a6f44b2b7f97ff08251

I am fine with the patch file, it will be easy enough to cull eventually.

@jeroen.steinvoorte_mep-info.com can you please get me the Cisco config for a port? I did test on a 2960X. Depending on what I see with that I will either fix or revert.

Committed as 9ff52cbdf482bf9da124fa9f3603c99ed45a646c

MFH is done at the discretion of the committer, a request by the maintainer, or potentially someone else. I would lean toward no in this case without a supporting reason.

@ashafer you can go ahead and commit this with "Approved by: kbowling(mentor), maintainer timeout (danfe, x11)".

@andrew got it, thanks for clarifying

Would it make more sense to invert the conditional to aarch64? I would assume that future implementations would support ASPM as do past ones i.e. for sure PHB4 on POWER9.

I've been pondering this and it seems pretty broken in the tree and what I have suggest doesn't make sense.

Add clarification suggested by @markj

@tuexen just a note that the X552 is also using the same middle value as 82599

In D47336#1079637, @fbsd_opal.com wrote:

Glad to see this is back under consideration. It will be useful for cases where it is needed.
When D34449 was reverted, we puled a new CAT6 cable where we had had this problem and therefore eliminated our need for this patch.
I am actually at the location in question at the moment, for a few days. I will try to set up a test of this revised patch this weekend.

@franco_opnsense.org can you please see if you can find some users to test this that had the colo setups.