## Summary

On a Dell XPS Panther Lake system using Omarchy's `linux-ptl` kernel, sustained outbound Wi-Fi traffic can trigger a sudden unreclaimable kernel `skbuff_*` slab allocation storm. The system OOMs user/session processes, then `iwlwifi` reports a stuck queue and firmware restart.

This is probably below Omarchy itself (`iwlwifi`/`iwlmld`/mac80211 or firmware), but I'm filing here first because the affected kernel package is Omarchy's `linux-ptl` package and I don't know where its PKGBUILD/backport patchset lives.

## Environment

- Machine: Dell XPS 14 DA14260 / Intel Panther Lake platform
- Kernel: `7.0.3-arch1-2-ptl`
- Omarchy package: `omarchy/linux-ptl 7.0.3.arch1-2`
- Package description: `The Linux with Panther Lake hardware backports (SDCA audio, PSR2, Panel Replay SU) kernel and modules`
- Wi-Fi interface: `wlan0`
- Wi-Fi driver path: `iwlwifi` / `iwlmld` / mac80211
- Firmware loaded: `101.6e695a70.0 sc-a0-wh-b0-c101.ucode`
- Swap: disabled

## Observed Failure

The OOMs are dominated by unreclaimable kernel networking slab caches, not userspace RSS and not ZFS ARC:

- `skbuff_small_head`
- `skbuff_head_cache`

These grow from around 1 MiB to tens of GiB within seconds. OOM victims are incidental user/session processes such as `elephant`, `Hyprland`, `walker`, `direnv`, or browsers with modest RSS.

A representative OOM log showed:

```text
skbuff_small_head   41901327KB
skbuff_head_cache   15236888KB
```

The monitor later captured an even larger wave:

```text
2026-05-15T14:19:58+12:00 skb_total_kb=52530722
skbuff_small_head approx_kb=38558814
skbuff_head_cache approx_kb=14021415
SUnreclaim: 53910012 kB
MemAvailable: 3181328 kB

2026-05-15T14:19:59+12:00 skb_total_kb=57028760
```

## Dmesg Extracts

OOM starts from normal userspace allocation, but memory is consumed by unreclaimable kernel slab:

```text
[16742.772329] direnv invoked oom-killer: gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO|__GFP_COMP), order=0, oom_score_adj=200
[16742.772337] CPU: 11 UID: 1000 PID: 1270644 Comm: direnv Tainted: P        W  OE       7.0.3-arch1-2-ptl #1 PREEMPT(full)  f3ae37c960e57db84cb617efedd3a8d4d21c121c
[16742.772341] Hardware name: Dell Inc. XPS 14 DA14260/0TVXV7, BIOS 1.3.1 02/12/2026
[16742.772440] active_file:933 inactive_file:2211 isolated_file:0
[16742.772440] unevictable:16815 dirty:205 writeback:0
[16742.772440] slab_reclaimable:165600 slab_unreclaimable:14643334
[16742.772488] Free swap  = 0kB
[16742.772489] Total swap = 0kB
[16742.772492] Unreclaimable slab info:
[16742.773367] skbuff_small_head   41901327KB   41901346KB
[16742.773368] skbuff_head_cache   15236888KB   15236896KB
```

The OOM victim is incidental and has modest RSS compared to the slab explosion:

```text
[16742.776431] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=user.slice,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/[email protected]/app.slice/elephant.service,task=elephant,pid=1111128,uid=1000
[16742.776482] Out of memory: Killed process 1111128 (elephant) total-vm:3558056kB, anon-rss:124720kB, file-rss:112kB, shmem-rss:0kB, UID:1000 pgtables:1056kB, oom_score_adj:200
```

Soft lockup follows in networking softirq with the `iwlwifi` / `iwlmld` TX segmentation path:

```text
[16756.650915] watchdog: BUG: soft lockup - CPU#10 stuck for 26s! [swapper/10:0]
[16756.650920]     #1:   0% system, 100% softirq,   1% hardirq,   0% idle
[16756.651040]  <IRQ>
[16756.651060]  __alloc_skb+0x137/0x330
[16756.651062]  skb_segment+0x359/0xfc0
[16756.651064]  tcp_gso_segment+0x11f/0x620
[16756.651068]  inet_gso_segment+0x166/0x440
[16756.651074]  skb_mac_gso_segment+0xaa/0x120
[16756.651077]  __skb_gso_segment+0x79/0x1c0
[16756.651079]  iwl_tx_tso_segment+0x32a/0x380 [iwlwifi 104e89be23eb81f4b2ec5ccb16068af6563b64ab]
[16756.651099]  iwl_mld_tx_skb+0x3cf/0x400 [iwlmld 44d6238a3aa52c20c847e5ff73e8a3e3c4be7b16]
[16756.651112]  iwl_mld_tx_from_txq+0x94/0x130 [iwlmld 44d6238a3aa52c20c847e5ff73e8a3e3c4be7b16]
[16756.651120]  ieee80211_queue_skb+0x52e/0x720 [mac80211 d4ecc517b267e3a2bc077b5f4b26fbf4f3802507]
[16756.651176]  __ieee80211_xmit_fast+0x84c/0xb10 [mac80211 d4ecc517b267e3a2bc077b5f4b26fbf4f3802507]
[16756.651222]  __ieee80211_subif_start_xmit+0x328/0x420 [mac80211 d4ecc517b267e3a2bc077b5f4b26fbf4f3802507]
[16756.651309]  dev_hard_start_xmit+0x57/0x1e0
[16756.651311]  sch_direct_xmit+0x159/0x380
[16756.651313]  __qdisc_run+0x82/0x640
[16756.651318]  net_tx_action+0x12e/0x350
[16756.651319]  handle_softirqs+0xe8/0x2c0
[16756.651324]  </IRQ>
```

