I am running Mageia 2 on a Macbook Pro 8,2. This has the following broadcom wireless chipset: 03:00.0 Network controller: Broadcom Corporation BCM4331 802.11a/b/g/n (rev 02) Full support for this chipset was added to the b43 driver in the 3.3 kernel. It requires installing b43-fwcutter and extracting the newest firmware. I did extract the latest firmware and the b43 driver works fine and loads the ucode29_mimo.fw firmware. The b43 driver works fine. However, after suspend to RAM and wakeup, the wireless fails to reconnect. One workaround I have found is that if I unload the b43 module resume, Mageia 2 then reloads it again immediately (weird, don't understand why that's the case?) and now I can connect to my wireless access points and get an IP address. So, the workaround is: Wake up from sleep Run "modprobe -r b43" Then netapplet reconnects to my wireless The same thing happens with all Wireless APs I have used, so I don't think the problem is related to any specific AP. As a more convenient workaround so that b43 reloads after sleep, I created the following file /etc/pm/sleep.d/99sleep-script #!/bin/sh case "$1" in suspend|freeze) ;; resume|thaw) /sbin/modprobe -r b43 ;; *) ;; esac and now b43 reloads automatically after sleep. I can also just create a file /etc/pm/config.d/modules with the following content: SUSPEND_MODULES="b43" and that works too without the 99sleep-script. But, two things are wrong here: 1. I should not HAVE to reload b43 after waking from sleep? 2. Why does "/sbin/modprobe -r b43" BOTH unload the b43 driver and then reload it? I would think unloading it should unload it and not load it again automatically.
Created attachment 2415 [details] Log of unloading b43 driver. Note the lack of evidence of unloading the driver!
CC: (none) => mageia, tmbSeverity: normal => major
Can you try kernel-3.3.8-1.mga2 from updates_testing. It has a fix for this.
Status: NEW => ASSIGNED
Andy could you please test with the new kernel and leave a comment either here or on bug 6914. Thanks!
Let's hope the update fixed the bug, as we didn't hear back from the reporter.
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVEDCC: (none) => stormi