Pegasus3 R6 - Driver crashes constantly

  • 1.1K Views
  • Last Post 2 weeks ago
Shaun Farmer posted this 10 August 2025

I have a Pegasus3 R6 attached to a brand new Mac Studio(M4 Max, 64GB) macOS Sequoia 15.6 (24G84)

  • Studio is acting as a homelab server running File Services (SMB & NFS), caching service & Plex Media Server
  • R6 was disconnecting every day @ 2:16 AM
  • Only way to recover was to disconnect and reconnect
  • Rebooting also worked most of the time
  • I installed the Promise Utility and it started crashing & disconnecting every hour or two
  • Removed the utility and it's not crashing as often, but it's still happening multiple times a day

Looking at the utility when it was installed, all the arrays/hardware/etc looked good. No errors.

It looks like the driver having issues with SCSIControllerDriverKit on modern Macs while 

Every crash report looks identical to the one below(full report attached) and I was wondering if anyone else is dealing with this and what they did to resolve/mitigate.

-------------------------------------

Translated Report (Full Report Below)

-------------------------------------

Process:             com.promise.driverkit.pegasus [782]

Path:                /Library/SystemExtensions/*/com.promise.driverkit.pegasus

Identifier:          com.promise.driverkit.pegasus

Version:             21.1.0 (1)

Code Type:           ARM-64 (Native)

Role:                Default

Parent Process:      launchd [1]

Coalition:           com.promise.driverkit.pegasus [1006]

User ID:             270

 

Date/Time:           2025-08-09 19:31:57.3608 -0400

Launch Time:         2025-08-09 19:21:37.9199 -0400

Hardware Model:      Mac16,9

OS Version:          macOS 15.6 (24G84)

Release Type:        User

 

Crash Reporter Key:  AF26B97A-38CB-BBBE-C20B-FF6AD113773B

Incident Identifier: BBBF8613-5F9A-4FEA-84AB-0511ED5C4EE9

 

Time Awake Since Boot: 770 seconds

 

System Integrity Protection: enabled

 

Triggered by Thread: 2, Dispatch Queue: PegasusSCSIDext-Default

 

Exception Type:    EXC_BAD_ACCESS (SIGSEGV)

Exception Subtype: KERN_INVALID_ADDRESS at 0x000000016f412968

Exception Codes:   0x0000000000000001, 0x000000016f412968

 

Termination Reason:  Namespace SIGNAL, Code 11, Segmentation fault: 11

Terminating Process: exc handler [782]

 

 

Attached Files

Order By: Standard | Latest | Votes
Shaun Farmer posted this 10 August 2025

Yes, I've tried different cables(Apple & Cable Matters) and all the ports on both devices.

R P posted this 12 August 2025

Hi Shaun,

We have updated both Apple Silicon Macs and Intel Macs to 15.6 and everything is working fine.

On some few occasions macOS updates have caused driver issues, in these cases reinstalling the driver is necessary.

Please open Finder, find the Pegasus DEXT Driver Installer App...

and drag it into the trash. This will uninstall the DEXT driver.

Then reboot and install the driver from the downloaded installer again.

Shaun Farmer posted this 12 August 2025

Thank you for the response, but I have done this multiple times already.

To be extra fair, I did this again after your post and it stayed online for about 60 minutes before disappearing again.

After my initial post I moved the services and Pegasus3 to an M1 MacBook Pro running macOS 15.2 and it did not crash/disappear once during the two days.

I'm assuming it is something with the new Thunderbolt 5 ports on the Mac Studio, newer version of macOS 15.x or both.

R P posted this 14 August 2025

Hi Shaun,

I do not have an M4 Mac Mini Max to test this in the lab.

But I will report the issue.

I have had no issues with my M1 Mac Mini, which is similar to your M1 Macbook Pro in this regard.

Shaun Farmer posted this 15 August 2025

Thank you. The machine having the issue is a Mac Studio, but as long as it has Thunderbolt 5 bolts the testing should be comparable.

I can install whatever logging profiles and generate a sysdiagnose as needed.

R P posted this 15 August 2025

Hi Shaun,

If you can generate and save a macOS System Report that might help. Please zip it and attach it to your post.

Shaun Farmer posted this 15 August 2025

Hi Shaun,

If you can generate and save a macOS System Report that might help. Please zip it and attach it to your post.

Those reports can contain detail that should not be publicly downloadable.
Do you have an option that's more secure?

Shaun Farmer posted this 3 weeks ago

This drive has become unsable under Tahoe on all my devices. Any large file transfer cause the DEXT to crash like before. The drive is years old and deperately needs an update. I have about 60TB of current and archived work that I can no longer access.

Frank Bosma posted this 3 weeks ago

Hey Shaun,

can you create a service report in the promise utility and attach it here please ?

Thanks,
Frank

Shaun Farmer posted this 3 weeks ago

Per your request

Attached Files

R P posted this 3 weeks ago

Hi Shaun,

Since last August I have had the opportunity to debug three Pegasuses with panic issues, one on my own lab.

In all three cases it was not a driver issue.

In the first case, the issue was root caused to a bad drive. The SMART data was enought to diagnose the drive and when we removed it from the enclosure the panics stopped. After rebuilding to a new drive everything worked perfectly.

In the second case I thought it was also a bad drive but a binary search for a bad drive found nothing, finally we rebooted with all the drives and the problem went away. Most likely there was corrosion or contamination on the SATA connector contacts and unseating and reseating the drives wiped the contacts.

The third issue was also a bad drive.

In your case the SMART data shows all drives to be in good shape. I would suggest powering down the Pegasus, removing the power cable, unseat all the drives, plug the power cable back in again and boot the Pegasus without drives. It should not panic booted this way. Then power it down again, unplug the power cable, reseat the drives and plug in the power cable and boot the storage. Hopefully the panic situation is solved.

 

Shaun Farmer posted this 2 weeks ago

I followed your recommendations and went a little further. While I did not see any obvious oxidation/corrosion/contamination, I did use a special contact cleaner and brush I have on hand for PCB repair work. All the drive & chassis connectors were thoroughly cleaned, allowed to dry and reassmebled.

I was able to mount and use the array to copy multiple TBs of data with an issue. Unfortunately, there was a lot of corruption so a majority was lost, but some of the most important projects were recovered.

Thank you for the unorthodox recommendation, which I would not have considered, that allowed me to recover and reuse the system.

Search
Categories
Close