### System details

Dell XPS 14 DA14260, Omarchy 4

### What's wrong?

# Dell XPS 14 DA14260: closing lid causes severe Wi-Fi TX stall while docked

## Description

On a Dell XPS 14 DA14260 (Panther Lake / Intel BE211), physically closing the laptop lid while using an external USB-C monitor causes Wi-Fi connectivity to become effectively unusable.

The laptop remains fully awake, the external display continues working, Wi-Fi remains associated, RSSI and reported link rates remain good, but even latency to the local gateway increases from a few milliseconds to hundreds or thousands of milliseconds.

Opening the lid immediately restores normal connectivity.

This appears to be a TX-side `iwlwifi`/`iwlmld` queue stall associated specifically with the physical lid state.

The problem appears to have been introduced around the migration to Omarchy Quattro. Before Quattro, Wi-Fi performance on this machine was already worse than expected, but clamshell operation worked and I could use the laptop normally with the lid closed.

## Hardware

* Dell XPS 14 DA14260
* Panther Lake
* Intel Wi-Fi 7 BE211 320 MHz
* PCI ID: `8086:e440`
* Subsystem: `8086:4110`
* External monitor connected over USB-C
* USB-C also provides external power

BIOS was originally `1.2.1`. I updated to Dell BIOS `1.9.0` during troubleshooting. This made no difference.

## Current software

```text
Omarchy: 4.0.2-1
Kernel: 7.1.8-arch1-2-ptl
linux-ptl: 7.1.8.arch1-2
linux-firmware-intel: 20260810-2
NetworkManager: 1.58.1-1
wpa_supplicant: 2.12-1
```

Wi-Fi:

```text
Driver: iwlwifi
Operation module: iwlmld
Firmware: 102.07fca168.0 sc-a0-wh-b0-c102
Interface: wlp0s20f3
```

The C106 firmware is installed on disk as part of the current Arch firmware package, but Linux 7.1 only selects up to C102, so I have not attempted to force C106 onto the 7.1 driver.

## Reproduction

1. Connect the laptop to an external USB-C display/power.
2. Connect to Wi-Fi.
3. Start:

```bash
ping <local-gateway>
```

4. With lid open, latency is normal.
5. Physically close the laptop lid.
6. External monitor remains active and the machine remains usable.
7. Within seconds, local Wi-Fi latency increases dramatically.
8. Open the laptop lid.
9. Wi-Fi latency immediately returns to normal.

This is reproducible.

Example gateway ping during one test:

```text
10.0 ms
10.1 ms
11.0 ms
942 ms
1238 ms
198 ms
428 ms
510 ms
430 ms
1486 ms
1079 ms
77.2 ms
750 ms
9.53 ms
9.76 ms
9.48 ms
```

The high-latency section corresponds to the lid being physically closed.

## TX queue evidence

I monitored the Intel driver's debugfs TX queue state during reproduction.

With the lid open, hardware queue 3 remains drained:

```text
read=9141 write=9141 backlog=0
...
read=9159 write=9159 backlog=0
```

After physically closing the lid, the queue progressively falls behind:

```text
read=9257 write=9268 backlog=11
read=9258 write=9271 backlog=13
read=9270 write=9286 backlog=16
read=9279 write=9298 backlog=19
read=9291 write=9310 backlog=19
```

During this period:

```text
stopped=0
frozen=0
need_update=0
```

Immediately after reopening the lid, the queue drains again:

```text
read=9865 write=9865
```

This correlates very closely with the local gateway latency.

I have also previously seen the kernel report:

```text
iwlwifi 0000:00:14.3: fail to flush all tx fifo queues Q 3
iwlwifi 0000:00:14.3: Queue 3 is stuck 6199 6206
```

Those particular messages were not timestamp-correlated with the controlled lid experiment, but appear consistent with the TX queue behaviour observed directly.

## What does NOT change when the problem occurs

During the lid-closed failure:

