Done, MFC'ed as r333106.

Thanks for looking into this!

In D14880#312984, @jhb wrote:

Hmm, what are the cases when the hint is wrong? The kernel always prefers the hint for the acpi0 driver (see sys/x86/acpica/OsdEnvironment.c:AcpiOsGetRootPointer). The hint name is just an implementation detail, it is only set by the loader if the loader actually finds the root pointer via the memory scan or from EFI's system tables.

• share the trampoline allocation logic between i386 and amd64.
• Define bootMP_size in assembly for amd64 also (so it can be set at link time).
• Define GiB/MiB in a pre-patch.

Thanks, new version coming up.

In D14400#303264, @jkim wrote:

In D14400#302932, @jhb wrote:

i386 calls acpi_install_wakeup_handler() in the existing MD attach hook acpi_machdep_init() earlier in acpi_machdep.c. amd64 should probably follow the same approach. Hmm, it seems amd64 intentionally stopped doing that in r197863, but it's not clear to me why that change was made. The difference seems to be whether the memory is allocated before or after all of the devices (not just acpi0) are probed and attached. If r197863 could be reverted I think that is the cleanest approach.

I am not 100% sure why I did it but I *think* it was not possible at the time, probably because amd64 and i386 had too many differences. I believe it's okay now. Please try this patch.

acpi.diff996 BDownload

Introduce a tunable.

Use "ifdef" instead of "if defined"

Move acpi_install_wakeup_handler call.

I've been thinking about this patch, is there any reason the wakeup memory chunk is not allocated in acpi_attach?

In D14399#302096, @ian wrote:

Does ACPI_FADT_NO_CMOS_RTC also imply that there is no battery-backed nvram (aka "cmos") available? If so, then this same sort of check might need to go into the MOD_LOAD case in nvram(4) (dev/nvram).

Thanks for the review.

Return ENXIO if ACPI reports that the device is not present.

In D14267#299114, @emaste wrote:

Existing indentation in this file is a mess, but there are a couple of new cases that don't match either of the two existing styles. I suggest tweaking this change to match the surrounding cases, and then someone (@imp or me, perhaps) should follow up with reformatting the portions that don't conform to style(9).

Remove FreeBSD specific ld emulation flag

Thanks.

Sorry for jumping out of the blue, but I don't understand what this is all about. You seem to use lagg together with VFs (I assume PCI Virtual Functions), yet there's no commit message at all explaining what's going on, I think you should add a proper commit message describing how this is supposed to work.

Thanks, that's indeed better.