Silicon Motion SM2263 / ShiJi NVMe: standard temperature stuck at 313 K, vendor log page 0xC6 has a dynamic temperature-like value

[proxmox26-dot]

Hi,

I am investigating an NVMe temperature reporting issue on a small Silicon Motion SM2263-based device.

I originally reported this to smartmontools:

smartmontools/smartmontools#633

Christian Franke suggested forwarding the vendor-specific log page question to the nvme-cli project.

Device

Model:
ShiJi 128GB M.2-NVMe

Firmware:
T1103N0L

PCI controller:
Silicon Motion SM2263EN/SM2263XT
PCI ID: 126f:2263

NVMe version:
1.3

nvme-cli:
2.13

libnvme:
1.13

OS:
Debian GNU/Linux 13 (trixie)

Kernel:
7.0.14-14-pve

Standard NVMe temperature

Both smartctl and nvme-cli report approximately 40 °C:

nvme smart-log /dev/nvme0

temperature : 40 °C (313 K)

The raw SMART / Health Information log page 0x02 contains:

00 39 01 64 0a ...

The composite temperature field is therefore:

0x0139 = 313 K ~= 39.85 °C

A smartctl debug trace requested by the smartmontools maintainer confirms that this value comes directly from the device's standard NVMe SMART/Health log, rather than being a smartctl conversion issue.

Temperature Sensor 1 through Temperature Sensor 8 are all unset.

The device nevertheless reports thermal-management activity, including:

Warning Composite Temperature Time: 1
Thermal Management T1 Transition Count: 8
Thermal Management T1 Total Time: 4392

The smartmontools maintainer considers the fixed 313 K value a firmware bug unless the device has no temperature sensor.

Vendor-specific log page 0xC6

The device accepts:

nvme get-log /dev/nvme0 \
    --log-id=0xC6 \
    --log-len=512 \
    --rae \
    --raw-binary

During monitoring, byte offset 0x50 (decimal 80) changes dynamically.

Typical observed values are approximately:

66
67
68
69
70
71
...
74
75

while the standard NVMe composite temperature remains fixed at approximately 39.85/40 °C.

During a conservative read-only validation test, for example:

Standard SMART   C6[0x50]
39.85            69
39.85            68
39.85            70
39.85            71

Longer-term monitoring also shows changes in C6[0x50] during system activity.

I am NOT claiming that C6[0x50] is definitively a temperature field. I have not found public Silicon Motion documentation for vendor log page 0xC6.

It is only an empirically observed dynamic value whose behavior appears temperature-like.

Questions

1. Is vendor-specific log page 0xC6 known for Silicon Motion SM2263 / SM2263XT controllers?

2. Is there any public or existing nvme-cli/libnvme knowledge of the layout of this Silicon Motion log page?

3. Is offset 0x50 known to represent a temperature, thermal state, or another controller parameter?

4. Have similar devices or vendor-specific firmwares been observed to keep the standard SMART composite temperature fixed while exposing thermal information elsewhere?

5. Would decoding such a vendor-specific page, if its format could be established reliably, belong in nvme-cli/libnvme, or should this remain entirely vendor-specific tooling?

I can provide sanitized raw dumps of log page 0xC6 and paired measurements if useful.

For privacy reasons I have not included the complete raw Identify Controller debug dump, because the subsystem NQN contains the device serial number even when smartctl is run with -q noserial.

Thanks.

[ikegami-t]

1. About the LID: C6h (hardware component) log page you can see the OCP specification below.
   OCP Specification: https://www.opencompute.org/documents/datacenter-nvme-ssd-specification-v2-6-2-pdf

2. Also you can use the nvme-cli ocp plugin command as described by the wiki page.
   Wiki page: https://github.com/linux-nvme/nvme-cli/wiki/OCP-documentation
3. Anyway about the drive actual behavior you need ask to the vendor I think.

[proxmox26-dot]

Thanks. I tested the OCP plugin against this drive:

nvme ocp hardware-component-log /dev/nvme0

and also:

nvme ocp hardware-component-log /dev/nvme0 --list

Both return:

error: ocp: failed to get hwcomp log: C6, ret: -22

However, the generic command:

nvme get-log /dev/nvme0 --log-id=0xC6 --log-len=512 --rae --raw-binary

successfully returns 512 bytes.

So at least with nvme-cli 2.13, this device's log page 0xC6 does not appear to be accepted as an OCP Hardware Component Log Page.

This seems to suggest that the drive may be using LID 0xC6 for a vendor-specific format rather than the OCP format.

I will try to identify the actual device vendor / firmware source, but documentation may be difficult to obtain.

Thanks for the pointer to the OCP specification.

[ikegami-t]

Thanks for your testing. Right seems the drive LID: C6h not supported for the OCP specification as mentioned. You need ask to the vendor as difficult to get the documentation.

[maxDeveloper42]

I think this is not‑nvme‑cli’s‑problem and the issue can be closed.

The drive re‑uses LID 0xC6 for a proprietary vendor‑specific log page, instead of the standardized OCP Hardware Component Log format. Without official documentation from Silicon‑Motion there is nothing to implement on the nvme‑cli side.