Please commit ASAP.

Thanks, committed with the two minor changes you suggested.

@salvadore Ping?

Requires https://reviews.freebsd.org/D49584 to work properly (otherwise setting the sysctl(8) gets confused).

In D49543#1129854, @cperciva wrote:

The one user-visible difference is that if we avoid reusing freed IDs then we can quickly hit PCI_INVALID_IRQ and get a panic. If we reuse freed IDs then we only hit that panic when we leak an IRQ (which is a separate issue I'm talking to @jhb about).

If someone can figure out how to resolve the "returning PCI_INVALID_IRQ from intr_map_irq makes bad things happen" issue then I agree there will be no functional difference.

In D49543#1129770, @mhorne wrote:

IMO it is logically preferable to exhaust all unique/unused IDs before issuing one that was previously assigned, then freed. This is how the current code behaves.

In D49543#1129672, @andrew wrote:

Isn't this just working around a bug in the pci code that assumes an interrupt ID can't be PCI_INVALID_IRQ? This change doesn't fix that, just less likely to be seen. I'm not sure how useful the interrupt number field is on arm64 as it depends on which interrupt controller is used.

Looks good to me. Slight commit message nit, the issue here is actually .if defined(NO_ROOT) in Makefile logic rather than -n or -z in a shell script. But the same concept applies.

FWIW I don't have any particular way to test this, except that I've booted an EC2 instance with this patch and everything seems to be working fine. But it seems like an obviously-correct change per the documentation.

Switch to ilog2_long.

@salvadore Is this ok now?

Fix: One sentence per line.

In D49252#1125653, @jhb wrote:

I assume the parties in question realize that the correct behavior is the bus should be settled with _EJ0 returns, but that since that is on the older systems they don't plan to fix it?

I may have more to add to this report later in the month, but I wanted to get something up here before I forgot.

Looks reasonable to me. Should I test in EC2? (If yes, which other patches do I need?)

Change quirk name

Make this an ACPI quirk.

In D49222#1122856, @cperciva wrote:

Yes, the PCIM_PSTAT_PMEENABLE is set to 0 until the eject request arrives at which point it is set to 1.

In D49222#1122616, @jhb wrote:

In D49222#1122599, @cperciva wrote:

This doesn't cause any problems in EC2, but it doesn't solve the "recognizing that we're ready for an nvme disk to go away" problem either. They're definitely using a write to the power status register as a cue to remove the device (per https://reviews.freebsd.org/D49146 ).

Humm, I can't imagine what the goal of this behavior is on the part of EC2. Can the engineers there explain why they think the PME is still pending and needs to be cleared? Do they assert a PME as part of the eject notification? (You can read the PME bit to see when it changes from 0 to 1 if that's helpful.)

This doesn't cause any problems in EC2, but it doesn't solve the "recognizing that we're ready for an nvme disk to go away" problem either. They're definitely using a write to the power status register as a cue to remove the device (per https://reviews.freebsd.org/D49146 ).

In D49193#1121912, @sjg wrote:

FYI I run freebsd-update cron on 1st of each month, this morning I noted that my home machine did not get the updates that the ones at work got.
I ran freebsd-update fetch which failed claiming there was no support for FreeBSD 14.1 amd64, using fetch -4 fixes this.

I don't know why, but I find from my home network that IPv6 is not as reliable as IPv4.

Ok, please commit this and send me instructions on how I should use it. :-)

LGTM, please commit.

In D48574#1121221, @dfr wrote:

To make the script simpler, I chose to squash everything into a single layer per image. In theory, it might be possible to construct 'delta' layers e.g. by parsing the output of diff but it doesn't gain much given that the static and dynamic images are so small.