A second OOM repeats with the same slab signature:

```text
[16760.606943] bluetoothd invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=0
[16760.607131] slab_reclaimable:164998 slab_unreclaimable:14726572
[16760.608107] skbuff_small_head   42229054KB   42229787KB
[16760.608121] skbuff_head_cache   15355977KB   15356636KB
[16760.618019] Out of memory: Killed process 1111127 (walker) total-vm:1770516kB, anon-rss:21156kB, file-rss:3028kB, shmem-rss:44kB, UID:1000 pgtables:528kB, oom_score_adj:200
```

The iwlwifi queue/firmware failure happens after the OOM storm:

```text
[16766.429631] iwlwifi 0000:00:14.3: Queue 2 is stuck 3713 3720
[16766.435843] iwlwifi 0000:00:14.3: Microcode SW error detected. Restarting 0x0.
[16766.435893] iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 6
[16766.435895] iwlwifi 0000:00:14.3: Loaded firmware version: 101.6e695a70.0 sc-a0-wh-b0-c101.ucode
[16766.435896] iwlwifi 0000:00:14.3: 0x00000084 | NMI_INTERRUPT_UNKNOWN
[16766.436009] iwlwifi 0000:00:14.3: Transport status: 0x0000004A, valid: 7
[16766.436010] iwlwifi 0000:00:14.3: 0x20000066 | NMI_INTERRUPT_HOST
```

## Ordering

The important ordering is:

1. Huge `skbuff_*` allocation storm.
2. OOM/session fallout.
3. `iwlwifi` stuck queue / firmware restart.

The later driver messages include:

```text
iwlwifi 0000:00:14.3: Queue 2 is stuck 3713 3720
iwlwifi 0000:00:14.3: Microcode SW error detected. Restarting 0x0.
iwlwifi 0000:00:14.3: Loaded firmware version: 101.6e695a70.0 sc-a0-wh-b0-c101.ucode
```

## Kernel Stack Evidence

A watchdog soft lockup happened in networking softirq/TX segmentation path, with the stack including:

```text
__alloc_skb
skb_segment
tcp_gso_segment
inet_gso_segment
skb_mac_gso_segment
__skb_gso_segment
iwl_tx_tso_segment [iwlwifi]
iwl_mld_tx_skb [iwlmld]
iwl_mld_tx_from_txq [iwlmld]
ieee80211_queue_skb [mac80211]
__ieee80211_xmit_fast [mac80211]
dev_hard_start_xmit
sch_direct_xmit
net_tx_action
handle_softirqs
```

The watchdog reported `100% softirq`, which fits a TX-path networking storm rather than a userspace memory leak.

## Trigger Pattern

The strongest common factor is sustained outbound Wi-Fi TX on `wlan0`:

- ZFS backup / SSH traffic to another LAN host (`192.168.33.60`)
- AWS/HTTPS uploads
- ISO build/download traffic can amplify reproduction

## Negative Mitigation Result

A `tc` egress rate limit did not prevent the issue:

```bash
sudo tc qdisc replace dev wlan0 root tbf rate 100mbit burst 32kbit latency 400ms
```

The monitor confirmed the `tbf` qdisc was active during later spikes:

```text
qdisc tbf 8001: root refcnt 2 rate 100Mbit burst 4Kb lat 400ms
```

Despite that, `skbuff_*` still peaked around 57 GiB.

## Offload State

`ethtool -k wlan0` showed these enabled at the time:

```text
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
```

Given the stack is in `iwl_tx_tso_segment` / GSO/TSO segmentation, disabling these is the next local test if supported.

## Might not be the place, happy to move if this is not the right place to file this

- Where is the `linux-ptl` PKGBUILD/backport patchset hosted?
- Is there a newer PTL kernel package or firmware recommendation for Panther Lake Wi-Fi?
- Should this be escalated directly to Arch kernel or Linux wireless with the `linux-ptl` patch context?

I can provide the full `dmesg` excerpt and monitor logs if useful.