Promise Pegasus2 R6 (Thunderbolt 2) causes Controller Reset/Kernel Panic on Write in Proxmox VE 8 (Mac Mini 2012)

[favonion]

Hardware:

• Host: Mac Mini Late 2012 (Server), i7-3720QM, 16GB RAM.
• DAS: Promise Pegasus2 R6 (6-Bay).
• Connection: Thunderbolt 2 (Native).
• Drives: 6x Mixed HDDs (4TB WD Red, 2TB Toshiba). Configured as JBOD/Pass-Thru.
• OS: Proxmox VE 8.1 (Debian 12 Bookworm), Kernel 6.8.x.

The Issue:I am attempting to use the Pegasus2 R6 as a JBOD enclosure for a MergerFS pool. The drives are visible in lsblk, but any write operation (mkfs.ext4, wipefs, dd) triggers a controller handshake failure, causing the specific drive device to go offline or the entire host to hang/freeze. Read operations seem stable initially, but writes kill the connection immediately.

Symptoms & Logs:

• lsblk correctly lists all 6 drives (e.g., sdb through sdg) upon boot.
• boltctl shows the device as authorized.
• Attempting mkfs.ext4 /dev/sdb results in No such device or address immediately after execution.
• dmesg output during the crash:
  
  sd 0:0:1:0: [sdb] tag#639 aborting command<br>scsi host0: resetting host<br>stex(0000:09:00.0): no signature after handshake frame<br>stex(0000:09:00.0): resetting: handshake failed<br>sd 0:0:1:0: Device offlined - not ready after error recovery<br>
• Initial boot showed PCI resource allocation errors, fixed via GRUB parameters (see below).

Troubleshooting / Steps Taken:

1. Hardware Verification (macOS):
   
   • Booted external macOS Catalina via USB.
   • Installed Promise Utility.
   • Cleared all Arrays and Spare definitions.
   • Set all 6 Physical Drives to PassThru mode.
   • Result: Hardware is functional. Successfully partitioned and formatted all 6 drives (GPT/ExFAT) using macOS Disk Utility. No I/O errors under macOS.
2. Proxmox/Linux Configuration:
   
   • Installed bolt, mergerfs, fuse3.
   • Authorized UUID via boltctl enroll.
   • Added pci=realloc to GRUB_CMDLINE_LINUX_DEFAULT to fix initial "bridge window" allocation errors.
   • Driver loaded: stex: Promise SuperTrak EX Driver version: 6.02.0000.01.
3. Attempted Fixes for Write Instability:
   
   • Tried disabling MSI/AER via pci=nomsi pci=noaer (Result: update-grub hangs because os-prober chokes on the unstable drives).
   • Forced PCI rescan (echo 1 &gt; /sys/bus/pci/rescan) brings drives back after crash, but they die again on next write.
   • Tried mkfs.ext4 -E nodiscard to rule out TRIM/Discard issues. Failed.
   • Tried wiping signatures via dd if=/dev/zero .... Failed (I/O error).

Hypothesis:The mainline Linux stex driver appears incompatible with the Pegasus2 firmware or Thunderbolt tunneling behavior under load (specifically writes), causing the controller to hang during handshakes. It works perfectly in macOS, ruling out cables/backplane.

Question:Has anyone successfully stabilized a Pegasus2 R6 on modern Linux kernels (6.x)? Are there specific kernel parameters or stex module options required to prevent the handshake timeouts?

 

[macsinspace]

Hi,
I hit the same family of problems with a Pegasus2 R8 (and a Pegasus32 R8) on Proxmox VE 9.2 (kernel 7.0.14-pve), and fiiinally got it stable.
There were actually several separate faults stacked on top of each other, so posting what fixed each one in case it helps.

Setup: MSI Cubi NUC 1M (Intel Thunderbolt 4) → Pegasus32 R8 (USB-C/TB3) → Apple TB3→TB2 adapter → Pegasus2 R8.
The Pegasus2 would not link at all on the NUC's own TB4 ports on the day I tested it, but has in the past... really unstable.
But daisy-chained off the Pegasus32's second TB3 port it works.

1. firmware not operational / no signature after handshake frame during probe
This was the Pegasus2 controller firmware. Newer firmware doesn't complete the stex handshake; after downgrading to 5.04.0000.36 (done on a Mac with Promise Utility 4.06) it probes fine. You can check your version on Linux without any tools; the Pegasus2 volume's SCSI revision is the firmware:

grep . /sys/class/scsi_device/*/device/{model,rev}   # Pegasus2 R8 > rev 0504

2. Hot-plugging the Pegasus2 crashed the OTHER Pegasus
Without enough hot-plug PCI space, the kernel moved the running Pegasus32's memory window to fit the new device, and its controller died (firmware not operational on the working unit). Fixed with:

pci=realloc pci=hpiosize=0 pci=hpmemsize=128M

3. Any drop/reset hangs the whole host (needs a hard reboot)
This is a genuine bug in the mainline stex driver (unchanged since 2017). When the controller disappears (cable pulled, enclosure powers off) or a reset handshake fails, the SCSI layer livelocks in sd_sync_cache / stex_remove and you get hung-task traces every 2 minutes. Causes:
- stex_queuecommand sets cmd->result = DID_NO_CONNECT without << 16, so a "device gone" completion looks like a bogus status byte and triggers error recovery on hardware that no longer exists.
- After a failed reset the driver sets MU_STATE_FAILED, and queuecommand then returns SCSI_MLQUEUE_HOST_BUSY forever. Commands requeue endlessly. sd_remove never finishes.
- The reset path waits ~55 s for a handshake even when the PCI device is already gone.
- With two Pegasus units, the reboot notifier is registered per controller (notifier callback stex_halt already registered WARN at probe).

I wrote a small patch (~50 lines) that fixes the shift, fails I/O immediately (DID_NO_CONNECT) when the controller is gone or failed, skips the reset and handshake when pci_device_is_present() says the device is gone, and registers the notifier once at module init.
Built as a DKMS module (6.02.0000.01-hp2). If you're on Secure Boot you'll need to enroll the DKMS MOK key.
After it, pulling the cable or a failed reset drops just that unit, and plugging back in re-attaches without a reboot. Patch attached.
To be clear: it doesn't fix the write-triggered reset in the first post; it just stops that from taking the host down with it.

Result: with firmware 5.04, the PCI params and the patched driver, the Pegasus2 did ~1 TB of checksum-verified fio writes (sequential ~700 MB/s, random 4K–1M, buffered) with zero stex errors, resets or Thunderbolt drops. I couldn't reproduce the "resets on write" behaviour from the first post on this setup, so I suspect firmware and/or the host's Thunderbolt controller (native TB1/2 on the 2012 Mini vs a TB3 chip here), not the driver's write path.

I'm currently putting together a small "pegasusctl" to read and write to my Peusus devices and set drives up, read error states etc based on Promise's Windows cliib.exe which I got running under Wine!
Promise's Windows cliib.exe (from the Pegasus2 Windows utility) runs under Wine with a small shim DLL that translates its one Windows-only ioctl to the stex Linux equivalent. It can list and locate drives, view arrays, SMART, etc. It also showed me my array had been running degraded with no redundancy, which you can't see otherwise on Linux.
But requiring Wine is a bit much... so linux native it is.


Craig.