Depuis quelques temps, j'ai des mail me disant que le daemon smartd a loggu=
=C3=A9 des erreurs pour le p=C3=A9riph=C3=A9rique Samsung SSD 950 PRO 256GB=
, S/N:S2GLNX0H729158H, FW:1B0QBXX7.
Il s'agit de mon disque SSD NMV.
Et les logs et mails ont commenc=C3=A9s apr=C3=A8s la mise =C3=A0 jour du p=
aquet smartmontools (6.6-1+b1 -> 7.0-2), ceci dit sans savoir s'il y a un l=
ien quelconque entre cette m=C3=A0j et le probl=C3=A8me.
Apparement, le disque va bien mais ajoute tous les jours une entr=C3=A9e =
=C3=A0 son log d'erreurs qui ressemble =C3=A0 ceci :
$ sudo nvme error-log /dev/nvme0 | head -30
Error Log Entries for device:nvme0 entries:64
.................
Entry[ 0] =20
.................
error_count : 3528
sqid : 0
cmdid : 0x1a
status_field : 0x4004(INVALID_FIELD: A reserved coded value or an unsupport=
ed value in a defined field)
parm_err_loc : 0
lba : 0
nsid : 0
vs : 0
cs : 0
.................
Entry[ 1] =20
.................
error_count : 3527
sqid : 0
cmdid : 0xa
status_field : 0x4004(INVALID_FIELD: A reserved coded value or an unsupport=
ed value in a defined field)
parm_err_loc : 0
lba : 0
nsid : 0
vs : 0
cs : 0
.................
Un contr=C3=B4le via smartctl ne donne rien d'alarmant =C3=A0 part l'ajout =
de log :
$ sudo smartctl -a /dev/nvme0
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-4-amd64] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
=3D=3D=3D START OF INFORMATION SECTION =3D=3D=3D
Model Number: Samsung SSD 950 PRO 256GB
Serial Number: S2GLNX0H729158H
Firmware Version: 1B0QBXX7
PCI Vendor/Subsystem ID: 0x144d
IEEE OUI Identifier: 0x002538
Controller ID: 1
Number of Namespaces: 1
Namespace 1 Size/Capacity: 256.060.514.304 [256 GB]
Namespace 1 Utilization: 106.228.342.784 [106 GB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: 002538 5761b0b172
Local Time is: Sat Mar 7 21:29:50 2020 CET
Firmware Updates (0x06): 3 Slots
Optional Admin Commands (0x0007): Security Format Frmw_DL
Optional NVM Commands (0x001f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Fe=
at
Maximum Data Transfer Size: 32 Pages
Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 0
=3D=3D=3D START OF SMART DATA SECTION =3D=3D=3D
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 33 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 0%
Data Units Read: 11.141.571 [5,70 TB]
Data Units Written: 8.773.345 [4,49 TB]
Host Read Commands: 202.440.422
Host Write Commands: 115.540.892
Controller Busy Time: 850
Power Cycles: 5.041
Power On Hours: 6.022
Unsafe Shutdowns: 218
Media and Data Integrity Errors: 0
Error Information Log Entries: 3.528
Et les logs et mails ont commencés après la mise à jour du paquet smartmontools (6.6-1+b1 -> 7.0-2), ceci dit sans savoir s'il y a un lien quelconque entre cette màj et le problème. Apparement, le disque va bien mais ajoute tous les jours une entrée à son log d'erreurs qui ressemble à ceci : $ sudo nvme error-log /dev/nvme0 | head -30 Error Log Entries for device:nvme0 entries:64 ................. Entry[ 0] ................. error_count : 3528 sqid : 0 cmdid : 0x1a status_field : 0x4004(INVALID_FIELD: A reserved coded value or an unsuppo rted value in a defined field) parm_err_loc : 0 lba : 0 nsid : 0 vs : 0 cs : 0 ................. Entry[ 1] ................. error_count : 3527 sqid : 0 cmdid : 0xa status_field : 0x4004(INVALID_FIELD: A reserved coded value or an unsuppo rted value in a defined field) parm_err_loc : 0 lba : 0 nsid : 0 vs : 0 cs : 0 ................. Un contrôle via smartctl ne donne rien d'alarmant à part l'ajout de log :
Bonjour, je me risque à faire une réponse au doigt mouillé. À mon sens aussi, il n'y a rien d'inquiétant. Si le problème est apparu au moment de la mise à jour, il est probable que la nouvelle version de smartmontools ait nouvellement pris en charge l'affichage d'un nouveau champ géré par le firmware du NVMe. Il y a donc deux possibilités: - soit l'implémentation de smartmontools est incorrecte; - soit le remplissage du "status_field" par le firmware est erroné. Si c'est le second cas, alors je crois qu'il est possible qu'un message relatif à un champ SUBNQN invalide apparaisse dans le journal du noyau. Juste pour satisfaire ma curiosité personnelle, que donne : # dmesg | grep SUBNQN Peut-être qu'une mise à jour du microcode du NVMe corrigerait alors le problème, si vous avez le courage de vous lancer là dedans. Sinon, en dehors du bruit dans les entrées de journal, ça ne devrait pas poser de problèmes. Amicalement, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d Sent from /dev/pts/2, please excuse my verbosity. --KFztAG8eRSV9hGtP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEiWj4FzqNZS4rFmXPZAyZDOTALZsFAl5kq4AACgkQZAyZDOTA LZt1XQwAhhflEfsSzs3dja5ZgdAuOJsc7hnyONBiCdEmTaqa37s0xMPcgabCB7IP NayUrMeVqa8xOonbqYtGXHBeWllASdFHu1KENT4H8C8RzDyP7ilGq5PyvPPFs+LG PJgMp6bIsNZ1+JEjZEBALXwdIHTHdGOaDPjGRtDLWXKqaj23pEgAYwHqjGuJkpwP NuI56ZMtJ3D87YctJ1pkS5lNtmvcX/DZ92VTIWNa3HLclYkC4knhvA8/BI6F56u8 BN5sH3k4x7SG3vxrjGjMBImmM69kr7DRgIZ1MeHJS8m5CtwoCA+xnhvQ39DzC7nU fuH+G8a3QJKolahO1LvrWZcdKN+ptJe5/dkyBt254aDUE1OfHe3H9i2kBU7w7MgZ z1FAVWEkKFuGLRkUVyHsO88qditDUooJIzEqRkdeo1ahu0WAv0qkdJ1TcqaB3cpg HEzBm091aywFnSSWZVKNymwXtgRwaeWliEG/aEhRCK8NiH3cW4DpWjQCmXnMaesz wASyjhUC =VUQo -----END PGP SIGNATURE----- --KFztAG8eRSV9hGtP--
Et les logs et mails ont commencés après la mise à jour du
paquet smartmontools (6.6-1+b1 -> 7.0-2), ceci dit sans savoir
s'il y a un lien quelconque entre cette màj et le problème.
Apparement, le disque va bien mais ajoute tous les jours une
entrée à son log d'erreurs qui ressemble à ceci :
$ sudo nvme error-log /dev/nvme0 | head -30
Error Log Entries for device:nvme0 entries:64
.................
Entry[ 0]
.................
error_count : 3528
sqid : 0
cmdid : 0x1a
status_field : 0x4004(INVALID_FIELD: A reserved coded value or an unsuppo rted value in a defined field)
parm_err_loc : 0
lba : 0
nsid : 0
vs : 0
cs : 0
.................
Entry[ 1]
.................
error_count : 3527
sqid : 0
cmdid : 0xa
status_field : 0x4004(INVALID_FIELD: A reserved coded value or an unsuppo rted value in a defined field)
parm_err_loc : 0
lba : 0
nsid : 0
vs : 0
cs : 0
.................
Un contrôle via smartctl ne donne rien d'alarmant à part
l'ajout de log :
Bonjour, je me risque à faire une réponse au doigt mouillé.
À mon sens aussi, il n'y a rien d'inquiétant.
Si le problème est apparu au moment de la mise à jour, il est
probable que la nouvelle version de smartmontools ait
nouvellement pris en charge l'affichage d'un nouveau champ géré
par le firmware du NVMe. Il y a donc deux possibilités:
- soit l'implémentation de smartmontools est incorrecte;
- soit le remplissage du "status_field" par le firmware est
erroné.
Si c'est le second cas, alors je crois qu'il est possible qu'un
message relatif à un champ SUBNQN invalide apparaisse dans le
journal du noyau. Juste pour satisfaire ma curiosité
personnelle, que donne :
# dmesg | grep SUBNQN
Peut-être qu'une mise à jour du microcode du NVMe corrigerait
alors le problème, si vous avez le courage de vous lancer là
dedans. Sinon, en dehors du bruit dans les entrées de journal,
ça ne devrait pas poser de problèmes.
Amicalement,
--
Étienne Mollier <etienne.mollier@mailoo.org>
Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d
Sent from /dev/pts/2, please excuse my verbosity.
Et les logs et mails ont commencés après la mise à jour du paquet smartmontools (6.6-1+b1 -> 7.0-2), ceci dit sans savoir s'il y a un lien quelconque entre cette màj et le problème. Apparement, le disque va bien mais ajoute tous les jours une entrée à son log d'erreurs qui ressemble à ceci : $ sudo nvme error-log /dev/nvme0 | head -30 Error Log Entries for device:nvme0 entries:64 ................. Entry[ 0] ................. error_count : 3528 sqid : 0 cmdid : 0x1a status_field : 0x4004(INVALID_FIELD: A reserved coded value or an unsuppo rted value in a defined field) parm_err_loc : 0 lba : 0 nsid : 0 vs : 0 cs : 0 ................. Entry[ 1] ................. error_count : 3527 sqid : 0 cmdid : 0xa status_field : 0x4004(INVALID_FIELD: A reserved coded value or an unsuppo rted value in a defined field) parm_err_loc : 0 lba : 0 nsid : 0 vs : 0 cs : 0 ................. Un contrôle via smartctl ne donne rien d'alarmant à part l'ajout de log :
Bonjour, je me risque à faire une réponse au doigt mouillé. À mon sens aussi, il n'y a rien d'inquiétant. Si le problème est apparu au moment de la mise à jour, il est probable que la nouvelle version de smartmontools ait nouvellement pris en charge l'affichage d'un nouveau champ géré par le firmware du NVMe. Il y a donc deux possibilités: - soit l'implémentation de smartmontools est incorrecte; - soit le remplissage du "status_field" par le firmware est erroné. Si c'est le second cas, alors je crois qu'il est possible qu'un message relatif à un champ SUBNQN invalide apparaisse dans le journal du noyau. Juste pour satisfaire ma curiosité personnelle, que donne : # dmesg | grep SUBNQN Peut-être qu'une mise à jour du microcode du NVMe corrigerait alors le problème, si vous avez le courage de vous lancer là dedans. Sinon, en dehors du bruit dans les entrées de journal, ça ne devrait pas poser de problèmes. Amicalement, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d Sent from /dev/pts/2, please excuse my verbosity. --KFztAG8eRSV9hGtP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEiWj4FzqNZS4rFmXPZAyZDOTALZsFAl5kq4AACgkQZAyZDOTA LZt1XQwAhhflEfsSzs3dja5ZgdAuOJsc7hnyONBiCdEmTaqa37s0xMPcgabCB7IP NayUrMeVqa8xOonbqYtGXHBeWllASdFHu1KENT4H8C8RzDyP7ilGq5PyvPPFs+LG PJgMp6bIsNZ1+JEjZEBALXwdIHTHdGOaDPjGRtDLWXKqaj23pEgAYwHqjGuJkpwP NuI56ZMtJ3D87YctJ1pkS5lNtmvcX/DZ92VTIWNa3HLclYkC4knhvA8/BI6F56u8 BN5sH3k4x7SG3vxrjGjMBImmM69kr7DRgIZ1MeHJS8m5CtwoCA+xnhvQ39DzC7nU fuH+G8a3QJKolahO1LvrWZcdKN+ptJe5/dkyBt254aDUE1OfHe3H9i2kBU7w7MgZ z1FAVWEkKFuGLRkUVyHsO88qditDUooJIzEqRkdeo1ahu0WAv0qkdJ1TcqaB3cpg HEzBm091aywFnSSWZVKNymwXtgRwaeWliEG/aEhRCK8NiH3cW4DpWjQCmXnMaesz wASyjhUC =VUQo -----END PGP SIGNATURE----- --KFztAG8eRSV9hGtP--
