#1201 closed defect (fixed)
SmartCtl on Windows10 sets logpage offset to high value.
| Reported by: | Vikram Manja | Owned by: | Christian Franke |
|---|---|---|---|
| Priority: | major | Milestone: | Release 7.1 |
| Component: | all | Version: | 7.0 |
| Keywords: | nvme windows | Cc: |
Description
On Windows10, when smartctl sends getlogpage command, logpage offset (Command DWORD 12) is set to 0xFFFFFFFC.
This results in errors for drives which support NVMe Spec > 1.2.
Command DWORD 12 should be set to 0.
_
Command used:
smarctl -d nvme -x /dev/sdb
Attachments (2)
Change History (11)
by , 6 years ago
| Attachment: | smartctl_GetLogPage_Submission_Queue_Entry.PNG added |
|---|
comment:1 by , 6 years ago
| Component: | smartctl → all |
|---|---|
| Keywords: | windows added; smartctl removed |
Unfortunately the Windows 10 NVMe driver stornvme.sys does not provide a full fledged NVMe pass-through I/O-Control.
The limited support from IOCTL_STORAGE_QUERY_PROPERTY protocol specific queries does not allow full control pass-through input.
For further diagnostics, please provide output of
smartctl -r ioctl,2 -x /dev/sdb
as plain text (no screenshot please). Use a *.txt attachment or wiki markup for preformatted text.
PS: In future submissions, PLEASE don't set a milestone.
by , 6 years ago
| Attachment: | SMARTCTL_Windows10.txt added |
|---|
comment:2 by , 6 years ago
Please note that in both WinPE and Windows10, command dword 12 of GetLogPage (Log Page Offset Lower) is set to 0xFFFFFFFC.
In Windows 2016, it is set to 0 and the command returns accurate data.
comment:3 by , 6 years ago
From the kernel+driver POV, the original Windows 2016 (build number 14393) is similar to Windows 10 1603. The behavior of the Windows NMVe driver varies between Windows 10 versions or similar Server versions. Sometimes, downgrading stornvme.sys helped to fix issues, see VirtualBox ticket 17228 for an example.
The IOCTL_STORAGE_QUERY_PROPERTY NVMe call does not allow to control the values of most command dwords, in particular of command dword 12. See debug output and the link from above. If real pass-through support is available, which is the case with various vendor specific (Intel, OCZ/Toshiba, Samsung) Windows NVMe drivers, smartctl always sets Dword 12 to 0.
Therefore the bogus 0xFFFFFFFC (aka -4) is possibly the result of a driver bug which cannot be fixed by smartmontools.
Do other tools (e.g. CrystalDiskInfo) work with this drive on an affected machine?
comment:4 by , 6 years ago
Do other tools (e.g. CrystalDiskInfo) work with this drive on an affected machine?
Yes, CrystalDiskInfo 8.1.0 works with Windows 10 on this device which supports NVMe 1.2.1 spec.
comment:5 by , 6 years ago
I assume 'this device' is the SK Hynix PE4010 as seen before. If possible, please attach a PCIe Trace for the GetLogPage Submission Queue Entry issued by CrystalDiskInfo.
comment:6 by , 6 years ago
| Milestone: | undecided → Release 7.1 |
|---|---|
| Owner: | set to |
| Status: | new → accepted |
Test (thanks!) shows that setting ProtocolDataRequestSubValue = 0 fixes the problem. Former setting was broadcast NS (0xffffffff). This suggests that newer NVMe 1.2.1 aware Windows drivers align this value to dword boundary (0xfffffffc) and pass it to command dword 12 (LPOL - Log Page Offset Lower).
Picture of smartCTL GetLogPage Submission Queue Entry from PCIe Trace