Sample output from the tail of a NO_KERNELCLEAN=yes build with nothing to do:

Thanks!

Ok. I will trust your judgement on what is the best approach.

I think moving and moving back probably doesn't break anything, so if this is the simplest approach I'm ok. For NUMA allocation I was kind of hoping we could have a way other than PCPU_GET(cpuid) to specify a preferred domain when we really want NUMA allocation, but maybe binding and pcpu is simpler than the other possibilities (e.g. could you set a temporary numa policy on curthread in place of sched_bind? Not sure if we have the bits for that though.)

I agree that we can't handle this in ether_ioctl as it varies too much by real hardware.

Hmm, do you require this going forward? I think it's probably fine, but changing the binding is going to possibly break some assumption in the calling code and the purpose of the panic was to force the calling code to be aware of that and handle it (e.g. by unbinding before calling bus_bind_intr() or the like so that then the calling code is aware of the change and can handle the migration if needed.)

• Style fixes.

The random non-changes to files in bhyve, etc. is odd. I think this comes from using svn merge which I think is usually a bad idea for non-MFC's as it often screws up.

• Rebase.
• Style fixes from kib.
• Move td_errno into zeroed section of struct thread.

• Document PT_GET_SC_RET.

Nice. I was just planning on looking why these tests fail on i386. Thanks!

Ed, I believe you had mentioned doing this for head once the 12.0 cycle was done? Right now you can't find the svn revision for a build of a clean tree (which is often a useful bit of info when reporting bugs on current@, etc.). I also commonly export trees into VMs using NFS and build inside the VM and newvers.sh fails to recognize dirty trees since the VCS may not be installed in the VM or the VM may be mounting a subdirectory of an svn checkout and thus not see the .svn, etc.

One thing to consider is moving the new comment up above 'pci_mask_msix' function and just listing it once.

Rather than conflating the renaming of pmap_mapbios with this change, I've just altered the semantics of the existing function for now. I do think a separate followup to rename pmap_mapbios to pmap_mapphys might be nice, but I don't think we need yet another variant of pmap_mapdev.

(My 3.0 is older than Warners which is somewhat unfortunate, but I think the requirement for RMW still stands)

The newest spec I have (3.0) say this about the upper 31 bits of VCTRL:

• Rename back to pmap_mapbios.
• Change pmap_mapbios on i386 to not change attributes.
• Don't look for an existing page for pre-init mappings.
• Don't rewrite PTEs for pmap_mapbios of "low" mappings.

Simplify by using stubs for old OpenSSL versions.

• Use ext_arg1 instead of ext_arg2.

I added Mark to be aware of another place using held pages that the pending wire count patch would touch. Drew in case you are curious as this is another use for M_NOMAP.

One more question, should we fail for trailing garbage? I think we should but we don't currently.

On further thought, I think this is ok. If the jobq isn't empty, then at least one job exists, and that job would hold a reference on the struct file and thus keep the socket "open".