SAT-SMART driver is causing major problems for the USB subsystem in 10.13.6
robohack opened this issue · comments
I had installed the signed copy of version 0.8 of this driver on my older iMac running 10.13.6 to enable SMART over FireWire to my new OWC ElitePro Dual U3FW-R1 enclosure, and that part worked great.
However I also have a JMicron based USB enclosure with a drive I use for Time Machine, and it kept disconnecting and leaving the rest of the USB system in disarray (system_profiler and USB Prober would hang, other devices, especially USB-Serial adapters would get stuck or disappear, etc.).
For now I've removed the driver. I'm reluctant to try a new version without some assurance that this particular bug has been fixed. I'm also reluctant to try an un-signed release.
The JMicron shows up as:
Usb production:
Product ID: 0x2509
Vendor ID: 0x152d (JMicron Technology Corp.)
Version: 1.00
Serial Number: 00A123457741
Speed: Up to 480 Mb/sec
Manufacturer: JMicron
Location ID: 0x24100000 / 1
Current Available (mA): 500
Current Required (mA): 2
Extra Operating Current (mA): 0
Media:
ST1000DM003-1ER162:
Capacity: 1 TB (1,000,204,886,016 bytes)
Removable Media: No
BSD Name: disk2
Logical Unit: 0
Partition Map Type: GPT (GUID Partition Table)
S.M.A.R.T. status: Verified
USB Interface: 0
Volumes:
EFI:
Capacity: 209.7 MB (209,715,200 bytes)
File System: MS-DOS FAT32
BSD Name: disk2s1
Content: EFI
Volume UUID: 85D67001-D93E-3687-A1C2-79D677F0C2E0
External-Backup:
Capacity: 999.86 GB (999,860,912,128 bytes)
Available: 339.45 GB (339,447,554,048 bytes)
Writable: Yes
File System: Case-Sensitive Journaled HFS+
BSD Name: disk2s2
Mount Point: /Volumes/External-Backup
Content: Apple_HFS
Volume UUID: C72315AD-ABD9-313D-ACC6-B0C637296A06
When it goes offline the logs show SATSMART timeouts several times (which I suspect are for the USB drive, then the disk's "channel" goes offline, writes fail, and the volume is unmounted (the IOStorageFamily messages repeat many times):
2018-08-12 14:59:41.983089-0700 0x18402 Default 0x0 0 0 kernel: (SATSMARTDriver) IOSATDriver::sendSMARTCommand failed, service response 1, task status 255
2018-08-12 14:59:41.983105-0700 0x18402 Default 0x0 0 0 kernel: (SATSMARTDriver) REQUEST: [ d0 00 00 4f c2 00 b0 ], flags 0x2000, opcode 0x1, timeout 30000 direction 1, count 1, protocol 4 bytecount 512
2018-08-12 14:59:41.983139-0700 0x18402 Default 0x0 0 0 kernel: (SATSMARTDriver) senseData: VALID_RESPONSE_CODE=2 (7=valid),
: SEGMENT_NUMBER=0,
: SENSE_KEY=184 (7 = FILEMARK, 6 = EOM, 5 = ILI, 3-0 = SENSE KEY)
: INFORMATION_1,_2,_3,_4=91,75,51,234,
: ADDITIONAL_SENSE_LENGTH=150,
: COMMAND_SPECIFIC_INFORMATION_1,_2,_3,_4=0,0,0,0,
: ADDITIONAL_SENSE_CODE=0,
: ADDITIONAL_SENSE_CODE_QUALIFIER=0,
: FIELD_REPLACEABLE_UNIT_CODE=0,
: SKSV_SENSE_KEY_SPECIFIC_MSB=0 (7 = Sense Key Specific Valid bit, 6-0 Sense Key Specific MSB),
: SENSE_KEY_SPECIFIC_MID=194,
: SENSE_KEY_SPECIFIC_LSB=0
2018-08-12 15:00:46.305795-0700 0x6f Default 0x0 0 0 kernel: (IOStorageFamily) disk2s2: device/channel is not attached.
2018-08-12 15:00:46.305882-0700 0x18738 Default 0x0 0 0 kernel: (IOStorageFamily) disk2s2: media is not present.
2018-08-12 15:00:46.306086-0700 0x16a Default 0x0 0 0 kernel: (IOUSBMassStorageDriver) USB device 152D250924100000 - fConsecutiveResetCount = 1.
2018-08-12 15:00:46.307764-0700 0x18849 Default 0x0 0 0 kernel: (HFS) jnl: disk2s2: do_jnl_io: strategy err 0x6
2018-08-12 15:00:46.307770-0700 0x18849 Default 0x0 0 0 kernel: (HFS) jnl: disk2s2: write_journal_header: error writing the journal header!
2018-08-12 15:00:46.344696-0700 0x1884d Default 0x0 0 0 kernel: (HFS) hfs: unmount initiated on External-Backup on device disk2s2
There hasn’t been an update for almost four years now and it never signed by the developer, so I don't think you'll find the help you are looking for here. You might have better luck contacting the third party utility developer who signed the version you were using.
The driver's Info.plist defines a very long list of drives to use a non-standard communication mode. Your problematic drive is defined there to use the jmicron-specific mode instead of standard SAT:
<key>(No Name 2)</key>
<dict>
<key>PassThroughMode</key>
<string>jmicron</string>
<key>idProduct</key>
<integer>9481</integer>
<key>idVendor</key>
<integer>5421</integer>
</dict>
(The decimal numbers make the correspondance a lot less obvious.)
Removing this entry or changing "jmicron" to "sat16"/"sat12" could help.
They might have changed the hardware, but used the old USB id.
Thanks @Artoria2e5 for your comments. I guess I'll just just close this issue though as I'm not using that drive as much any more and I'm on a new Mac and of course much newer OS.
It would still be interesting to have SMART data access for this drive, but I won't be able to pursue testing this driver again, and with lack of any recent updates I'd be reluctant to try this in a current kernel anyway.
Hmmmm, it could be interesting to put a access method setter in the driver so a program can change it at runtime... Changing Info.plist would have the downside of requiring a re-sign.
Configuring the driver runtime would be possible, but it is too late in boot if you have the enclosure plugged in.
That would be too late to not break the USB stuff, but I was thinking about making smartctl -d sat,16 kind of work – so that I can get the actual SMART logs and not be stopped by these 48-bit problems. Wait, this feature already exists in smart_status.c via IORegistryEntrySetCFProperties!
.... of course it didn't quite work. I didn't even know it could return kIOReturnUnsupported. the binaryfruit thing is supposed to be unchanged, riiiight?
$ sudo ./smart_status 0x10000049e sat16
ID : 0x10000049e
Class : fi_dungeon_driver_IOSATDriver
Set PassThroughMode = sat16
IORegistryEntrySetCFProperties returned 0xe00002c7.