In D46502#1066069, @jrtc27 wrote:

I've submitted a patch for exp-run in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281674.

Well that doesn't even do MACHINE, which is important, otherwise you'll end up with MACHINE not matching MACHINE_ARCH, which breaks things. You can't in general just set one; that's a custom feature of the src tree's Makefile.

In D46502#1060031, @jrtc27 wrote:

In D46502#1059884, @tijl wrote:

bmake calls uname(3) to define MACHINE and that returns the value of environment variable UNAME_m which is defined by poudriere so MACHINE should be correct. MACHINE_ARCH cannot be obtained through uname(3) so bmake has to call sysctl which will indeed return the native architecture. I think it's best to add MACHINE_ARCH=${ARCH} to WRK_ENV in Mk/bsd.port.mk so it applies to all ports not just kmod ports.

The more I think about it the more I'm convinced the original commit was just wrong.

If a user puts things in make.conf, there is the expectation it applies to all builds made with that environment, ports included. If they configure their system in a way that breaks building a port, that's their fault. If they want a sanitised environment, that's what poudriere is for, and sidesteps any such issues. That is, it is a feature not a bug that make.conf applies to ports builds, and it is a feature which poudriere has relied upon for many years to correctly configure ports in the jail, which that commit broke (and doing an exp run of native amd64 isn't going to turn up the interesting failures like cross-building kmods). Quite frankly, I believe any port that disables make.conf is wrong, let alone doing it globally.

bmake calls uname(3) to define MACHINE and that returns the value of environment variable UNAME_m which is defined by poudriere so MACHINE should be correct. MACHINE_ARCH cannot be obtained through uname(3) so bmake has to call sysctl which will indeed return the native architecture. I think it's best to add MACHINE_ARCH=${ARCH} to WRK_ENV in Mk/bsd.port.mk so it applies to all ports not just kmod ports.

I spent yesterday and today on this but it's taking too much time to familiarise myself with the code so I won't be able to fix this in a timely manner. It's also too risky to make changes to drm-*-kmod this close to 14.1. So I've created D45125 which should be safe to MFC.

Maybe it would be better to turn arch_io_reserve_memtype_wc into a no-op returning 0 and leave the drm-*-kmod ports unchanged. That would be safer this close to 14.1 release. Before 1e99b2ee9095 the function interpreted a physical address as a virtual address so it must have always failed and after that commit the BSDFIXME comment in the link I posted before suggests it still doesn't work. So whatever this function is supposed to do has not been necessary on FreeBSD. The only benefit of implementing it as a wrapper around vm_phys_fictitious_reg_range is that it makes the FreeBSD specific code in drm-*-kmod smaller, but that's not important. Agreed?

The patch for graphics/drm-*-kmod ports is in D45059.
Example use of arch_io_reserve_memtype_wc:
https://github.com/freebsd/drm-kmod/blob/1f0859f54b6f4bcce3862f30c9c1b5cfd08710db/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c#L1048
Note that arch_io_reserve_memtype_wc is only called conditionally here so removing vm_phys_fictitious_reg_range calls like the drm-*-kmod patch does may not be correct. The i915 driver doesn't call arch_io_reserve_memtype_wc at all. It calls io_mapping_init_wc instead, which calls ioremap_wc, which calls pmap_mapdev_attr, so I think it doesn't need to call vm_phys_fictitious_reg_range but I cannot test that.

Example use:
https://github.com/freebsd/drm-kmod/blob/1f0859f54b6f4bcce3862f30c9c1b5cfd08710db/drivers/gpu/drm/radeon/radeon_gart.c#L83
set_memory_uc called on ptr returned by linuxkpi dma_alloc_coherent, which returns a virtual address.