Repository navigation
MacBook5,1 / BCM4322: document wl-first boot workaround for Wi-Fi failures after reboot #10994
Description
What happened
On a MacBook5,1 with an Apple Broadcom BCM4322 adapter, Omarchy uses the
in-kernel b43 driver. Networks are visible, but after a warm reboot the
adapter intermittently fails to remain connected. A full shutdown/power-on
usually restores it.
Hardware:
03:00.0 Network controller: Broadcom BCM4322 802.11a/b/g/n [14e4:432b] (rev 01)
Subsystem: Apple Inc. AirPort Extreme [106b:008d]
Machine: Apple MacBook5,1
Observed with Omarchy 4.0.3-1 and Linux 7.2.3-arch1-3. In a failed boot,
b43 reports:
Fatal DMA error: 0x00000400
This device does not support DMA on your system. It will now be switched to PIO.
PREV_AUTH_NOT_VALID
Forcing b43 to PIO from the initramfs (also with nohwcrypt=1) removes the
DMA error but does not prevent disassociation. PCI reset, PCI remove/rescan,
suspend/resume, and disabling ASPM did not solve the warm-reboot failure.
Workaround verified on this machine
Installing the official Arch package broadcom-wl-dkms and ensuring wl is
the first driver to initialize the adapter fixed the functional problem in
the initial test series:
/etc/mkinitcpio.conf.d/wifi-wl-first.conf:
MODULES+=(wl)
The package-provided /usr/lib/modprobe.d/broadcom-wl-dkms.conf blacklists
b43, ssb, and the other conflicting Broadcom modules. After rebuilding
the UKI, the result was:
- one successful cold boot;
- three consecutive successful warm reboots;
- automatic WPA connection and DHCP on every boot;
- Internet traffic explicitly tested over the Wi-Fi interface with 0% loss;
- no
Fatal DMA errororScan_results error (-22).
Loading wl only after b43 had already initialized the card produced
Scan_results error (-22) and misleadingly looked like a wl failure. This
same driver-order behavior is documented for the identical PCI ID in Debian
bug #1088231:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088231
Suggested Omarchy change
install/hardware/fix-bcm43xx.sh currently handles BCM4360 (14e4:43a0)
and BCM4331 (14e4:4331) by installing broadcom-wl-dkms, but not BCM4322
(14e4:432b).
Could BCM4322 support be documented or offered as an explicit opt-in hardware
workaround, including rebuilding the initramfs/UKI so wl initializes the
adapter before b43? I would avoid enabling it unconditionally based only on
the PCI ID: Broadcom behavior varies by Mac model, and issue #7593 documents
a BCM4331 machine where wl causes hard freezes.
Important caveat
This is a functional workaround, not an endorsement of the proprietary
driver. On Linux 7.2.3, wl emits warnings that it is unmaintained and
incompatible with kernel security mitigations, plus Unpatched return thunk
and a FORTIFY field-spanning write warning in
wl_cfg80211_hybrid.c. Any Omarchy integration should present that tradeoff
clearly and preferably remain opt-in.
Activity
omarchybot commentedon Oct 11, 2026
Read against
quattroat be7c7bf. Your description of the installer is accurate:install/hardware/fix-bcm43xx.shinstallsbroadcom-wl-dkmsonly for14e4:43a0(BCM4360) and14e4:4331(BCM4331), and no install step or migration does anything for14e4:432b, so a BCM4322 is left to the in-kernelb43.Nothing was run for this: a worker VM has no BCM4322, so the warm-reboot failure and the
wlworkaround cannot be reproduced or tested here. Your logs are the only evidence of either, and nothing in Omarchy's own code explainsb43losing the association after a warm reboot, so this is a driver/hardware problem rather than a defect in Omarchy's code.On the workaround itself:
MODULES+=(wl)in a drop-in fits how Omarchy builds the initramfs. Its hooks includemodconf(etc/mkinitcpio.conf.d/00-omarchy-hooks.conf:34), which copies/usr/lib/modprobe.dinto the image, so the package's blacklist ofb43andssbis in effect from early boot, andsudo limine-mkinitcpiois the rebuild Omarchy uses itself. Two caveats for anyone copying it: the blacklist is system-wide rather than scoped to this chip, and removingbroadcom-wl-dkmslater means removing that drop-in too and rebuilding.Related, not duplicates:
b43-firmwarefor this same chip and keepsb43. It does not fix this report: your failing boots already haveb43running with firmware, and the failure is the association dropping after a warm reboot. The two only conflict if both become the automatic default for14e4:432b.wlhard-freezes a 2011 MacBook Air whereb43works. It is why switching drivers by PCI ID alone is risky, as you noted.wlpath.Whether to offer
wlfor BCM4322, opt-in or documented, with the security warnings it carries on current kernels, is a decision about how these machines boot, so no fix has been drafted. It is waiting on the maintainer.Reviewed by Claude Opus 5.5, with a second opinion from Codex Medium, which agreed on the installer, #11311 and the initramfs interaction; its independence is not guaranteed, since the reviewer can read this session's notes.