TL;DR: 2012 MBA, failed SSD. Used an adapter with regular NGFF SSD and it works fine, but resume from sleep always crashes. Suspect it has to do with the SMC lines that don't exist on normal SSDs and am asking for information on these signals or on a kext/patch that ignores them.
I have an 11" 2012 MBA (MacBookAir5,1: i7, 8GB, 512G SSD) that works great. The SSD died and I'm loathe to spend what Apple or OWC want for a replacement. I bought a Biwin 512GB SSD and adapter, both from Aliexpress. Installed El Cap and restored. I also purchased a separate adapter just for comparison but it brings the same connections out, just in a different (with lower SI, IMO) way.
Everything works great, as it did before, with the exception of waking from sleep. I get a kernel panic every time. The 10.11.4 update changes this slightly where the login screen comes up, but I can't type anything and I eventually get the spinning circle and have to hard-power-cycle. Cold boots always work.
I've played around with suspend-to-RAM only, suspend-to-disk-always and the normal sleep (suspend to RAM, then dump to disk after an extended time off). They all crash the same way. My suspicion is that the SSD is either not waking up correctly or waking up in a different state than OSX is expecting the controller to be in, leading to the crash.
Examining the adapter and the MBA schematics (and examining the original failed Samsung Apple-branded SSD) I can see that there are only a few connections actually used: +3.3V, GND, SATA TX/RX and a two lines that are NOT part of the NGFF spec: SMC_OOB1_TX and _RX. The OEM drive doesn't use any other connections, and the adapter does not bring the SMC connections out to the NGFF drive. I scoped these two non-standard signals and surprisingly they are just normal 115200N81 UART signals. I can clearly see the SMC trying to talk to the drive, but my fried SSD is sufficiently fried that it doesn't talk back, meaning that I don't know what it's returning.
2s after power on, the SMC sends 0xf1 0x03 0x82 0x03 0x28 0xf7 to the drive. 50ms after that, the SMC sends 0xf1 0x05 0x80 0x80 0x80 0x80 0xe8 0xf7 to the drive. 1ms later, it sends 0xf1 0x03 0x82 0x03 0x28 0xf7 to the drive.
The SMC repeats those last two stanzas every 50ms for a total of 8 attempts.
From just a cursory analysis I can see that commands start with 0xf1 and end with 0xf7, and the second byte is the payload length.
My plan is to scope these two signals on a working MBA and emulate the response with a little AVR or something, but I wonder if anyone else has run across this before. Clearly OWC has figured this out since it's impossible that they're selling replacement drives that won't resume. OWC was selling temperature sensor adapters for iMacs which I thought might be a lead, but that doesn't seem to explain why it works fine (my fan isn't on all the time) and just won't resume.
It's also possible that OSX is balking at the SSD manufacturer name "BIWIN SSD" instead of "APPLE SSD SM512C" but I find this to be unlikely given the nature of the crashes.
For those interested, I've saved some of the wake crash logs here and here (both 10.11.3) and here (10.11.4, where it comes up but hangs with the spinny circle).
[link] [comments]
Post a Comment