In D19992#429687, @bcran wrote:

In D19992#429679, @imp wrote:

I've also started to create a 'fallback loader' path to try to hash out a good design. I'm thinking that a good design might be to have loader.efi read in \efi\freebsd\loader.env and parse it like the command line with foo=bar variables. This would let us say uefi_rootdev=HD(3,GPT,0f91d7c6-2de5-11e8-b5f1-3cfdfe9d5250,0x619430,0x600000) and have that become / for the new system. The only downside to this is that we have to encode the size and offset of the partition into the device path which doesn't play well with the auto resize code, though we could hack that to update this env :)

I don't understand how loader.env fits into the idea of a fallback loader, but it's perhaps better to wait for your design document.

I like this, but command line switches are too easy to quibble over, so I'll just have my say and let you decide.

In D19962#429625, @sjg wrote:

Would it be worth adding a means of explicitly marking a file in manifest as not to be verified?

(sorry, last comment was stale)

one minor style nit and we're good to go.

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 line length, per ed.

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]