In D29182#658119, @tobik wrote:

Thanks for the review. I'll make the suggested manual changes later.

This bothers me a whole lot. Did you really have to add a swipe on Linux or glibc? I wonder where exactly I have given the impression that my justification to want to import get_current_dir_name is "because Linux".

This appears to conform to the description of the Linux version:

Most of that info is already available through kenv(1) and/or kenv(2):

[threepio:~] rpokala% kenv | grep smbios
hint.smbios.0.mem="0xf05b0"
smbios.bios.reldate="11/22/2019"
smbios.bios.vendor="American Megatrends Inc."
smbios.bios.version="2.1"
smbios.chassis.maker="Supermicro"
smbios.chassis.serial="0123456789"
smbios.chassis.tag="To Be Filled By O.E.M."
smbios.chassis.type="Main Server Chassis"
smbios.chassis.version="0123456789"
smbios.memory.enabled="33554432"
smbios.planar.location="To be filled by O.E.M."
smbios.planar.maker="Supermicro"
smbios.planar.product="X10SDV-TLN4F"
smbios.planar.serial="ZM15AS030025"
smbios.planar.tag="To be filled by O.E.M."
smbios.planar.version="1.02"
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.family="To be filled by O.E.M."
smbios.system.maker="Supermicro"
smbios.system.product="Super Server"
smbios.system.serial="0123456789"
smbios.system.sku="To be filled by O.E.M."
smbios.system.uuid="00000000-0000-0000-0000-0cc47a7c0a92"
smbios.system.version="0123456789"
smbios.version="2.7"

This looks grossly correct to me, but it's been a long time since I've thought about this stuff. IIRC @ambrisko did some stuff with SMBIOS a ways back; Doug?

This function will be used for exposing DMI info as sysctls in the smbios module (in an upcoming review).

LGTM. Remember to bump .Dd when you commit.

LGTM, for whatever little that's worth.

Can drivers are created in a callback in xpt_done_td.

Document the new depop command.

Implement and document the new "depop" command.

In D28922#647557, @markj wrote:

@rpokala could you please see if this patch fixes the hang you see when reading vm.pmap.kernel_maps while an nvdimm is mapped?

In D28818#645488, @khng300_gmail.com wrote:

The old virtio_pci.c code handling legacy Virtio is ported over to
virtio_pci_legacy.c in FreeBSD 13 and -CURRENT

D26915 is marked as superseded by this one, but that one was for virtio_pci.c, and this one is for virtio_pci_legacy.c...?

LGTM, FWIW.

In D28738#644234, @allanjude wrote:

In D28738#643660, @rpokala wrote:

If the intention is to support smbios(4) on non-x86, shouldn't it be added to a non-x86 KERNCONF file?

That is done here: https://reviews.freebsd.org/D28744

Address review comments from @cem

Address review comments from @cem

If the intention is to support smbios(4) on non-x86, shouldn't it be added to a non-x86 KERNCONF file?

In D28700#642544, @mav wrote:

In my driver in TrueNAS I am printing this in dmesg if anything other than ACPI_NFIT_MEM_HEALTH_ENABLED is set. Everything read from NFIT applies more to boot state, rather than run-time.

Address review comments from @mav

It probably goes without saying, but please confirm that contrib/mtree/mtree.8 is what's getting installed as mtree.8, not usr.sbin/fmtree/mtree.8.

In D27194#634238, @khng300_gmail.com wrote:

In D27194#634011, @rpokala wrote:

Don't forget a manpage.

Seems like a manpage for vnode_pager_setsize(9) is also missing. Should I do it all together or separate the manpage into another differential?

Don't forget a manpage.

LGTM

Okay from me, but let @kp and @kevans weigh in as well.

Remember to bump .Dd at the top, to reflect the commit date. Other than that, looks good from a manpage standpoint.

In D27517#624368, @chuck wrote:

In D27517#623929, @rpokala wrote:

