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.

Ping?

I'm not sure that the combination of asserting PME and clearing PMEENABLE makes sense, but it's what works. Hoping for feedback from someone who knows more about our PCI code than I do.

Looks like this only makes single-layer images, whereas I think the old code had minimal being a layer on top of dynamic which was a layer on top of static. I'm not sure if this is something we care about, or even which is better if we do care about it, but I thought I should mention it.

Someone from secteam might correct me, but I don't think we normally bump __FreeBSD_version on releng/X.Y branches after the release. The places I'm aware of where it doesn't end 000 in a release are (a) X.0-RELEASE where we have whatever number HEAD got up to, and (b) rare cases when a new feature is merged after BETA1.

Context which probably doesn't need to be in the commit message: I'd like to make builds on HEAD *reproducible* even if they're not *deterministic*, i.e. given a build I want to be able to extract environment settings which will allow the same build to be reproduced. This will be easier if I can SOURCE_DATE_EPOCH?= a single SOURCE_DATE_EPOCH value and have it apply to all of the loader binaries.