* Wi-Fi remains associated.
* RSSI remains approximately `-63/-64 dBm`.
* Reported TX rate remains around `864.6 Mbit/s` / 160 MHz HE.
* `tx retries=0`.
* `tx failed=0`.
* `beacon loss=0`.
* rfkill remains off.
* PCI device remains in `D0`.
* PCI runtime status remains `active`.
* PCI runtime control is `on`.
* PCI `runtime_suspended_time=0`.
* External power remains online.
* TAS remains enabled.
* Both antennas remain ACTIVE.
* SAR/regulatory limits do not change.
* No firmware HW/SW error is reported.
* No kernel suspend/resume event occurs.

`systemd-logind` only reports:

```text
Lid closed.
Lid opened.
```

There is no system suspend.

## Omarchy clamshell handling does not reproduce it by itself

I also tested Omarchy's clamshell monitor handling while leaving the physical lid open.

I forced `omarchy-hyprland-monitor-clamshell` into the clamshell state so that the internal display was disabled/reconfigured without physically closing the lid.

This did **not** reproduce the Wi-Fi failure.

Physically closing the lid immediately does.

Therefore disabling the internal display / running the Omarchy clamshell monitor script by itself does not appear sufficient to trigger the problem.

## Power-saving tests already performed

Normal Wi-Fi power saving is disabled:

```text
/sys/module/iwlwifi/parameters/power_save = N
NetworkManager wifi.powersave=2
```

I also tested:

```text
iwlmld power_scheme=1
```

The problem still occurs.

I also tested with Wi-Fi 7/EHT disabled:

```text
iwlwifi disable_11be=Y
```

The problem still occurs.

Changing these settings did not resolve the lid-triggered behaviour.

## Quattro migration context

The issue appears to have started around my migration to Omarchy Quattro on 2026-08-16.

That upgrade changed several relevant components at approximately the same time:

```text
linux-ptl:
7.1.3.arch1-1 -> 7.1.8.arch1-2

linux-firmware-intel:
20260622-1 -> 20260810-1

systemd:
261.1-1 -> 261.2-1

Hyprland:
0.56.0-2 -> 0.56.2-1
```

Quattro also changed the Wi-Fi userspace configuration.

Before migration I was using:

```text
iwd 3.12
```

During migration:

```text
wpa_supplicant 2.12 installed
NetworkManager 1.58.0 installed
iwd removed
```

I have not yet switched NetworkManager back to the iwd backend because I wanted to report the current stock Quattro behaviour before making further changes.

## Additional observation

A normal interactive shell can also appear to hang while the lid is closed — commands may execute but the configured prompt does not return.

However, a clean:

```bash
bash --noprofile --norc
```

continues working normally with the lid closed.

Background processes also continue running normally.

Therefore the machine itself is not frozen. The shell symptom appears secondary and may be caused by a network-dependent shell/prompt hook.

## BIOS

The machine initially had:

```text
Dell BIOS 1.2.1
```

I updated it to the current Dell BIOS:

```text
1.9.0
```

The lid/Wi-Fi behaviour is completely unchanged.

## Related issues

This may be related to #7056 because this is the same XPS 14 DA14260 / BE211 / `iwlwifi` + `iwlmld` platform and the current 7.1 PTL kernel is limited to C102 firmware.

It may also be relevant to #5827, which documented a different TX-side `iwlwifi`/`iwlmld` failure on the same DA14260 platform.

I have not found an existing issue describing this exact physical-lid-triggered TX queue stall.

## Summary

The most interesting observation is that physical lid closure corresponds with Intel hardware TX queue 3 progressively ceasing to drain normally, despite:

* the device remaining in PCI D0,
* no system suspend,
* good RSSI,
* high reported PHY rates,
* no MAC retries/failures,
* no rfkill,
* no regulatory/TAS change,
* and the Wi-Fi association remaining established.

Opening the lid causes the queue to drain and connectivity immediately recovers.

Because the same laptop previously worked in clamshell mode before the Quattro-era changes, this looks like a software/firmware/platform regression rather than an inherent limitation of using the DA14260 with its lid closed.