Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#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)

smartctl_GetLogPage_Submission_Queue_Entry.PNG (2.8 KB) - added by Vikram Manja 4 years ago.
Picture of smartCTL GetLogPage? Submission Queue Entry from PCIe Trace
SMARTCTL_Windows10.txt (15.3 KB) - added by Vikram Manja 4 years ago.

Download all attachments as: .zip

Change History (11)

Changed 4 years ago by Vikram Manja

Picture of smartCTL GetLogPage? Submission Queue Entry from PCIe Trace

comment:1 Changed 4 years ago by Christian Franke

Component: smartctlall
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.

Changed 4 years ago by Vikram Manja

Attachment: SMARTCTL_Windows10.txt added

comment:2 Changed 4 years ago by Vikram Manja

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 Changed 4 years ago by Christian Franke

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 Changed 4 years ago by Vikram Manja

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 Changed 4 years ago by Christian Franke

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 Changed 4 years ago by Christian Franke

Milestone: undecidedRelease 7.1
Owner: set to Christian Franke
Status: newaccepted

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).

comment:7 Changed 4 years ago by Christian Franke

Fixed in r4920, thanks.

comment:8 Changed 4 years ago by Christian Franke

Resolution: fixed
Status: acceptedclosed

comment:9 Changed 4 years ago by Christian Franke

Note: See TracTickets for help on using tickets.