Curious..
It's probably connected to accessing the sleepimage file during wakeup. No sleep image, no problem
Curious..
Weird, why the kext that read the NVRAM showed into this KP?
You should test another blade before anything.
Workstation:~ Fangio$ diskutil list
/dev/disk0 (external):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 500.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk7 499.8 GB disk0s2
[...]
/dev/disk7 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +499.8 GB disk7
Physical Store disk0s2
1: APFS Volume Samsung 970 Mojave 175.0 GB disk7s1
2: APFS Volume Samsung 970 High Sierra 150.0 GB disk7s2
3: APFS Volume Preboot 48.7 MB disk7s3
4: APFS Volume Recovery 1.1 GB disk7s4
5: APFS Volume VM 20.5 KB disk7s5
Update: disabling hibernation solved the issue. It now sleeps solid and wakes up in an instant after a day of sleep.
com.apple.message.domain: com.apple.sleepwake.failure
com.apple.message.signature3: Wake
com.apple.message.signature: Drivers Failure
com.apple.message.signature2: IOU2(PXS3 IONVMeController),RP03(Intel82574L),RP04(Intel82574L),SATA(AppleAHCI)
com.apple.message.value: 5
com.apple.message.summarize: NO
SenderMachUUID: 82BA3EF4-1A03-3292-A7FA-95B595883B9B
com.apple.message.domain: com.apple.wake.failure
com.apple.message.signature: Drivers Failure
com.apple.message.signature2: IOU2(PXS3 IONVMeController),RP03(Intel82574L),RP04(Intel82574L),SATA(AppleAHCI)
com.apple.message.summarize: YES
SenderMachUUID: 82BA3EF4-1A03-3292-A7FA-95B595883B9B
Unclicked "put hard disks to sleep when possible" and Mac back to normal
So I've tried the new 970 Evo Plus also, and have had more success.
I had to troubleshoot quite a bit too, but it turned out a dated kext was the culprit when CCC'ed over to the blade. I'm running the 500GB variant on a kryoM.2 adaptor, with 141 bootrom and two boot volumes, HS and Mojave. Firmware is 1B2QEXM7. The x4 linkspeed gets fully utilized as expected, and its stable so far. Very pleased with the result.
View attachment 824645 View attachment 824647
Code:Workstation:~ Fangio$ diskutil list /dev/disk0 (external): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme 500.1 GB disk0 1: EFI EFI 209.7 MB disk0s1 2: Apple_APFS Container disk7 499.8 GB disk0s2 [...] /dev/disk7 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +499.8 GB disk7 Physical Store disk0s2 1: APFS Volume Samsung 970 Mojave 175.0 GB disk7s1 2: APFS Volume Samsung 970 High Sierra 150.0 GB disk7s2 3: APFS Volume Preboot 48.7 MB disk7s3 4: APFS Volume Recovery 1.1 GB disk7s4 5: APFS Volume VM 20.5 KB disk7s5
OK so is the 970 Evo Plus now confirmed as working and is compatable? If confirmed is it too early to perhaps update the M.2 NVMe and AHCI Blades info located at start of this thread for the 970 EVO Plus?
Performing First Aid auf „Samsung 970 Mojave“ (disk1s1)
Repairing File System.
Volume unmounted succesfully.
Run fsck_apfs -y -x /dev/rdisk1s1
Checking the container superblock.
Checking the EFI jumpstart record.
Checking the space manager.
Checking the space manager free queue trees.
Checking the object map.
Checking volume.
Checking the APFS volume superblock.
The volume Samsung 970 Mojave was formatted by newfs_apfs (748.77.8) and last modified by apfs_kext (945.250.127.0.3).
Checking the object map.
Checking the snapshot metadata tree.
Checking the snapshot metadata.
Checking the extent ref tree.
Checking the fsroot tree.
Verifying allocated space.
The volume /dev/rdisk1s1 appears to be OK.
Exit-Code for File System Check is 0.
Original status (aktiviert) is restored.
Vorgang erfolgreich. (Operation succesfull)
I tested the r/w speed of the EVO plus booted up from by old SSD. Read and write speeds decreased within seconds from 1500 to 700.
Yes. They work like a charm. Working together with a 970 Pro.Has someone tested SM951 NVMe drives for compatibility in MP5.1?
So I've tried the new 970 Evo Plus also, and have had more success.
I had to troubleshoot quite a bit too, but it turned out a dated kext was the culprit when CCC'ed over to the blade. I'm running the 500GB variant on a kryoM.2 adaptor, with 141 bootrom and two boot volumes, HS and Mojave. Firmware is 1B2QEXM7. The x4 linkspeed gets fully utilized as expected, and its stable so far. Very pleased with the result.
.. Maybe Fangio has another firmware or version of this SSD
Could you give more details about the outdated Kext?
Btw I had to remove my Velocity Solo x2 PCI card for SATA3 first before things started to work.
Nope. See pic in #628. I can take pics of the box too ofc.. Maybe this will comfirm I wasn't talking BS here
View attachment 825378
Not sure what else I can do to prove that it works. Maybe send an I/O Registry dump to members knowledgeable enough to read that.
The HS volume has had no problems booting from my CCC clone. In Mojave I've had older versions of Lilu w/ AppleALC, Innie & NightShiftUnlocker as plugins, working fine on the SATA SSD. Pretty sure removing helped to boot from the 970 Evo Plus Mojave volume.
Workstation:~ Fangio$ kextstat | grep -v com.apple
Index Refs Address Size Wired Name (Version) UUID <Linked Against>
82 0 0xffffff7f80e71000 0x17f000 0x17f000 at.obdev.nke.LittleSnitch (5210) 0BEBCAD5-9FC2-35B4-A87D-08B14BCB15F5 <8 6 5 3 1>
95 0 0xffffff7f816c0000 0xb000 0xb000 org.dungeon.driver.SATSMARTDriver (0.8.1) F82FDDF4-8465-52D6-DE01-FA1BE76AB4F3 <29 28 27 5 3>
132 0 0xffffff7f82a72000 0x7000 0x7000 com.hzsystems.terminus.driver (4) A34AA04A-490F-DEE3-BF42-CDAE5B86833D <91 6 5 3 1>
Workstation:~ Fangio$ diskutil list
/dev/disk0 (external):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 500.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk1 499.8 GB disk0s2
/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +499.8 GB disk1
Physical Store disk0s2
1: APFS Volume Samsung 970 Mojave 134.8 GB disk1s1
2: APFS Volume Samsung 970 High Sierra 150.0 GB disk1s2
3: APFS Volume Preboot 70.7 MB disk1s3
4: APFS Volume Recovery 1.1 GB disk1s4
5: APFS Volume VM 20.5 KB disk1s5
/dev/disk2 (internal, physical): [...]
/dev/disk3 (internal, physical): [...]
/dev/disk4 (internal, physical): [...]
/dev/disk5 (internal, physical): [...]
/dev/disk6 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +127.5 GB disk6
/dev/disk7 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +255.9 GB disk7
/dev/disk8 (external, physical): [...]
You are making the wrong correlation here, GPU is not the smoking gun. Something else is causing this.There are demonstrated / reproducible issues with Samsung 970 NVMe SSD's used in conjunction with the RX580 and AHCI/SATA devices. Switching to a Tahiti based video card, such as the 7950 or 7970, eliminates the issue.
While @Fangio has noted the 970 Evo Plus is working on a cMP with a AMD 280x, for users who are having issues with the Evo Plus.... What video card are you using?
You are making the wrong correlation here, GPU is not the smoking gun. Something else is causing this.
I've been using the Sapphire Pulse RX 580 + 970 Pro in my office Mac Pro since @crjackson2134 started to have problems and I tried to track it unsuccessfully. I boot numerous times a day, shutdown at day's end and I never get this problem.
This mystery continues.
also a sapphire pulse RX580 together with a 970 evo in a wings PX1 with no problems
Yes, same here. The Velocity Solo x2 was the main reason to move on to NVMe blades. I've had two 830 SSDs connected to it and had to grab additional power for it from drive bay 4, messy look included. When booted from one of them I can't do any firmware updates in Mojave. It would only work in HS where I did all of them so far (083-089 except 087 thanks to the warnings here, and then 138-141).Interesting you say this initiated the resolution. I've noticed some inconsistent behavior with Apricorn Velocity Duo X2. Not enough to say it's not compatible with 140.0.0.0.0 firmware, but enough random issues related directly to this adapter (on occasion only) to be concerned with the adapter moving forward. Was using in conjunction with Velocity Solo X2 before NVMe boot drive (via PX1), but the Solo has since been removed from the system.