macOS 15.5 + SANLink3 F2 + Xsan: FC Write Timeout and c3timeout Errors

  • 183 Views
  • Last Post 3 days ago
terry wang posted this 4 weeks ago

Hi all,

 

We’ve recently encountered a serious Fibre Channel I/O timeout issue when using macOS 15.5 with a Promise SANLink3 F2 adapter in an Xsan environment.

 

### Environment:

- macOS Sequoia 15.5 (latest public release)

- Promise SANLink3 F2 (dual-port 16Gb FC)

- Apple Xsan with MDC + metadata LUNs + data LUNs on FC storage

- Brocade FC switch (with zoning configured)

- Multipath (MPIO) enabled

 

### Problem Description:

On macOS 15.5 systems connected to Xsan via SANLink3 F2, we consistently observe **write I/O timeouts**, followed by **abort and chip timeout errors**. These show up in the system log as:

 

This corresponds to failed write operations (SCSI op 0x2A) and eventually causes the mount point to hang or file system-level errors in Xsan volumes.

 

### Diagnostics Performed:

- `log show --last 5m | grep sanlink` confirms repeated timeouts.

- FC switch shows **extremely high c3timeout counts** on port 32 (~89,900).

- However, port 32 is **not physically connected** or zoned — it’s unused.

- No CRC, sync loss, or PCS errors were found on other active FC ports (32–47).

- Disabling port 32 on the switch improves system behavior temporarily.

- Suspected residual MPIO paths pointing to nonexistent targets may be involved.

 

### Attempts to Resolve:

- Re-seated SFPs and fibre cables

- Reinstalled latest Promise SANLink drivers (still no official macOS 15.5 support)

- Disabled unused FC ports at the switch level

- Verified zoning is correct for active LUNs

- Tried removing/rebuilding volume metadata in Xsan

 

### Key Question:

Has anyone else seen **write timeouts or c3timeout-related errors** with macOS 15.5 and SANLink3 F2 in an Xsan setup? Could this be due to compatibility issues with SANLink drivers on macOS 15.5?

 

Any insight or suggestions would be much appreciated!

 

---

 

Thanks in advance,

 

Order By: Standard | Latest | Votes
R P posted this 4 weeks ago

Hi Terry,

- FC switch shows **extremely high c3timeout counts** on port 32 (~89,900).
- However, port 32 is **not physically connected** or zoned — it’s unused.

These are errors on the Switch, and on an unconnected port, I'm not seeing any connection between this error and the SanLink.

If the errors were on the port(s) connected to the SanLink, that would be one thing, but that is not the case.

Is there something I'm missing?

terry wang posted this 4 weeks ago

Port 32 was previously connected to one of the controllers on our SAN storage system. However, that particular storage controller had failed, and although the Fibre Channel cable was still physically connected, the port continued to report errors.

I’ve just removed the fibre cable from port 32, so we expect that specific issue to be resolved now.

 

However, the core problem still persists — when using AJA System Test Lite to test read/write performance, we consistently encounter the following kernel errors:

kernel: (SANLink-FC) [SL] driver timeout tgt:17 lun:2 ctrl:2 op 2a ...

kernel: (SANLink-FC) [SL] abort xxxx

 

kernel: (SANLink-FC) [SL] chip timeout ...

At the same time, AJA System Test Lite halts completely during the test.

R P posted this 3 weeks ago

Hi Terry,

1. I responded to your email to the support alias and it bounced.

2. Can you clarify whether your Mac is Intel or Apple Silicon, I don't see that mentioned anywhere.

R P posted this 3 weeks ago

Hi Terry,

According to the dev team, you'll need to change some settings in macOS.

1. Boot into Recovery Mode

For Intel Macs press and hold Command + R
For Apple Silicon (M1/M2/M3/M4), press and hold the power button until “Loading startup options” appears.

2. Disable SIP (System Integrity Protection)

Once in the macOS Utilities window, go to the menu bar and open Utilities > Terminal.

In the Terminal window, type:

csrutil disable

Press Enter.

3. Enable Permissive Security Options (Only for Apple Silicon M1/M2/M3/M4)

From the top menu bar, choose Utilities > Startup Security Utility.

Select your system drive (usually named “Macintosh HD”).

Click Security Policy

       Choose the radio button: Permissive Security.
       Under that, check both of the following options

4. Reboot the Mac

 

 

terry wang posted this 3 weeks ago

Thank you for your reply!
I'm using a Mac Studio M3 Ultra (2025).
I've already set csrutil disable and adjusted the Security Policy,
but I'm still getting this error.

R P posted this 3 weeks ago

Hi Terry,

The dev team is seeing if they can dig a bit deeper.

But it seems to me that the chip timeout might be a hardware issue.

- Kernel logs with “driver timeout”, “chip timeout”, and “abort failed” errors

And with hardware in mind, is there a possibility that the power brick might have gotten weak? In the unlikely event that you have a another power brick of the same type, you could see if things work with the other brick.  

 

R P posted this 2 weeks ago

Hi Terry,

The dev team has prepared a new beta driver compiled with Sequioa 15.

But I can't post a beta here.

If you can send an email to the support alias from an address that can be responded to I will forward the driver.

Either that or open a support ticket and I an upload the driver to the ticket.

R P posted this 3 days ago

 

Status Update: Terry has been emailed the beta driver.

Search
Categories
Close