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.
Generated Oct 3, 2026, 12:35:03 AM
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.
Create a reproducible minimal test script that suspends and resumes (sleep then wake) while capturing dmesg to demonstrate the failure consistently for maintainers.
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.
Try booting a live USB with a newer/mainline kernel to test whether a newer kernel/driver combo fixes resume behavior (non-destructive trial).
If possible, contact Broadcom or distribution maintainers with logs and repro steps; escalate to kernel driver maintainers if a kernel regression is suspected. If hardware replacement is an option and issue persists across kernel versions, test with a USB Wi‑Fi dongle as a definitive hardware bypass.