v1.8 kernel panic (M_PKTHDR assertion) on Tahoe 26.4 with VT-d DISABLED in BIOS

[adriandleon]

Summary

Reproducible kernel panic with AppleIGC v1.8 on macOS Tahoe 26.4 (25E246). The crash occurs despite VT-d being disabled in BIOS throughout all tests — ruling out AppleVTD as the cause for this configuration. This differs from the reports in #24 and #28 where disabling VT-d was the fix.

Hardware

Component	Details
CPU	Intel Core i7-12700K (Alder Lake)
Motherboard	Gigabyte Z690 Aorus Pro
NIC	Intel I225-V (onboard)
RAM	64GB DDR5
GPU	AMD Radeon RX 580 8GB
Bootloader	OpenCore (Hackintosh)

Software

• macOS: Tahoe 26.4 (build 25E246)
• Kernel: Darwin 25.4.0 xnu-12377.101.15~1/RELEASE_X86_64
• AppleIGC: v1.8 (CFBundleVersion 1.8d1)
• SMBIOS: MacPro7,1

Kernel Panic

The crash is 100% reproducible and always hits the same location:

panic(cpu 0 caller 0xffffff80017acb5c): assertion failed: m->m_flags & M_PKTHDR,
file: uipc_mbuf.c, line: 4839 @uipc_socket.c:8256

Panicked task: pid 0: kernel_task

Backtrace (CPU 0):
0xffffff80441bfda0 : 0xffffff800179d64d
0xffffff80441bfe90 : 0xffffff80017acb5c   <- assertion
0xffffff80441bfea0 : 0xffffff80011ef957   <- uipc_socket.c:8256
0xffffff80441bff50 : 0xffffff80011efc96
0xffffff80441bffa0 : 0xffffff8000eeb19e

Boot args: alcid=12 -wegnoigpu e1000=0 dk.e1000=0 igc-no-tso

The kernel offset of the calling function (0x8B164D from kernel base) is identical across all panics, confirming a deterministic code path.

Key Finding: VT-d Was Already Disabled

This is the critical difference from other reports:

• VT-d was DISABLED in BIOS during every single crash
• DisableIoMapper: true and DisableIoMapperMapping: true were set in OpenCore throughout
• AppleVTD was confirmed not loaded via ioreg -c AppleVTD and kmutil showloaded

$ ioreg -c AppleVTD   → no AppleVTD entry
$ kmutil showloaded | grep -i vtd   → no output

The workaround reported in #24 (disable VT-d / DisableIoMapper) does not apply here because VT-d was never active. The panic is caused by something else in the RX path on this hardware/OS combination.

What Was Tried

Attempt	Result
Remove ncl=131072 boot arg	Still panics
igc-no-tso boot arg	Still panics
DisableIoMapper: true + DisableIoMapperMapping: true	Still panics
VT-d disabled in BIOS (was already off)	Still panics
Enabled VT-d in BIOS (with DisableIoMapper still true)	Not tested — VT-d confirmed irrelevant

Analysis

The panic is an M_PKTHDR assertion failure in the BSD socket layer's receive path (uipc_socket.c:8256). The socket layer receives an mbuf from the driver without the M_PKTHDR flag set, which Tahoe 26.4's XNU no longer tolerates at that code path.

This appears to be a regression in the RX path introduced (or not fully fixed) by the v1.8 "Improved RX error handling to safely recover from packet buffer copy failures" change. The mbuf_copyback() path may be returning a partially-formed mbuf without M_PKTHDR in a code path that is not gated by VT-d presence.

Additional Context

• The panic only affects Tahoe 26.4. The same hardware/config was stable on earlier macOS versions.
• The panic occurs in kernel_task (not a user process), triggered by background network activity.
• The system runs stably for 15–45 minutes before panicking, suggesting it is triggered by a specific network condition rather than immediately on boot.
• Windows 11 on the same hardware with the same NIC never crashes.

Reference

Related issues: #24, #28, #34

[luchina-gabriel]

Same thing here with me, in some setups that have I226 the same KP occurs.

The strangest thing is that I have another identical setup, but the problem doesn't occur there.

It only happens in Tahoe, in Sonoma/Sequoia versions the problem doesn't occur.

[jzrodriguez98]

I'm having the problem in Tahoe where my 225V Ethernet card does not work if VTD is enabled. This problem was not present in Sequoia / Sonoma.

[jzrodriguez98]

@SongXiaoXi this issue already fixed with a recent commit?