I have this problem too with ADATA SX8200 Pro 1TB. It happens late a night after I’ve been driving the SSD hard all day working with tens of gigabytes. Get a beachball, can’t switch to anyother apps, then 30 secs later it reboots, upon restart it shows the kernal panic screen and the report to send to apple is same /BuildRoot/Library/Caches/com.apple.xbs/Sources/IONVMeFamily/IONVMeFamily-387.270.1/IONVMeController.cpp:5334
The main job of rubber plunger is to push the key back up so if the issue is the key press is not being detected it might be another problem. In my case my R key was sometimes not detected or double registered. The trace (the metal lines that carry the keyboard signals) looked dirty, black instead of silver. It was the R key on a 2015 MacBook Pro 15” with USA layout and it was the trace doing to the right. I used a very small flat head screwdriver and pushed it under the thin plastic layer that is on to of the trace and scrape the dirt away a few times. Then the key registered correctly. Unfortunately I had messed with the plunger a little to see if there was any dirt under it and half is now not stuck down so now I need to see if it will be ok or needs to be glued back on fully.
The R is a model code variation that means it comes with a metal heat spreader so I’d imagine the S means something similar - the actual SSDs are the same. I’m not sure what 0AX number means, perhaps it identifies the factory it was made in? Here are some 512 GB examples: 2013 MBP MZ-JPU512T/0A6 SSUAX is slow (x2) PCIe/AHCI 2015 MBP MZ-JPV5120/0A4 SSUBX is faster (x2) PCIe/NVMe 2019 iMac MZ-KKW5120/0A7 SSPOLARIS is ridiculously fast, larger card but still fits in MBP 2015. (x4) PCIe/NVMe In terms of speed: SSUAX < SSUBX < SSPOLARIS If buying used, remember to ask the seller for this DriveDX information: Overall Health and Lifetime Left Indicator.
I believe that there is a bug (or a feature!) in the iOS kernel that when the battery level is low, it attempts to send commands to the battery which fail on non-genuine batteries, causing the commands to be sent repeatedly, causing the kernel to use 100% CPU and lock the phone’s UI up, and in my experience if I do manage to get a call out the audio is choppy. My solution was to find a genuine used battery from a reputable seller on eBay that deals in iPhone recycling, unfortunately with this particular seller it is pot luck to find one with a good health value.
When you go below 20% and notice the lag can you try running Lirum Device Info Lite and check if it reports your device as using 100% CPU? That is what mine does but not sure why yet. Mine is an iPhone 6S, iOS 12.1, battery from ebay with apple logo covered with marker pen.
I don’t believe this is the same issue as the CPU throttling Apple have admitted to. In this case the lagging is so bad the phone is essentially unusable, can’t launch apps and can’t even make phone calls, and if any audio plays it can be scrambled. In this case the CPU is still at maximum frequency but the reason for the lagging is the CPU is at 100%. I’ve noticed it on my 6s on iOS 12.1, when battery goes under 20% and I go on an area of no mobile data (or turn off mobile data to simulate) then CPU goes to 100% and battery drains down to zero in no time. You can use Lirium Info Lite to see the CPU usage (CPU Dasher X does not show the total CPU usage so don’t use that). I’m a developer so trying to figure out what process is responsible for this. The moment the phone is connected to the Mac it isn’t possible to debug the problem because it also starts charging which immediately resolves the issue, however enabling network in the Devices window allows it, and can use Instruments to view the process list...
Samsung drives use a 512 block size for NVME and Apple only support 4096 block size so buy one of those (like the OCZ RD400) and it works on a hackintosh with no patching, and if you get the correct adaptor it might work in a MacBook Pro too. There is a lot of misinformation about Apple only supporting NVME in the upcoming High Sierra but that is not accurate.