I have no objections, if its true.

I don't think this change fix anything. As I see, this code path is called without the lock held, so locking callback is pointless. What should be added instead is BUS_DMA_NOWAIT flag to the bus_dmamap_load() calls, since the code there really expects synchronous completion. Or it require some more complicated rework to make it asynchronous.

Generally looks good to me, except one cosmetic issue -- the line seems to go beyond 80 columns, so it would be nice to re-wrap it earlier.

Looks good to me. I applied the version for 11 you've proposed on IRC and so far the benchmark runs for about 20 minutes, while previously crashed after about 5. I'll let you know if it ever happen again.

I generally believe that we should let BIOS do its job. The chipset specification explicitly tells that OS doesn't need to know about this register. I can't recall why that code exist there and what was the problem, but since it touches only ancient ICH8M chipset, unless there is some other newer cases to have it, I'd remove it completely instead.

I have feeling it is a workaround of some other problem. Shouldn't we have fully operational scheduler at that point when EARLY_AP_STARTUP is enabled? This change may open the races this code intended to handle.

Have you tried to investigate whether keeping only VREF_ENABLE_MASK would be enough? It could have some more sense in general, since the driver has no way to know what VREF is needed in specific case. Same time other bits there are pretty logical.

I have no specific objections. Looks good to me. It just looks slightly odd, that MTU is handled different from other properties -- set before interface addition to LAGG, while multicast filters set after just before protocol initialization, and capabilities are set after the protocol initialization. As one of downsides this different order required addition of duplicate checks for LAGG nesting.

Unfortunately I haven't touched this area for several years and don't know details of modern transfer modes.

I have no particular objections, just quietly sighing that this area remains so tangled. I haven't investigated the area much recently, but it seems like WDAT-based attach could be cleaner, if it is a widespread standard and does not conflict too badly with existing drivers. Having watchdog drivers enabled in FreeNAS for years we had huge number of complains, caused by random platform specifics, and obtaining some valid configuration directly from platform in face of this table could be priceless.

Dropping locks inside the function is a mess, but I don't see specific problems.