looks good to me too

In D16328#347509, @kib wrote:

For data blocks, this is absolutely the right fix.

This is not a right fix for the data blocks, at least for some people. https://wiki.postgresql.org/wiki/Fsync_Errors

I accepted? Really? No, I did not.

So what's actually wrong with this code?
APM is still in the range of things we support, and that standard hasn't changed in a long time.
Many early ACPI machines are now blacklisted as being too old, so we can only run APM on them (though not all of them). FreeBSD still runs on these systems, but 12 will likely be the last release for them since the coming purge will likely prune device support past the point of viability for these machines (plus many have issues running a full range applications that will just get worse as we get into the 13 release). At that time, I agree that this might be a good candidate to evaluate for removal, but not being updated in a along time is not a compelling reason to me.

In D16328#347433, @mckusick wrote:

On further thought, I realize that while we (correctly) deal with the B_PAGING panic, we simply replace it with the "dangling dependency" panic in UFS along with about 100 UFS metadata corruption panics that occur if the I/O fails when writing a UFS metadata block. So, at a minimum we need to make a callback to the filesystem when we are going to fail a write so that it can take some sort of defensive action (such as forcible unmount). This can be done here where we know that we are about to start the cascade or perhaps in buf_free where we should call buf_deallocate if the reason for the buffer being freed is that it had a failed write.

We don't need the zfsloader.efi compat link...

actually do the link to zfsloader now.

make sure all the places you've put the mmc_handle_reply can handle errno-type errors. There's at least one that can't.

In D16312#346248, @andrew wrote:

In D16312#346225, @andrew wrote:

I think this will also remove support for the last ARMv4 SoC.

No, CNS11XXNAS is also ARMv4.

I wish I'd seen this. Any reason why arm_neon.h couldn't just include sys/stdint.h?

https://reviews.freebsd.org/D16290

sparc64 does not need ISADMA either. There's actually no fdc driver that needs it.

In D16260#345589, @andrew wrote:

In D16260#345214, @alc wrote:

Does this architecture actually need VM_FREELIST_ISADMA?

From my reading of the code I don't think so, but I'm unsure it's intended purpose. I would expect riscv also doesn't need it.

In D16258#345051, @kib wrote:

I can only think about failing writes re-dirtying the buffers with error.

last cleanup... Will put through it's paces in a new couple places then commit.

Style changes from john, collapse if statement one layer

Review feedback and fix overrides

let's get this in, modulo the one nit.

I agree with linimon's stuff, but have no other niggles.

This is a good first step...
I wonder, though about the one item I highlighted.

Except maybe the hummingboard one

Hmmm, I have all these boards except the GUMSTIX :).