Fix select(2) initialization.

In D44204#1216519, @ae wrote:

It seems to have affected MLDv6: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290407

Add man page entry.

This is one of the last files that we commit when we publish the report and, as usual, we are still waiting for many late reports. So feel free to modify the file directly in this review as much as you need.

This will not fix that bug. fence is fence iorw, iorw, so all you are doing is relaxing some ordering requirements.

I'm ambivalent on this. I agree with the broad rationale here.

It seems to have affected MLDv6: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290407

update review tag

review tag

In D53220#1216044, @rosenfeld_grumpf.hope-2000.org wrote:

In D53220#1215995, @corvink wrote:

It would make it easier to review and merge when each point gets it own commit.

Actually, all of this was done together with D53223, D53222, and D53221. I've moved this part out and ahead of the other changes as I figured they'd needlessly complicate the review of the larger functional changes.

It may seem as a bunch of individual changes lumped together, but I've really just listed what this change does. Except perhaps for the style cleanups (which I'm not sure are well received in FreeBSD anyway) and the 1-line change to enable indirect descriptors, I'm not sure much is gained if I try to split it up further as all of this was really developed and tested together.

Anyway, if you insist that I split it up, I will of course try to do so.

Move ENXIO check behind mutex and add or fix comments

I really become curious in which way firmware parks APs after the initial configuration. Coreboot might have something for this.

About SMI, from Intel SDM vol 3 7.3.1 External Interrupts:

Note that several other pins on the processor can cause a processor interrupt to occur. However, these interrupts
are not handled by the interrupt and exception mechanism described in this chapter. These pins include the
RESET#, FLUSH#, STPCLK#, SMI#, R/S#, and INIT# pins. Whether they are included on a particular processor is
implementation dependent. Pin functions are described in the data books for the individual processors. The SMI#
pin is described in Chapter 33, “System Management Mode.”

I read this (and it aligns with the experience) that SMI is independent from the LAPIC configuration or enablement, as it should be.

@jrtc27 I've update the revision, PTAL

In D53232#1216063, @jrtc27 wrote:

Do we actually have a proper definition of what *our* memory barrier APIs are meant to mean? What the ISA manual says is a sensible mapping isn't necessarily what we want; note that the table you're referencing is for "Linux memory primitives", and we are not Linux, nor do we follow its memory model.

@freebsd_ny-central.org, I had to add a few more entries to the index as part of my testing of Foundation entries. Can I either add them here, or can you commit this so I can add them after your commit?

Looking at the history: armeb support ended with 11.4 and was removed after that.

Respond to latest comments.

Get rid of unneeded else statement.

Fixes: 8c9c3144ccfa ("Impleent COMPAT_FREEBSD32 for arm64. This is based on early work by andrew@.")