Broadcom STA/WL driver drops Wi‑Fi association after suspend on Linux laptop

Environment

Dell XPS 13 developer laptop running Ubuntu 22.04 with Linux kernel 5.15 and Broadcom BCM4360 chipset using the proprietary broadcom-sta (wl) driver; NetworkManager managing connections; laptop suspend/resume via S3.

Symptoms

After resuming from suspend, Wi‑Fi shows as 'connected' in NetworkManager but no traffic is sent/received. Repeated suspend/resume cycles increase frequency. Manually disabling/enabling the Wi‑Fi device via nmcli sometimes restores connectivity, but often the device needs a full reboot.

Observations

dmesg after resume contains repeated lines from the wl driver: 'wl: failed to allocate skb' and 'wl: bus: error -5'. iwconfig lists the wireless interface but iwlist scan returns no networks until the module is reloaded. Unloading and reloading the wl kernel module (rmmod wl; modprobe wl) restores functionality for that session. Using the opensource brcmfmac driver is not viable with this chipset in current kernel. No kernel oopses; only driver error messages.

Already attempted

Updated broadcom-sta package to latest from apt and built the wl module against current kernel headers; problem persisted. Tested disabling power management via NetworkManager.conf (wifi.powersave = 2) with no durable improvement. Created a systemd service to reload the wl module on suspend/resume as a temporary workaround; this restores connectivity but is disruptive (network reset on every resume).

Question

What diagnostic steps and reversible mitigations can confirm whether the issue is a driver race during PCI bus power-up after S3 vs. a firmware/hardware problem, and how can I minimize disruption without needing a full reboot each resume?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Proprietary Broadcom wl driver does not properly handle device reset or PCI power state transitions on resume, leaving firmware in an unusable state. 85%

PCIe/USB bus power sequencing on this laptop model interacts poorly with the wl driver, causing temporary resource allocation failures after resume. 70%

Firmware on the Wi‑Fi chip has a corner-case bug that requires a hard reset (power-cycle) which module reload attempts to emulate partially. 30%

Summary

Driver error messages on resume and the fact that module unload/reload fixes the problem indicate the wl driver fails to reinitialize the device after the kernel hands it back following suspend. This is likely a driver/kernel power-management interaction or PCI power state handling bug rather than a user-space NetworkManager issue. The module reload workaround reinforces a kernel-driver-level root cause.

Suggested Fixes

Diagnostic step 1

Capture full dmesg and kernel logs before and after suspend/resume to identify precise error codes and timestamps. Keep logs for vendor/maintainer bug reports.

Diagnostic step 2

Create a reproducible minimal test script that suspends and resumes (sleep then wake) while capturing dmesg to demonstrate the failure consistently for maintainers.

Diagnostic step 3

Continue using the reversible module-reload workaround via a systemd sleep hook (create /lib/systemd/system-sleep/wl-reload script that rmmods and modprobes the wl module), noting this is a workaround and not a fix.