I don't have any chip documentation to know what is right here, so just wonder if unconditional printing a bunch of raw hex numbers is expected here. It feels mpi3mr_print_fault_info() is another candidate for mpi3mr_dprint().

I am not a big fan of kernel printing something in response to arbitrary user requests, it makes logs messy. Is the error reporting to user is not enough here?

Why not backport 506fe78c48 instead?

My only complaint is that it puts the queue into the same cache line as the main queue, that may be modified by writers. But if you really need it for debugging, it could be understood.

On failure we've already notified consumers that controller has failed. What will report it is back? And is there even a device to sent request IOCTL?

If you say it helps I have no objections, but I see nvme_sim_controller_fail() destroying SIM, so I am not sure you actually get here.

I wonder if there are any namespace-specific events? I remember NVMe specs allow per-namespace SMART, but I don't remember much details now.

In D39620#1008905, @sean_rogue-research.com wrote:

stable/13 has this patch
releng/13.2 doesn't have this patch (yet).

I'm not very familiar with FreeBSD's branching system... I see FreeBSD 13.3-RELEASE was released today, is this bug fix included?

In D43385#989072, @gallatin wrote:

Is it possible that the firmware could set ACPI_HEST_GEN_ERROR_FATAL in ged->ErrorSeverity but not ges->ErrorSeverity ?

There is already a panic in apei_ge_handler(), based on total status severity. Do you see it not enough?

Not very my area, but seems to have sense.

This is already merged.