We have a group of Macs that mount SMB shares over 10 GbE with jumbo frames (MTU 9000). Since late June, they have been kernel panicking several times a day with the same assertion:
panic(cpu N caller ...): assertion failed: m->m_flags & M_PKTHDR, file: .../xnu/bsd/kern/uipc_mbuf.c, line: 4839 @uipc_socket.c:8260
Panicked thread: dlil_input_en0
Last started kext: com.apple.filesystems.smbfs 6.0.1
Environment
- Clients: Mac Studio (M1 Max and M1 Ultra) and Mac Pro (2019, Intel with T2), using the built-in 10GBASE-T at MTU 9000
- macOS 26.5.1 (25F80), 26.6.2 (25G83) and 26.7 (25G229); it panics on all three
- Servers: Samba-based NAS, SMB 3.1.1, signing on, encryption off
- Filed as FB24912731
What we've found
- It still panics with our third-party EDR fully uninstalled.
- The Mac that panics needs an active SMB session. A Mac left on the network without a share mounted stayed up through several events that took down the others.
- Panics are often simultaneous across machines: two to six Macs, with different hardware and different macOS builds, within the same minute.
- It doesn't need sustained heavy throughput. Some panics came within minutes of reconnecting, during light editing.
- Setting
kern.skywalk.flowswitch.rx_agg_tcp_host=0did not help. - The switch and server links stay up, and spanning tree doesn't change during these events. Only the Macs' ports drop.
- In one server-side capture, the client stopped sending within about 0.2 ms of receiving a READ response made of 8948-byte frames. That fits the panicked thread being dlil_input.
Two existing threads look related
- Kernel panic using Vagrant synced folders via NFS beginning with macOS 15.4 (FB17853906). A DTS reply there said the issue is in kernel mbuf management and that SMB "is very likely to experience a similar panic."
- Incorrect packet handling in SMBClient MacOS 26, which describes a race in SMBClient under heavy load above about 10 Gbps.
Questions
- Is this the same underlying issue as FB17853906, and is a fix planned for macOS 26? Our 2019 Mac Pros can't move to a later major release.
- Is there a known workaround, such as a sysctl, an nsmb.conf option, or a change to MTU or offload settings?
- Is there logging or a diagnostic we can leave enabled to capture more state at panic time? We can't reproduce this on demand, but between several machines we see it multiple times a day.
We can provide full panic reports, sysdiagnoses, and packet captures from both client and server sides.