certainly RAID, and it would appear it also happens with some third party SATA cards that require drivers. In some situations, the TRIM command won't get passed through from the OS to the drives controller. I suspect given some idle time, you won't see a difference. It would be interesting to see some read/write tests when new, then again after a few months usage with no TRIM. I really don't think you are going to see any performance degradation over time by not using TRIM. TRIM just does it at the OS level and in real time. Every SSD I have seen has some sort of internal "garbage collection" scheme, and if left to idle this will run and clean up the drive, restoring performance. Am I missing something.Īll of that aside, IMO everybody is overly concerned about this whole TRIM issue. From what I am reading here, you folks are having trouble running TRIM on the secondary drive, so your plan is to swap around and make put the slave drive in the master location the enable TRIM and run fsck? I assume you don't have the OS on this secondary drive, so I'm not seeing how this will work. The fsck command does it instantly and you are done. If you do that, there is no reason to wait (idle) at all. The second SSD is used as a Photoshop/Lightroom scratch and cache disk and is connected to a SATA-II PCIe card. The first SSD is my boot drive and connected to the lower optical drive connector. So what's the deal? Why won't TRIM enabler support both SSDs? This time I was able to enable TRIM enabler, so since then I've reconnected the 2nd SSD but haven't touched the on/off function of TRIM enabler. Next I shut down the Mac, disconnected the SATA cable from the 2nd SSD and powered up the Mac again. I figured it might have something to do with the second SSD, so using "Disk utility" I ejected the drive and tried again. So I decided to turn TRIM enabler off, then on again, however I wasn't able to turn it on again! I got an error message saying something along the lines that I probably had an Apple SSD or something (which of course is incorrect). A few days ago I added another SSD (same brand, type and size) and was surprised that it didn't show up in that application. I have an Etrecheck report as well: EtreCheck version: 5.5.I've been running TRIM enabler with a single SSD (Samsung 830, 128 GB) for a few months with no issues. System uptime in nanoseconds: 60743822424 Kernel Extensions in process name corresponding to current thread: kernel_taskĭarwin Kernel Version 18.7.0: Thu Jan 23 06:52: root:xnu-4903.278.25~1/RELEASE_X86_64 Panic(cpu 0 caller 0xffffff7f8d966ae5): "Failed to complete supporting devices (CPU 0), Frame : Return Address The frame addresses can also be slightly different. For example, last loaded kext can be either or. There are many of them and they are all 99% identical. Panic logs show that only com.apple kexts (plus one from intel) were loaded at crash timeĭo you have any hints about what is happening and how could I solve it? Suggestions about how to investigate deeper? Panic logs.The issue does happen when logging as guest user or even in the login screen.When the OS reboots after panic, I see the "Your computer restarted because of a problem." message - something like this.I have some control over the frequency of kernel panics because I can control sleep from the energy preferences, but this is not a good solution of course. During the night, this can go on forever and when I open the lid in the morning, the device is very hot and spinning, probably because of this sleep -> panic -> reboot cycle.
Starting last week, whenever the OS would be supposed to go to sleep, it goes through a kernel panic instead, and reboots automatically. I have a MacBook Pro with macOS 10.14.6 installed.