That looks good. Nice little tidy-up.

Bump port revision

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.

libtirpc did something similar: https://github.com/alisw/libtirpc/commit/1e786fc401ff625fdcec3e0bdc495125feb0a070 . NetBSD and OpenBSD still contain the lseek.

I realize this is quite old, but I'd like to discuss the possibility of reverting this change, as it appears to have a significant performance impact which was never discussed at the time, while the benefit of the change appears to be purely hypothetical. I have no reason to doubt that pgrp_calc_jobc() is correct, but my own attempts to investigate possible errors in tracking pg_jobc did not uncover anything except an unrelated race condition in ppoll() and pselect() (cf. D47738 and D47741). I know of historical instances, e.g. D26116, but see no evidence of any unresolved issues at the time. Meanwhile, the cost of pgrp_calc_jobc() is quite high, especially in a debugging kernel where the process tree lock is being asserted at least four times per iteration of the inner loop, and it is being incurred even when no change occurs, e.g. on every ps or procstat -a or refresh of top.

thx!

feedback from emaste

In D48205#1101785, @markj wrote:

Isn't it used by svc_vc.c and clnt_vc.c? Any consumers of those interfaces would use this, it looks like, but there is no use of XDR_GET/SETPOS there that is affected by the bug, I think.

• use ptrdiff_t
• put back break

After staring at this for a while, I think it's right.

In D48054#1101622, @krzysztof.galazka_intel.com wrote:

LGTM but let me ask @bartosz.sobczak_intel.com to take a look at irdma changes.

In D48301#1101717, @rrs wrote:

Are you sure this condition cannot be reached?

I would suspect you can have available data and the pace_tmr_rxt can be up ...

Are you sure this condition cannot be reached?

Same diff but with -U99999 to capture the full files for review.

wx needs to use same OTP version as erlang

This update of the patch addresses Adrian's concern that *_chan() are polluted by references to USB (*uc) data structures. Instead of setting uc->uc_write_delay directly the *chan() functions set a chan_flag in the sc to indicate that execution is in a sensitive part of channel processing, that a delay should be made before the write.

Document in cpu_machdep(9)

I have reservations about this, but I think it's fine.

The ASPM hack is because some x86 firmware won't enable PCI-e hot plug unless this is enabled. Longer term we should eventually just implement support for ASPM. I don't think it will be very hard to do? This is fine for now, but maybe ASPM support is something we should track as a TODO item.

LGTM.

Please note that I'm working on a unit test which exercises the original sample read / write macros, to be committed before this refactoring. This way we can verify the test procedure and test data with the original code, then adapt it to the refactored code. It's still WIP, but I can already tell that we definitely have some regressions here.

In D48222#1101530, @jfree wrote:

I do not like how complicated this is getting, but the code all looks good.

This allows me to boot FreeBSD on VMWare Fusion on arm64 again.

I don't remember whether ASPM has anything to do with enabling ports, so wonder if it is a curios case of opposite bugs, but if it helps, I see no problem.

LGTM but let me ask @bartosz.sobczak_intel.com to take a look at irdma changes.

Yes, that's probably the best place for it

unexpected stuff added

push the right patch