2013 Mac Pro (FP D500 x2) [3rd,6C,E] + Radeon VII @ 16Gbps-TB2>TB3 (Mantiz Venus) + macOS 10.14.5 [itsage]
That was my impression too. I think there are not many nMPs going in for service so they make the facility hardware repair option most appealing. I was fortunately enough to chat with the tech who did diagnostics on my Mac Pro. He said in one scenario he was able to hear the boot chime (removed all but one RAM module).
He said in one scenario he was able to hear the boot chime (removed all but one RAM module).
The chime indicates successful POST - but I presume he was unable to boot beyond?
I might have heard him wrong. The only scenario the nMP produces a beep is when there’s no RAM module installed.
CR0: 0x0000000080010033, CR2: 0x0000000000000008, CR3: 0x00000001f1edf002, CR4: 0x00000000003626e0
RAX: 0x0000000000000000, RBX: 0xffffff803e93e000, RCX: 0xffffff803b0ca800, RDX: 0x00000000e0000255
RSP: 0xffffff81f9523b08, RBP: 0xffffff81f9523b30, RSI: 0x0000000000000000, RDI: 0x0000000000000000
R8: 0xffffff81f9523bb8, R9: 0x0000000000000000, R10: 0x0000000000000000, R11: 0x0000000000000000
R12: 0x00000000e0000255, R13: 0xffffff803b0ca800, R14: 0xffffff803e93e090, R15: 0xffffff803c7ae000
RFL: 0x0000000000010202, RIP: 0xffffff800be63493, CS: 0x0000000000000008, SS: 0x0000000000000010
Fault CR2: 0x0000000000000008, Error code: 0x0000000000000000, Fault CPU: 0x4, PL: 0, VF: 0
Backtrace (CPU 4), Frame : Return Address
0xffffff81f9523560 : 0xffffff800bd41b6b
0xffffff81f95235b0 : 0xffffff800be78e95
0xffffff81f95235f0 : 0xffffff800be6a8fe
0xffffff81f9523640 : 0xffffff800bce8bb0
0xffffff81f9523660 : 0xffffff800bd41257
0xffffff81f9523760 : 0xffffff800bd4163b
0xffffff81f95237b0 : 0xffffff800c4d2879
0xffffff81f9523820 : 0xffffff800be6acaa
0xffffff81f95239a0 : 0xffffff800be6a9a8
0xffffff81f95239f0 : 0xffffff800bce8bb0
0xffffff81f9523a10 : 0xffffff800be63493
0xffffff81f9523b30 : 0xffffff800c416c8f
0xffffff81f9523ba0 : 0xffffff800c4a7e6f
0xffffff81f9523c00 : 0xffffff800c4174b9
0xffffff81f9523c50 : 0xffffff800c4a7415
0xffffff81f9523d10 : 0xffffff800c4a70ad
0xffffff81f9523d40 : 0xffffff800c298c96
0xffffff81f9523e00 : 0xffffff800c2b339e
0xffffff81f9523f40 : 0xffffff800c39d8b9
0xffffff81f9523fa0 : 0xffffff800bce9376
BSD process name corresponding to current thread: launchd
Mac OS version:
Darwin Kernel Version 19.0.0: Sat Aug 31 18:49:12 PDT 2019; root:xnu-6153.11.15~8/RELEASE_X86_64
Kernel UUID: 7878452F-EDBA-3FDA-8430-29920E2E2C99
Kernel slide: 0x000000000ba00000
Kernel text base: 0xffffff800bc00000
__HIB text base: 0xffffff800bb00000
System model name: Macmini8,1 (Mac-7BA5B2DFE22DDD8C)
System shutdown begun: YES
System uptime in nanoseconds: 53117689763711
last loaded kext at 52932600454703: @kext.AMDRadeonX4000HWLibs 1.0 (addr 0xffffff7f91b16000, size 18583552)
That's unfortunate to hear they couldn't troubleshoot it better than that. I'm kind of surprised they didn't send it straight to a repair facility to begin with. I do hope the solderless efi chip from the gents at macunlocks fixes your Mac Pro's issue. Keep us Posted.
Mac Pro (Late 2013) 3 GHz 8-Core Intel Xeon E5 | AMD FirePro D700 6GB | 64GB Ram | 256GB SSD | NEC MultiSync PA271W-BK-SV
I received the solderless EFI chip this afternoon. As soon as I installed it, my nMP booted up with the boot chime. Keyboard input was working too so I did a NVRAM reset. Unfortunately it booted into the Windows partition which doesn’t have graphics drivers for the D500 and the screen is black. I saw the Windows logo during boot so I know at least the graphics cards are good. Another tricky issue I’m facing now is that the Boot Screen Selector doesn’t show up when holding OPTION.
Common issue on some Macs which I did notice - resetting NVRAM sometimes just boots Windows partition. Consider trying macOS recovery keyboard combos.
@mac_editor Yes I was too excited then immediately defeated, I forgot about Recovery mode. I tried it after dinner and found more bad news. There’s monitor output during Recovery and initial loading but you can see the red vertical lines on the monitor. This is a sign of a failing graphics card unfortunately. I’m glad I could at least interact with the machine to do further diagnostics. I will take it all apart again this weekend and reflow both graphics cards to see if that helps. 😀
This has been a series of intriguing events all at the same time it would seem. Beta update, EFI chip, possibly RAM, and now GPU. Hopefully you are able to at least get a bootable machine in Safe Mode.
Also, I noticed recently (running Mojave, but firmware is newer since I upgraded to Catalina before) that CMD+R recovery fails for me (goes to internet recovery and fails with -1008F). My guesstimate is due to the expected Recovery system being different vs. Mojave (activation lock, login requirement, etc. - a lot new in Catalina recovery) the firmware throws an error when attempting to boot a Mojave recovery partition (on Catalina firmware). CMD + OPT + R internet recovery succeeds, landing me with a Catalina recovery boot. Just in case it doesn't go well for you.
I agree it’s been a crazy series of unusual issues. Come to think of it I believe the GPU to be the ultimate culprit. It must have been failing for a while (a common issue on the trashcan). The boot loop during macOS upgrade was caused by the failing GPU which occurred precisely when the firmware update was taking place. The eGPU was not at fault. 😛
Thanks to yours and the community inputs I’m getting closer to fixing it. I’ll exhaust all options before sending it to Apple facility flat-rate repair.
So essentially, the failing GPU caused the firmware update to fail, resulting in a massive double whammy. Cursed luck, given the chances of this happening are slim at best.
My 2013 Mac Pro trashcan is back from the dead! Not quite eGPU-equipped like it was just yet but that should be done soon.
I reflowed the dual D500 discrete graphics cards this past weekend to make sure they were working. Unfortunately I was still having problems booting into macOS. I attempted different stick SSDs with different macOS versions pre-installed (10.13.6, 10.14.6 and latest 10.15 Beta). I also tried Local Recovery and Internet Recovery. Nothing worked.
It then dawned on me the solderless EFI chip may have a much older firmware that doesn’t support APFS partition tables on newer volumes. My last attempt was to boot off a USB Mojave installer then format one of the test drive to Journaled HFS+. That worked! The Mojave clean installation also updated the firmware. The trashcan is now back in action. Thank you all for your valuable input and support. This was quite an IT SAGA! 😀
Excellent news! Is reflowing a temporary workaround or should last?
@itsage What does "reflow" entail? I'm envisioning some kind of solder bath process which seems kind of extreme!
Is the trashcan running on the solderless EFI chip and the firmware on the solderless EFI chip was updated by Mojave? Or is your onboard EFI chip working and updated now?
@mac_editor & @joevt I used a rework station for this task. Once the GPU die was cleaned off, I applied flux paste (out of a syringe) around the gap between the chip and the PCB. The temperature for the heat gun is set at 395 degrees F. I worked the flux paste into the gap to get fully under the GPU die. The idea is to heal any micro-fractures in solder joints. This process went on for about 8 minutes then let cure for a day.
Reflow success is high but it’s not a permanent fix. I used to offer this service on older iMacs and MacBook Pros. Longevity estimate is one month to three years depending on use. I’m planning to strictly use an eGPU with this nMP going forward. Booting up with no monitor connected to the Mac Pro typically helps keeping the dual FirePros idle (no WindowsServer running). Here’s an example of an iMac MXM card.
At the moment I believe the nMP is running on the solderless EFI chip. I ran two macOS system updates with firmware updates so far. After placing the order on macunlocks.com, I had the option to provide the nMP serial number so it would match. I was not able to see which firmware version the EFI chip came with but it worked.
My Mac Pro trashcan is fully back to eGPU testing. I paired four eGPUs to it: RX 580 + AKiTiO Node Duo, R9 Nano + VisionTek mini GFX, Vega Frontier Edition + AKiTiO Node Pro, Radeon VII + NetStor HL23T-Plus. The trashcan has 6x Thunderbolt 2 ports but I only have 2x Thunderbolt 3 to Thunderbolt adapters. Therefore I used AKiTiO Node Duo and Pro were hosting the other two eGPU enclosures. Again we encountered the 4 discrete GPUs limit in macOS. Having two D500 dGPUs already, the system would not recognize more than four.
@itsage Time to search the macOS for all occurrences of the number 4 and change it them to a 5! I'm being silly, but the limit must be somewhere. AppleGPUWrangler kext? Use the log stream command in Terminal.app, connect a 5th gpu, and see if there's any clues.
There might be some nvram variables to give more info
But we can connect 4 eGPUs to an MBP with discrete GPU, making the count 5. Interesting.
Would love to try and figure this out, if only I had that many enclosures and GPUs haha.
Hi did you manage to connect your eGPU and nMP ? I have the same config and looking to make the same move as you.
I just installed a Radeon VII on a Helios FX case. It is connected to a MacPro 6.1. It works perfect, except on sleeping. I mainly use it with Autodesk Flame (VFX App) and in my first tests it renders twice as fast as the D700 of the Mac Pro. Very satisfied.
The only problem is when getting the machine to sleep the fans stay on and make a lot of noise. What would be better? Shut down the computer? Or can I put the Mac to sleep and turn off the case?
I ask this because when I connect my main monitor to the Radeon it doesn't work, it stays off... only my second monitor works using HDMI.