This looks good, and we can make good use of this in our automation. It's adequate for netflix to decide what to do at boot when the aberrant conditions happen, as well as accommodating our diverse deployment model which is currently biased towards servers, but may not always be.

Other than fixing the misleading comments, I understand why we're doing this, and it looks good.

The sysctl returns non-nonsense now. Is this even needed?

I like that we can have a fallback seeding to RND devices, but Netflix requires a system to be bootable to userland no matter what goes on with the randomness in early boot. As such, we'd like a mode that can report that something screwed up in the early random stuff so we can decide if we care or not about that. And then take appropriate action based on our level of caring and concern. We have boxes all over the world and a hung boot would mean an RMA which is quite costly. We'd rather the system come up at least enough to report broken randomness to our backplane, or to take remediation steps when, for example, our entropy file is corrupted on a crash by recreating it and rebooting.

this is a reasonable stopgap, approved with the understanding that there will be follow on work to allow MD sources of entropy, like RDSEED on x86 etc

Looks good to me.

There's only one issue that I see with this commit, and that's OUI namespace management. It's likely not a huge deal, but I think it's an easy thing to get right. emaste@ or kevans@ have the context / information to get the allocation from the foundation that I think we need. It's a minor tweak to the code to o things that way.

Looks like Andy's suggestions were followed... I was going to make similar when I last looked at it as well.

This change looks correct to me. Unsure why we need to do it though. Would like to see the follow-on fixes that this depends on, since I'm pretty happy with this if there's some reason to change.

This looks OK to me, but my knowledge of what bhyve does to emulate PCI is weak.

So this looks good to me. Having at least mips64 covered, even if other things are unknown is a win. one question about r_mips_32 to think about.

Couple of minor style nits, but the code looks good to my brain.

This looks good to me, however I'd wait a few days to see if Scott can spot something that I can't.

OK. this looks good, and you are using the flag I was complaining about not being used , so ignore that bit.
This is conditional on D19779.
and I'm ENOCLUE on the hardware, but it looks like it might be right.

Finish the transition

In D19695#425335, @chuck wrote:

In D19695#423813, @imp wrote:

This looks good to me. It's the right thing to do.
Do we need to expand it more generally (in a different commit) for any time we have to copy data out, or is the I/O path good?

The IO path appears to be OK, but I only took brief look. That said, I've run a fair amount of IO against and haven't seen any issues in practice. Where as this issue was easily reproducible.

Fix, per ed. move b= to place closer to where it's used.

I debated tossing this into sys/conf/NOTES, but didn't want to play whack-a-mole with the architectures that I'd opt out of... Comments?

mps debug flags in NOTES, as appropriate.

I'm trying to recall that. I know that the different types of subdevices don't change what's probed (as there are catch-all entries). I had a specific reason, but I can't recall it now.

I specifically allowed those duplicates when I was originally reviewing this change....

In D19816#425165, @cem wrote:

Why not just cut straight to a tunable instead and save a compile?

If this looks good, I'll do the identical changes to mpr as well.

Looks great, apart from the stupid date nits :). And even if those weren't fixed, it wouldn't be too bad.

In D19779#424228, @kibab wrote:

In D19779#424220, @bz wrote:

This is missing files I think. The mmcreg.h structure changes are missing from this one. This won't compile.

Sorry, something has gone wrong with my tree. I will reupload.

So slm is Steve McConnell who has been the long-time driver maintainer inside of LSI/et-al. His day job has transitioned to firmware, but is active on phab.
Achim is from Adaptec / Microsemi and left Adaptec in 2016.
Scott is going to contact both of them as a courtesy to these vendors.

Apart from slm and achim, I'm good. Let's put those two in the not yet box.

Update after latest cleanups.

I'd be happier if we copied usbdevs.awk to sdiodevs.awk.
I'll take a closer look next week when I'm back in the office.

In D19507#423939, @greg_unrelenting.technology wrote:

In D19507#423825, @imp wrote:

IIRC, this violates the ACPI definition for these fields.

Where are they defined? https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table — Ctrl+F "width" — 0 results. (Thanks Microsoft.)

In D19507#423770, @greg_unrelenting.technology wrote:

Dammit. The Ampere eMAG (which uses the pl011 SBSR UART) represents *shiftp = 2; as

[029h 0041   1]                    Bit Width : 20
[02Ah 0042   1]                   Bit Offset : 00
[02Bh 0043   1]         Encoded Access Width : 01 [Byte Access:8]

This looks good to me. It's the right thing to do.
Do we need to expand it more generally (in a different commit) for any time we have to copy data out, or is the I/O path good?

one quick Q. if you know the windows versions, document it in the comment. the code is good to go. If you know, update the comment. If you don't know, that's cool too. either way, I no need to do a round trip through the review. you can just tweak that and commit.

jhb specifically asked me not to do this driver. Please be sure to get sign off from him.

I'd be happier if we copied usbdevs.awk to sdiodevs.awk.
I'll take a closer look next week when I'm back in the office.

I'd be happier if we copied usbdevs.awk to sdiodevs.awk.

These are good changes, though the conf/files and kern.post.mk fragments seem a separate thing...

generally, I'm happy. Once minor nit that you can do or not as you see fit.

I think this looks good, but I've not studied it in enough detail to know for sure.
It might make sense to see if Scott or Ken has a chance to look into this to be sure it's the right solution.

My mistake... 386bsd booted from a file named /386bsd. FreeBSD changed that early on to be /kernel.

Current default was set before 1996, when "/kernel" was the
actual path I guess.

Defaults should match defaults. If we don't know, guess the default FFS.

derp... I missed you did both...

Does MPR need a similar fix?

You might want to take a look at tools/boot/rootgen.sh. It's as shell script I use to generate about 24 or 32 different images to test all the different ways you can boot. It also generates a bunch of different scripts to do the qemu testing that likely could be leveraged to provide more complete qemu coverage testing.