Jonathan Matthew <[email protected]> wrote:
Thanks. That looks interesting. Everyone with trouble please test.
Everyone without trouble, test also.
> > These new systems are nvme. Do we have a situation where the last hibernate
> > write operation gets skipped in subr_hibernate.c, or do we have low-level
> > side-effect-free io functions which don't do their job. Is
> > nvme_hibernate_io()
> > failing the last write to disk?
>
> Looking at the nvme shutdown code again, I realise we're not deleting
> the hibernate i/o queue, which we're supposed to do as part of the
> normal shutdown procedure. Perhaps without that the controller isn't
> flushing all the data out to non-volatile storage. We don't issue a
> flush command after the last hibernate write, but we shouldn't have
> to.
>
> Maybe this will help? (only compile tested)
>
>
> Index: nvme.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/ic/nvme.c,v
> diff -u -p -r1.125 nvme.c
> --- nvme.c 16 Dec 2025 00:24:55 -0000 1.125
> +++ nvme.c 5 Jan 2026 04:17:41 -0000
> @@ -557,6 +574,12 @@ nvme_shutdown(struct nvme_softc *sc)
> printf("%s: unable to delete q, disabling\n", DEVNAME(sc));
> goto disable;
> }
> +#ifdef HIBERNATE
> + if (nvme_q_delete(sc, sc->sc_hib_q) != 0) {
> + printf("%s: unable to delete hib q, disabling\n", DEVNAME(sc));
> + goto disable;
> + }
> +#endif
>
> cc = nvme_read4(sc, NVME_CC);
> CLR(cc, NVME_CC_SHN_MASK);
