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

In D28247#632482, @kp wrote:

I don't think it's a string length issue.

In D28247#632482, @kp wrote:

I don't think it's a string length issue. It's an issue of incorrect assumptions. This patch assumes that the original name of the interface is always the driver name ('if_dname') plus unit number. That's not the case for epair interfaces, and I wouldn't be surprised that this also fails for vlan interfaces (where the numeric suffix is not the unit number).

Committed as R10:b84d0aaa4e64

In D28247#632273, @kp wrote:

It turns out there's an edge case we didn't consider:

epair0a: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        initname: epair0
        options=8<VLAN_MTU>
        ether 02:a5:17:a0:1e:0a
        groups: epair
        media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Also, this wants a test case or two.