Skip to content

Add workaround for BCM4377b Wi-Fi failing after lid close #688

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
herzj-tcd wants to merge 2 commits into
base: master
Choose a base branch
from
+67 −0
Open

Add workaround for BCM4377b Wi-Fi failing after lid close #688

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a500a03
Update wifi-bluetooth.md
herzj-tcd Feb 20, 2026
851813e
Add BCM4377b lid close Wi-Fi fix
herzj-tcd Feb 20, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions docs/distributions/ubuntu/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,3 +34,10 @@ sudo apt install pipewire pipewire-audio-client-libraries libpipewire-0.3-module
# How do I upgrade my kernel

Follow [these](https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel?tab=readme-ov-file#using-the-apt-repo) instructions.

# Why does Wi-Fi stop working after closing the lid?

On some T2 Macs with the BCM4377b Wi-Fi chip (e.g. MacBookAir9,1), the `brcmfmac` driver
fails to handle suspend correctly, leaving the Wi-Fi firmware unresponsive after resume.
See the [Wi-Fi and Bluetooth guide](../../guides/wifi-bluetooth.md#wi-fi-not-working-after-lid-close-bcm4377b)
for the fix.
60 changes: 60 additions & 0 deletions docs/guides/wifi-bluetooth.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -237,3 +237,63 @@ Dec 24 22:34:20 hostname kernel: brcmfmac: brcmf_c_process_txcap_blob: TxCap blo
Dec 24 22:34:20 hostname kernel: brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4377/4 wl0: Jul 16 2021 18:25:13 version 16.20.328.0.3.6.105 FWID 01-30be2b3a
Dec 24 22:34:20 hostname kernel: brcmfmac 0000:01:00.0 wlp1s0f0: renamed from wlan0
```
## Wi-Fi not working after lid close (BCM4377b)

!!! Bug "Affected hardware: MacBookAir9,1 and possibly other T2 Macs with BCM4377b"
On some T2 Macs, the `brcmfmac` driver fails to enter D3 power state during suspend,
causing the Wi-Fi firmware to become unresponsive after the lid is opened. This is a
known Broadcom firmware bug [reported to Broadcom](https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/issues)
with no upstream fix available. The workaround below resolves it.
Comment on lines +245 to +246
Copy link
Contributor

@sharpenedblade sharpenedblade Mar 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you used the wrong link here


The failure manifests as `brcmf_pcie_pm_enter_D3: Timeout on response for entering D3 substate`
in the kernel log, followed by repeated `Timeout on response for query command` errors after resume.
Wi-Fi and Bluetooth are dead until reboot.

A further complication is that `mem_sleep_default=deep` is set in the kernel command line by
default on t2linux kernels, which overrides any sleep configuration set elsewhere. This needs
to be changed to `s2idle`.

### Fix

**Step 1:** Change the kernel command line to use `s2idle` instead of `deep` sleep. Edit
`/etc/default/grub` and change `mem_sleep_default=deep` to `mem_sleep_default=s2idle` in
`GRUB_CMDLINE_LINUX_DEFAULT`, then update GRUB:
```bash
sudo update-grub
```
Copy link
Contributor

@sharpenedblade sharpenedblade Mar 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not the correct way to change kernel parameters on all distros. On Fedora you should use grubby --args="mem_sleep_default=s2idle" --update-kernel=ALL, and some people with arch use systemd-boot which means you have to edit /etc/kernel/cmdline and then regenerate the BLS files.


**Step 2:** Force `s2idle` in the systemd sleep config to ensure it isn't overridden:
```bash
sudo mkdir -p /etc/systemd/sleep.conf.d
sudo tee /etc/systemd/sleep.conf.d/t2-sleep.conf << EOF
[Sleep]
SuspendState=freeze
EOF
```

**Step 3:** Create a post-resume script to rebind the Wi-Fi driver, which reloads the firmware after every resume:
```bash
sudo tee /usr/lib/systemd/system-sleep/brcmfmac-rebind.sh << 'EOF'
#!/bin/bash
case "$1" in
post)
sleep 1
echo "0000:73:00.0" > /sys/bus/pci/drivers/brcmfmac/unbind
sleep 2
echo "0000:73:00.0" > /sys/bus/pci/drivers/brcmfmac/bind
sleep 2
;;
esac
EOF
sudo chmod +x /usr/lib/systemd/system-sleep/brcmfmac-rebind.sh
```

!!! Warning "Do not unload the module pre-suspend"
Unloading `brcmfmac` before suspend (e.g. with `modprobe -r`) causes a hard crash on
Copy link
Member

@AdityaGarg8 AdityaGarg8 Mar 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is weird. I've seen many people simply unloading and suspending.

T2 hardware. The rebind script above only runs **after** resume and is safe.

After rebooting, verify that `s2idle` is now the active sleep state:
```bash
cat /sys/power/mem_sleep
# Should show: [s2idle] deep
```