That having been said - this is because the failing_lba field isn't aligned, right? But according to NVMe-1.4, it is aligned: failing_lba is bytes [23:16] of the data structure, which is clearly both 4-byte and 8-byte aligned. So, what's the problem with just having it be a uint64_t?

In the first element of the results[] array, yes, failing_lba is nicely aligned. But the packed array element size (28 bytes) is not divisible by 8 which will force every other failing_lba field to only be 4 byte aligned.

In D27517#623771, @chuck wrote:

Any feedback on the change of failing_lba to uint8_t [8]? Does anything else stick out?

Looks good! Thanks for making the changes. :-)

I don't have the hardware to test, but the change looks fine.

1. The zero-initialization is obviously valid
2. It's clear in context that XGBE_SET_ADV() (which sets the flag) is what was really intended, instead of testing the flag with XGBE_ADV() and throwing away the result.

In D27354#612664, @cy wrote:

Correct. A constant rate limit allows the attackers to infer which source port the request is coming from reducing its randomness from 32 bits to the original 16 bits. (Same mistake WPA made with WPS.)

Forgive my (carefully cultivated) ignorance of the network stack, but I'd like to understand this:

Code change looks good to me; please update any manual pages.

In D27373#612130, @tsoome wrote:

I guess it is better just to keep them all separate.

To reduce confusion, we maybe should pick better name to replace "efi_fb". The VT internal state is filled from this structure.

Implement vt_vbefb to support VBE framebuffer with VT

LGTM, but I'm not authoritative when it comes to CAM.

In D26994#602203, @imp wrote:

All this was cut and pasted from sys/disk.h, almost vebatim

In D26254#599501, @melifaro wrote:

In D26254#599487, @hselasky wrote:

Hi,

It is not possible to re-use lagg<N> for infiniband, because we set the type of the network device when it is created. lagg<N> are created like ethernet and bond<N> are created like infiniband.

Let's try to work it backwards?
I'd start with an assumption that from user POV we should be able to use the same interface for the same type of job, similarly to bond in Linux.
I see multiple options here:

1. make lagg auto-change type based on the first interface attached. That would involve quite a lot of mechanics with notifications when changing between eth/ib.
2. require lagg creation to specify laggtype in the creation params, assuming ethernet by default. ifconfig(8) needs to be updated (changes similar to vxlan_create() in sbin/ifconfig/ifvxlan.c).

(1) benefit that it won't require any userland changes when merging, compared to (2), however it comes at the cost of greater kernel complexity.
What is your feeling on requiring users to rebuild ifconfig(8)? Is it an absolute no-go?

In D26254#599454, @melifaro wrote:

The only real question/concern I have is the name. I'm a bit afraid that we're saying that "bond" is an IB port-channel and "lagg" is an ethernet port-channel. It's a bit confusing, given one cannot distinguish which is which by name and the fact that Linux folks are used to "bond" as the ethernet port-channel. If we really want to have the different names (to keep some applications happy?), would it be possible to have a name other than "bond"?

cdefs: require gcc 4.2

to ensure that any commands that completed after we last poll are handled in a timely manner.

In D26733#595994, @hselasky wrote:

This piece of code is about to change with D26254 . I've added the patch there instead.

Anmol is no longer with Panasas. 🙁 We remain interested in this feature, but we no longer have anyone with the cycles to participate in the review.

FWIW, in consultation w/ @kevans, I did s/beadm/bectl/g on beinstall,sh to get myself out of a problem, and it worked without issue.

Removing myself as a reviewer, and adding (the correct) Anmol from Panasas instead.

I am nowhere near competent to review any of this, but I did skim it. One thing that jumped out at me is that you're using "bond", not "lagg", only for Infiniband. That seems like a gratuitous difference; why?

I don't know enough about ACPI to really comment on the code change. The manpage change looks fine, but please remember to bump .Dd when you actually commit.