Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 May 2022 11:39:20 -0400
From:      Matteo Riondato <matteo@freebsd.org>
To:        Warner Losh <imp@bsdimp.com>
Cc:        matti k <mattik@gwsit.com.au>, Alexander Motin <mav@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, Jim Harris <jimharris@freebsd.org>
Subject:   Re: nvme INVALID_FIELD in dmesg.boot
Message-ID:  <20220525153920.sxzi7fhsfzv6yidv@ubertino.local>
In-Reply-To: <CANCZdfrYP-Wz7a-%2B_WEKbT=Yb=mrk0YYifDkzekV6H2q865sDg@mail.gmail.com>
References:  <20220525122529.t2kwfg2q65dfiyyt@host-ubertino-mac-88e9fe7361f5.eduroam.ssid.10net.amherst.edu> <d8462935-2874-2e5c-a7aa-d5352bd0a3c2@FreeBSD.org> <20220526001715.4ffee96a@ws1.wobblyboot.net> <CANCZdfrYP-Wz7a-%2B_WEKbT=Yb=mrk0YYifDkzekV6H2q865sDg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--65nvyd67luamsejh
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2022-05-25 at 11:29 EDT, Warner Losh <imp@bsdimp.com> wrote:
>
>SET FEATURES (opcode 9) feature 0xb is indeed async event=20
>configuration.
>0x31f is:
>SMART WARNING for available spares (0x1)
>SMART warning for temperature (0x2)
>SMART WARNING for device reliability (0x4)
>SMART WARNING for being read only (0x8)
>SMART WARNING for volatile memory backup (0x10)
>Namespace attribute change events (0x100)
>Firmware activation events (0x200)
>
>I wonder which one of those it doesn't like. My reading of the standard=20
>suggests that those should always be supported for a 1.2 and later=20
>drive... Thought maybe with the possible exception of the volatile=20
>memory backup, so let me do some digging here...
>
>We can get the last two items from OAES field of the controller=20
>identificaiton data. This is bytes 95:92, which if I'm counting right=20
>is the last word on the 040: line in the nvmecontrol identify -x nvmeX=20
>command:
>
>040: 4e474e4b 30303150 000cca07 00230000 00010200 005b8d80 0030d400=20
>00000100
>--------------------------------------------------------------------------=
--------------------------------^^^^^^^^^

On my system:

040: 31564456 30373130 5cd2e400 00000500 00010200 001e8480 002dc6c0=20
00000200

(same for all nvmeX, as far as I can tell)

>It looks like we don't currently test these bits before we add the last=20
>two (we do it unconditionally for >=3D 1.2, and maybe we should check=20
>these bits >=3D 1.2).
>
>Would you be able to test a fix for this?

Yes, I would be happy to, but I cannot do it for a couple of weeks=20
(running simulations for a deadline).

Thanks,
Matteo

--65nvyd67luamsejh
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJHBAABCgAxFiEEa9uKZL0hP4E8Nl5vGwL9SVQlVQEFAmKOTacTGGhrcHM6Ly9w
Z3AubWl0LmVkdQAKCRAbAv1JVCVVAQrmEADq3C7OD4UXRghoDttG3XOiFuRY2zY7
y6w6zZpAdlVw3wadHyW0yZ+UR5KdnnoSUnM99vDy8dxsPQ/xyuSb/sK6INENlX6t
2xFyP8OL4MQxdp0c17Pc9+MpU//nderecivMr4oB5HznipRuGl430SKTkk7/kIWw
0lSGUkfYDu+FLKg8TJNyJ9LCm3lCGA2tESOI4DJ9IDhSvQwnWskJJb0hOwB2TxiR
FjpYpIn2erLfauCidNIJSz1ieNYjl9iSCdzIjZm4WZ97xM3kJ27fouIATz6b8g+3
p+aW6srN3GBKr7uh9W5igH+4MSa9bYl6N0/tqA8tODOyq7yai/MIlAG7ZOpG42zr
EDJq5EbUY4yiL7KXrcbECir6uaYQmk5JBh626LcN1zWHBbrVWE/+va2s/xxuqBQg
2f7BFkhjH3TafHlBq+cTO8s8iGGXSjj7QVBQFXutkkye0t+LiFvdZH/IOfJaK2N/
l9JwA0rR/a6e6evAgM6vwAmfSmxLS7FcaujEfm7uMKCX5eAhWRA9tmNt698Rw+vd
h53ZRPu9JBq0RB5UUzZiEecZX9OguvoWE4iTNPNw8OaiJJzjoaebY234ug+IDVeJ
zqfT10DWxzrOsjQwYWBY1xdDKurAkXktuB3YTYUNUlC0bP+D7Tgsq3V+c9/t0S9c
FT8x/l4n9fxp+A==
=Y3uD
-----END PGP SIGNATURE-----

--65nvyd67luamsejh--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220525153920.sxzi7fhsfzv6yidv>