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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 2022-05-25 at 11:29 EDT, Warner Losh <imp@bsdimp.com> wrote: > >SET FEATURES (opcode 9) feature 0xb is indeed async event >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 >suggests that those should always be supported for a 1.2 and later >drive... Thought maybe with the possible exception of the volatile >memory backup, so let me do some digging here... > >We can get the last two items from OAES field of the controller >identificaiton data. This is bytes 95:92, which if I'm counting right >is the last word on the 040: line in the nvmecontrol identify -x nvmeX >command: > >040: 4e474e4b 30303150 000cca07 00230000 00010200 005b8d80 0030d400 >00000100 >----------------------------------------------------------------------------------------------------------^^^^^^^^^ On my system: 040: 31564456 30373130 5cd2e400 00000500 00010200 001e8480 002dc6c0 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 >two (we do it unconditionally for >= 1.2, and maybe we should check >these bits >= 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 (running simulations for a deadline). Thanks, Matteo [-- Attachment #2 --] -----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-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220525153920.sxzi7fhsfzv6yidv>