La clé WD (Sandisk) NVMe M.2 ne fonctionne pas tout à fait
Pour être clair, je m'attendais à des ennuis. L'ordinateur est un ancien HP Z820 (certainement pas de prise en charge du BIOS pour NVMe) avec la dernière mise à jour du BIOS 2018. Le bâton est un nouveau (-ish?) Modèle Western Digital (Sandisk):
SSD WD Black NVMe 500 Go - M.2 2280 - WDS500G2X0C
Monté sur une carte PCIe 3.0 x4:
Mailiya M.2 PCIe vers PCIe 3.0 x4
Je n'essaie pas de démarrer à partir de NVMe, il suffit de l'utiliser pour le stockage. Linux voit le lecteur (via lsblk et lspci) et peut lire ... mais pas écrire.
Il s'agit d'Ubuntu 18.04.2 LTS avec la version du noyau:
Linux brutus 4.15.0-46-generic # 49-Ubuntu SMP Wed 6 Feb 09:33:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
(Également testé le 18.10.)
Tiré les sources Linux pour cette version, et pour le Linux 5.0 actuel (de torvalds/linux sur Github). Il existe des différences substantielles de pilote/nvme entre Ubuntu LTS et actuel, avec des mises à jour aussi récentes (!) Qu'hier (2019.03.16 dans "cd drivers/nvme; git log").
Comme je l'ai dit au début, je m'attendais à des ennuis. :)
Je dois mentionner que je connais un peu les pilotes de périphériques Linux, car j'en ai écrit un de complexité modérée.
J'ai essayé de compiler les sources actuelles de Linux 5.0 et "rmmod nvme; insmod nvme" - qui n'a pas fonctionné (pas de surprise). J'ai essayé de copier le pilote 5.0 nvme dans l'arborescence 4.15 et de compiler - ce qui n'a pas fonctionné (pas de surprise non plus, mais bon, j'ai essayé).
Le prochain exercice serait de démarrer à partir du noyau Linux 5.0 actuel. Mais aussi bien mettre cela en public, au cas où quelqu'un d'autre serait plus loin.
Les lectures semblent fonctionner, mais plus lentement que prévu:
# hdparm -t --direct /dev/nvme0n1
/dev/nvme0n1:
Timing O_DIRECT disk reads: 4840 MB in 3.00 seconds = 1612.83 MB/sec
# dd bs=1M count=8192 if=/dev/nvme0n1 of=/dev/null
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 4.57285 s, 1.9 GB/s
Les écritures échouent mal:
# dd bs=1M count=2 if=/dev/zero of=/dev/nvme0n1
(hangs)
De journalctl:
Mar 17 18:49:23 brutus kernel: nvme nvme0: async event result 00010300
Mar 17 18:49:23 brutus kernel: print_req_error: I/O error, dev nvme0n1, sector 0
Mar 17 18:49:23 brutus kernel: buffer_io_error: 118 callbacks suppressed
Mar 17 18:49:23 brutus kernel: Buffer I/O error on dev nvme0n1, logical block 0, lost async page write
[snip]
Mar 17 18:49:23 brutus kernel: print_req_error: I/O error, dev nvme0n1, sector 1024
Mar 17 18:49:23 brutus kernel: print_req_error: I/O error, dev nvme0n1, sector 3072
A fouillé un peu avec l'outil de ligne de commande "nvme", mais seulement en devinant:
# nvme list -o json
{
"Devices" : [
{
"DevicePath" : "/dev/nvme0n1",
"Firmware" : "101140WD",
"Index" : 0,
"ModelNumber" : "WDS500G2X0C-00L350",
"ProductName" : "Unknown Device",
"SerialNumber" : "184570802442",
"UsedBytes" : 500107862016,
"MaximiumLBA" : 976773168,
"PhysicalSize" : 500107862016,
"SectorSize" : 512
}
]
FYI - sortie lspci:
03:00.0 Non-Volatile memory controller: Sandisk Corp Device 5002 (prog-if 02 [NVM Express])
Subsystem: Sandisk Corp Device 5002
Physical Slot: 1
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 37
NUMA node: 0
Region 0: Memory at de500000 (64-bit, non-prefetchable) [size=16K]
Region 4: Memory at de504000 (64-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] MSI: Enable- Count=1/32 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [b0] MSI-X: Enable+ Count=65 Masked-
Vector table: BAR=0 offset=00002000
PBA: BAR=4 offset=00000000
Capabilities: [c0] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <1us, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0.000W
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 256 bytes, MaxReadReq 1024 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L1, Exit Latency L0s <256ns, L1 <8us
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR+, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete+, EqualizationPhase1+
EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest-
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [150 v1] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [1b8 v1] Latency Tolerance Reporting
Max snoop latency: 0ns
Max no snoop latency: 0ns
Capabilities: [300 v1] #19
Capabilities: [900 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+
PortCommonModeRestoreTime=255us PortTPowerOnTime=10us
L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
T_CommonMode=0us LTR1.2_Threshold=0ns
L1SubCtl2: T_PwrOn=10us
Kernel driver in use: nvme
Kernel modules: nvme
Il h. Crédit à échéance. :)
preston@brutus:~/sources/linux/drivers/nvme$ git log . | grep -i 'wdc.com\|@sandisk' | sed -e 's/^.*: //' | sort -uf
Adam Manzanares <[email protected]>
Bart Van Assche <[email protected]>
Bart Van Assche <[email protected]>
Chaitanya Kulkarni <[email protected]>
Jeff Lien <[email protected]>
Également testé avec le noyau Linux actuel (2019.03.17):
root@brutus:~# uname -a
Linux brutus 5.1.0-rc1 #1 SMP Mon Mar 18 01:03:14 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
root@brutus:~# pvcreate /dev/nvme0n1
/dev/nvme0n1: write failed after 0 of 4096 at 4096: Input/output error
Failed to wipe new metadata area at the start of the /dev/nvme0n1
Failed to add metadata area for new physical volume /dev/nvme0n1
Failed to setup physical volume "/dev/nvme0n1".
Extrait du journal:
Mar 18 02:05:10 brutus kernel: print_req_error: I/O error, dev nvme0n1, sector 8 flags 8801
Mar 18 02:09:06 brutus kernel: print_req_error: I/O error, dev nvme0n1, sector 8 flags 8801
Mar 18 02:09:36 brutus kernel: print_req_error: I/O error, dev nvme0n1, sector 8 flags 8801
Donc ... ne fonctionne pas (encore) dans aucune version de Linux, semble-t-il.
Je ne sais pas si vous rencontrez toujours ces problèmes, mais je publierai au moins cela au cas où d'autres le rencontreraient.
J'ai ce même lecteur et je l'utilise comme mon lecteur principal exécutant 18.04. J'ai utilisé l'utilitaire de micrologiciel Windows et je n'ai vu aucune mise à jour à ce stade. J'ai également testé l'environnement en direct pour 19.04, qui présente les mêmes blocages/échecs d'installation que j'ai rencontrés avec 18.04 et 18.10, donc le problème semble toujours ouvert.
Le problème semble être que le lecteur devient instable lorsqu'il passe dans des états de faible consommation, le correctif consiste donc à désactiver les modes de faible consommation via le paramètre de démarrage du noyau. Je l'ai fait il y a quelques mois et je n'ai eu aucun problème le 18.04 depuis. Cette méthode devrait également fonctionner sur les nouvelles versions (18.10/19.04), mais c'est dommage qu'elle n'ait pas encore été corrigée.
Dans le menu de démarrage GRUB, appuyez sur e pour modifier le paramètre de démarrage. Ajouter nvme_core.default_ps_max_latency_us=5500 à la fin de l'éclaboussure silencieuse Ctrl-x pour démarrer, le programme d'installation doit détecter ce disque à l'étape de partition.
Une fois l'installation terminée, appuyez sur shift pendant la mise sous tension pour entrer GRUB encore une fois, ajoutez le même paramètre de noyau nvme_core.default_ps_max_latency_us=5500, Ctrl-x pour démarrer. Vous verrez Ubuntu démarrer avec succès, éditez /etc/default/grub, ajoutez le paramètre nvme_core.default_ps_max_latency_us=5500 encore une fois, exécutez Sudo update-grub. Pour qu'à chaque démarrage, ce paramètre contienne automatiquement ce paramètre dans le grub, plus de modification manuelle.
https://community.wd.com/t/linux-support-for-wd-black-nvme-2018/225446/9