am I ok to proceed with this cleanup?

The case I am thinking of, there are 4 NUMA domains, but memory access is equal cost to all four, so there may be better performance to be had by having the default policy be INTERLEAVE instead of FIRST_TOUCH (use the bandwidth of all 4 memory controllers). So I wasn't thinking to override those that request FIRST_TOUCH, but just set the default policy for zones that don't request a specific policy.

For modules that have tunables, you need to set them via kenv (or have them set at boot via loader.conf) BEFORE you load the module.

Would it make sense to have a tunable to control the default policy for UMA? If I wanted to have zones that don't declare themselves UMA_ZONE_FIRSTTOUCH, but interleaved, or something to that effect?

Reviewed By: allanjude
Approved By: allanjude

In P484#2311, @imp wrote:

cp /boot/boot1.efi /mnt/efi/boot/bootx64.efi

is easier :)

After rebase

I had to revert this, as it depends on https://reviews.freebsd.org/D28739 which isn't ready to land yet

Fix a typo

Switch to Scott's newer suggested code that is much cleaner

Add the new code to sys/conf/files.arm64 as well, so IPMI works when built into the kernel

I tested this recently on an ARM64 ACPI box, and ran into a panic at boot:

pmu0: <Performance Monitoring Unit> on acpi0
pmu0: MADT: cpu 0 (mpidr 1179648) irq 23 level-triggered
pmu0: MADT: cpu 1 (mpidr 1703936) irq 23 level-triggered
pmu0: MADT: cpu 2 (mpidr 1310720) irq 23 level-triggered
pmu0: MADT: cpu 3 (mpidr 1835008) irq 23 level-triggered
pmu0: MADT: cpu 4 (mpidr 1048576) irq 23 level-triggered
pmu0: MADT: cpu 5 (mpidr 1572864) irq 23 level-triggered
pmu0: MADT: cpu 6 (mpidr 1441792) irq 23 level-triggered
pmu0: MADT: cpu 7 (mpidr 1966080) irq 23 level-triggered
pmu0: MADT: cpu 8 (mpidr 655360) irq 23 level-triggered
pmu0: MADT: cpu 9 (mpidr 2228224) irq 23 level-triggered
pmu0: MADT: cpu 10 (mpidr 786432) irq 23 level-triggered
pmu0: MADT: cpu 11 (mpidr 2359296) irq 23 level-triggered
pmu0: MADT: cpu 12 (mpidr 524288) irq 23 level-triggered
pmu0: MADT: cpu 13 (mpidr 2097152) irq 23 level-triggered
Fatal data abort:
  x0:                0
  x1: ffffa0001d8103a8
  x2:                0
  x3:                a
  x4: ffff000000721fc0
  x5:               10
  x6:                f
  x7:              254
  x8: ffffa0001d80fe00
  x9: ffff000000aad928
 x10:                1
 x11:                0
 x12:                0
 x13:                4
 x14:               80
 x15:                1
 x16:              700
 x17:                3
 x18: ffff000000f277e0
 x19: ffff000000f27870
 x20: ffff0002023fd43c
 x21:                d
 x22: ffffa0001d80fe00
 x23: ffffa0001d80bc00
 x24:               17
 x25: ffff000000823cd6
 x26: ffffa0001d80bb00
 x27: ffffa0001d805af0
 x28:                1
 x29: ffff000000f277f0
  sp: ffff000000f277e0
  lr: ffff000000720860
 elr: ffff000000720888
spsr:         604001c5
 far:                0
 esr:         96000004
panic: vm_fault failed: ffff000000720888
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x184
panic() at panic+0x44
data_abort() at data_abort+0x1d8
handle_el1h_sync() at handle_el1h_sync+0x74
--- exception, esr 0x96000004
madt_handler() at madt_handler+0xe8
acpi_walk_subtables() at acpi_walk_subtables+0x3c
pmu_acpi_attach() at pmu_acpi_attach+0x64
device_attach() at device_attach+0x400
bus_generic_new_pass() at bus_generic_new_pass+0x11c
bus_generic_new_pass() at bus_generic_new_pass+0xac
bus_generic_new_pass() at bus_generic_new_pass+0xac
root_bus_configure() at root_bus_configure+0x40
mi_startup() at mi_startup+0x22c
virtdone() at virtdone+0x6c
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at      kdb_enter+0x40: undefined       d4200000

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?

Do we want to put this link and section reference in the commit message?

In D28749#643720, @manu wrote:

Any docs on what this should contain ?

In D28707#643461, @imp wrote:

We also have a machine here that won't boot with the patches applied. Please don't commit until that gets worked out....

Should https://reviews.freebsd.org/D28745 be squashed into this review?

It likely makes sense to squash this with https://reviews.freebsd.org/D28738

Ok, I think I've gotten a handle on the git-arc tool.

No, having only one loop that set both kenv is what we need.

In D28707#643366, @emaste wrote:

@allanjude these originated as a number of commits, right? Does it make sense to start committing earlier patches that have been reviewed (e.g. stand bits) and rebase this review?

In D28707#643382, @manu wrote:

In D28707#643380, @tsoome wrote:

In D28707#643373, @manu wrote:

stand patches can't go in without the kernel ones.
If we find a smbios v3 table we don't set the kenv of the v2.1 one so kernel won't work.

Ou, but that would be major pain - it would be bad day for anyone trying to boot older kernel... so we should provide both to let older kernel to work?

Yeah I think so, I think we should just export every smbios table in loader and let kernel choose.

Repost

• stand: Support (and prefer) the SMBIOS 64-bit Entry Point Structure
• smbios: Move smbios driver out from x86 machdep code
• smbios: Support (and prefer) the SMBIOS 64-bit Entry Point Structure
• smbios: Use loader provided adddress for SMBIOS entry point
• acpi: Add workaround for Altra I2C memory resource
• iicsmb: Request the bus recursively in bread()
• ipmi_smbios: Deduplicate smbios entry point discovery logic
• Enable smbios in ARM64 GENERIC
• ipmi: Add smbus and pci ipmi types to aarch64 build
• ig4(4): Add an EMAG device type
• ig4(4): Increase timeout to about 1 second
• ig4(4): Use calculated value when sda_hold is zero in ACPI
• ipmi_ssif: Fix inverted for the end of multi-part reads
• smbios: update makefile for new location of smbios.c
• ipmi: on aarch64, load dependancies to increase chance of finding ipmi device
• ipmi_smbios: remove unused smbios_cksum function
• [squashme] Address feedback from manu and andrew