Custom Query (1546 matches)

JMS578 is a JMicron USB3 to SATA bridge (UAS, TRIM, SAT capable) used on 'Orange Pi NAS Expansion board' and 'FriendlyELEC NAS Expansion bay'. It needs '-d sat' to be queried. Adding the following to drivedb.h fixed it:

  { "USB: ; JMicron JMS578", // USB->SATA
    "0x152d:0x0578",
    "", // 0x0100
    "",
    "-d sat"
  },

References: ​https://pastebin.com/rkhmJDED

Transcend TS120GMTS420 is a M.2 2242 SATA SSD not yet supported. 'Smartctl -x' output made on a SATA controller here ​https://pastebin.com/hxkTJxcp (first task, not even mounted the drive at this point -- bash history: ​http://sprunge.us/WbOK) and hours later behind a JMS578 there ​https://pastebin.com/LHUhv5UG

https://www.smartmontools.org/attachment/ticket/761/Transcend.pdf seems to *not* properly describe the attributes since 148-151 are missing for example.

Observations wrt known attributes: 9 interpreted as Power_On_Hours seems to be wrong (still 0 after 2 hours operation) 194 interpreted as Temperature_Celsius matches thumb test

Observations wrt unknown attributes between the two smartctl executions: 148 increased from 9 to 315 149 increased from 1 to 14 150 remained 0 151 increased from 0 to 9 160 remained 0 161 remained 69 163 remained 5 164 increased from 0 to 1012 165 increased from 0 to 5 166 remained 0 167 increased from 0 to 2 169 remained 100 245 increased from 0 to 8096

The raw data for attribute 188 is divided into three words from the seven raw bytes available. Each word defines a timeout and timing associated with the command timeout.

[0:1] Command Timeout Occurred [2:3] Command Timeout Occurred, command was in queue >5 seconds [4:5] Command Timeout Occurred, command was in queue >7.5 seconds

so the output 03 00 03 00 03 suggests that there are three timeouts, three 5 second timeouts, and three 7 second timeouts. Note that a 7 second timeout also counts as a five second. But a 5 second timeout doesn't count as a 7 second timeout. So this number really means that there were 3 7 second timeouts.

So the issue is that smartctl is reading that entire block as a single very large number. So I'm going to see if their is a more up to date version of smartctl, to see if this fixes the issue -- if not I'll open a bug report to smartctl so they know to fix it.