Apple’s forced O/S migration causes Thunderbolt failure

-May 18, 2017

My mid-2011 model Mac mini has served me ably since I bought it as a factory refurb back in November of that same year, aside from a misbehaving HDD that got replaced under warranty in September 2013. While the original system shipped with Mac OS 10.7 "Lion," Apple service installed the then-latest Mac OS 10.8 "Mountain Lion" on the replacement hard drive. I was able to resurrect my data and applications from Time Machine backup, but I was forced into an O/S evolution.

More recently, I needed to evolve my operating system foundation once again; first Firefox (my preferred browser) dropped support for O/Ss prior to Mac OS 10.9 "Mavericks," then I found out that the plugin for my webinar delivery service had also deprecated its support for Mac OS 10.8 and below. Before proceeding further with my story, though, I need to give a bit more background; first off, because I still haven't taken the plunge on the long-pondered SSD upgrade project, the Mac mini boots up (in particular) very slowly. And its half-TByte HDD, a Toshiba MK5065GSXF 2.5" 5400 RPM model, is not only performance-hampered but also capacity-squeezed by not only a full Mac application suite but also a VMWare Fusion-virtualized Windows 7-plus-applications build.

As a result, I offload to external storage the large video files I often find myself working on for my day job. Historically, I've tethered a Western Digital Thunderbolt Duo, containing dual 3 TByte WD "Green" HDDs in RAID 0 mode (for peak transfer speed and capacity, albeit absent any redundancy), to the Mac mini's first-generation Thunderbolt port. The WD storage appliance's secondary Thunderbolt port then connects to a mini DisplayPort-to-HDMI adapter for driving one of the system's two displays; the other LCD direct-connects to the Mac mini's HDMI output. And one other nuance is important in this particular case; since the system boots so slowly, I tend to put it to sleep between uses instead of fully shutting it down.

For several years, this setup has essentially worked without a hitch. It even seemed, at least at first, to survive my latest O/S upgrade unscathed. Recently, however, whenever the system would come out of sleep, its WD Drive Utilities software would complain that the HDD in slot B was "missing," in spite of the fact that the two-drive RAID 0 "striped" group seemingly continued to work just fine. A thorough S.M.A.R.T. test revealed no problems, but just in case, I backed up the Thunderbolt Duo, swapped in a replacement HDD, rebuilt the RAID array and restored data.

The "missing drive" message didn't disappear. Instead, the problems progressed further. Next, upon exiting sleep, I started seeing O/S messages indicating that the RAID array had been improperly ejected, even though connectivity was automatically restored ... at least at first, but eventually only a system reboot would resurrect it. Next, the LCD indirectly connected to the Mac mini via the Thunderbolt Duo intermediary would refuse to wake back up. And eventually, the entire system would randomly freeze until I disconnected the Thunderbolt-connected device chain from the Mac mini.

Theory #2; the Thunderbolt Duo's external "wall wart" power supply was failing. So I bought another one of those. Still no improvement. At that point, I assumed I was dealing with a failing internal power supply subsystem, or a wonky Thunderbolt controller within the storage appliance, or something like that. So I went searching for a replacement for the Thunderbolt Duo. Fortunately, I happened to have a 2 TByte Seagate FreeAgent GoFlex Desk for Mac in my possession. The Mac version of the FreeAgent GoFlex Desk series comes pre-formatted for Apple systems (i.e. HFS+) and also includes a STAE105 dock adapter with USB 2.0 and dual Firewire 800 connection options.

And conveniently, I also had two STAE122 GoFlex Thunderbolt dock adapters on my hands (GoFlex docks convert the SATA connector coming out of the HDD enclosure into various system interfaces).

Here's an oldie-but-goodie photo of the precursor-and-successor drives sitting next to each other, and also alongside the Mac mini:

I had hoped to continue the two-HDD RAID 0 stripe scheme, this time by tethering two separate external drives together. So I bought a short supplemental Thunderbolt cable (to connect the external drives to each other) along with a used 3 TByte FreeAgent GoFlex Desk for Mac drive; the latter didn't come with a dock adapter of any sort, but I didn't need one anyway.

I mounted the drives in the docks, connected them together, tethered one to the LCD and, with the Mac mini already powered up, tethered the other to the computer. An initialization-needed prompt appeared on-screen; I launched into Disk Utility and formatted-and-partitioned both drives, combining the entirety of one with a 2 TByte partition on the latter to construct the aforementioned RAID 0 array.

As for the remaining 1 TByte of space on the latter, I had high hopes for it as well. While the 2 TByte FreeAgent GoFlex Desk for Mac was constructed out of a 5900 RPM HDD, its 3 TByte counterpart I'd just acquired leveraged a speedier 7200 RPM hard drive. I therefore thought I might be able to clone the O/S build currently on the Mac mini's slow internal HDD to the extra 1 TByte partition on the larger GoFlex Desk and, by booting off it instead over Thunderbolt, end up with faster overall performance.

Alas, my aspirations were rapidly dashed. I rebooted the Mac mini ... and neither of the drives mounted, in spite of their Thunderbolt controllers still being "seen" by the system. Unplugging and replugging the cable connecting them to the Mac mini restored normal functionality ... until I put the system to sleep, after which a familiar error message pair greeted me upon subsequent wakeup:

And after that, all the other already-well-known random Thunderbolt-related issues resurfaced, as well; a LCD that wouldn't turn on, drives that would disappear, a system that would lock up until I disconnected the cable, etc. Disabling "Put hard drives to sleep when possible" didn't seem to do the trick, I suspect because this setting only controls internal drives:

And although I had high hopes for Jettison, a well-reviewed utility that purports to auto-eject drives prior to sleep, re-mounting them upon subsequent wakeup, it didn't do the trick either; it couldn't find the Thunderbolt-connected drives post-slumber. So I've bailed. The 3 TByte FreeAgent GoFlex Desk is now connected standalone to the Mac mini via Firewire 800, the second LCD is direct-connected to the Mac mini via the Thunderbolt port and the mini DisplayPort-to-HDMI adapter, and all's well. Seagate's equivalent to the WD Drive Utility even now "sees" the external HDD over Firewire 800:

whereas it never did in the dual-drive Thunderbolt days:

The root cause of my Thunderbolt woes, as far as I can gather from my research so far, may be the more "enthusiastic" power management focus that Apple implemented beginning with Mac OS 10.9. It appears that with Thunderbolt in particular, the company aggressively spins down external drives and other connected peripherals, along with the system controller itself, in sleep mode ... and if things don't wake up fast enough, they're overlooked and/or cause lockups.

Some users have reported that resetting the SMC and/or NVRAM (formerly known as PRAM) alleviates the issue, at least temporarily, and in retrospect I probably should have tried this first. It's helped in the past with wonky systems, and given that all seemed to be fine at first, it's a tempting potential culprit. But at least for now, I'm done experimenting. And I'm admittedly also pretty frustrated with Apple. The company was an early adopter of Thunderbolt, and today remains a dominant user of the technology. That operating system "advancements" result in functional regression to the point of flat-out failure is flat-out unacceptable.

Also see:

Loading comments...

Write a Comment

To comment please Log In