[SOLVED] Extremely Slow Wireless on Macbook Pro

fosskers · 2012-04-19 13:19:45

SOLVED (Hopefully forever.)

Problem: The b43 and bcma kernel modules do not get along. You'd never know this with kernels up to 3.2.14, as bcma is not automatically loaded and it is not needed with b43. For recent kernels however, it is. It in turn destroys wireless internet speeds.

Solution: The broadcom-wl driver. It used to be portrayed in the Wiki as being something to avoid, but that has changed recently. It offers a better connection and much faster speeds, but can take a little bit more effort to set up. Just a bit.

Broadcom-wl Installation and Setup
1. Install broadcom-wl from the AUR.
2. Uninstall b43-firmware if it's installed.
3. Note what broadcom-wl has put into /etc/modprobe.d. These blacklistings will ensure no interference from other kernel modules. Also make sure you're not blacklisting `wl` or its friends, if you have been.
4. Don't reboot yet. Go to /sys/class/net and use the command:

udevadm info -a -p /sys/class/net/<yourdevice> | grep address | tr [A-Z] [a-z]

(of course replacing <yourdevice> with the names of your interfaces - probably eth0 and wlan0) This will tell you their MAC addresses. Write these down!
5. Go to /etc/udev/rules.d/ and create a file called 10-network.rules. We are going to make custom udev rules so that our interfaces are matched to their proper names at boot time. Here is a template:

SUBSYSTEM=="net", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="net0"
SUBSYSTEM=="net", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="wifi0"

Enter the MAC addresses (in lower case!) and give them names in the NAME field. Apparently it's a good idea to choose new interface names, different from the default eth0 and wlan0. My file looks like this:

SUBSYSTEM=="net", ATTR{address}=="58:b0:35:f6:45:0c", NAME="wired0"
SUBSYSTEM=="net", ATTR{address}=="f8:1e:df:ea:99:17", NAME="wifi0"

6. Go change ANYTHING that had references to the old interface names. I had to change my rc.conf, as well as settings in my wicd preferences so that it knows what names to look for.
7. Rebuild your kernel image with

sudo mkinitcpio -p linux

(you might not have to do this, but it couldn't hurt.)
8. Save this page. Yes, the html. This is so that you still know what to do in case of problems and no internet.
9. Reboot and enjoy your restored wireless internet.

---- ORIGINAL POST ----

Seems everybody and their grandmothers are having internet problems since 3.3.

On a Macbook Pro, kernel 3.3.2-1.
Here is my problem: http://i.imgur.com/AcqLM.jpg

I made that image before checking the forums, but now that I've looked around I suspect the kernel.
Put up with it until 3.3.3? Or regress?

Last edited by fosskers (2012-08-31 13:00:28)

fosskers · 2012-04-21 09:07:03

Downgraded kernel to 3.2.14 and nvidia drivers too, and now everything is back to normal.

And how it's done (for nvidia people, and also assuming you don't clear your package caches):
cd /var/cache/pacman/pkg/
sudo pacman -U linux-3.2.14-1-x86_64.pkg.tar.xz nvidia-295.33-1-x86_64.pkg.tar.xz nvidia-utils-295.33-1-x86_64.pkg.tar.xz

Note that nvidia-295.33-2 has the 3.3 kernel as a dependency, but 295.33-1 does not. Be careful.
Also, you may have dependency conflicts other than nvidia. I did not. Good luck!

Further edit:
Once you've done this, dive into your pacman.conf and make sure fill out the IgnorePkg field, something like this:
IgnorePkg = linux nvidia nvidia-utils

Last edited by fosskers (2012-04-21 12:29:59)

fosskers · 2012-07-14 12:33:00

Reopened and bumped this on 2012 July 14.

After months of waiting and holding back my kernel I decided to try again to see if the problem would fix itself.
We are now at kernel 3.4.4-2 and still nothing.

I am running:
* MacBook Pro 7,1
* Kernel 3.4.4-2
* b43-firmware 5.100.138-2
* My wireless card is the `BCM4322`.

MODULES field in rc.conf looks like:
MODULES=(b43 acpi-cpufreq cpufreq_ondemand coretemp)

DAEMONS looks like:
DAEMONS=(hwclock syslog-ng !network !dhcpcd !networkmanager netfs crond dbus alsa laptop-mode wicd acpid)

I even rebuilt the b43 firmware after the kernel upgrade, but that didn't help anything. I can't _seriously_ be the only MBP user to experience this slow-as-molasses wireless speed, can I?

Last edited by fosskers (2012-07-14 12:44:18)

tulius · 2012-07-14 15:55:51

similar regression here. (since kernel 3.4)

same configuration: (BCM4322, MacBook Pro 7,1)

b43 still works great when downgrading to 3.3.8, but you can't stay there forever..

fosskers · 2012-07-14 22:49:57

Thank you. At least now I know I'm not alone.

I was never able to move off of 3.2.14... this is curious. Why was your b43 still in good shape up to 3.3.8, but not now all of a sudden?
You'd think the kernel update process itself is at fault, which is often the case, but even rebuilding b43 after a kernel update doesn't help the problem.
I don't want to stay on 3.2.14 forever because that lags back the nvidia drivers as well.

Take a look at my MODULES line.
I did an experiment by removing `b43` from there and restarting. It didn't affect my connection or speed at all.
Could the kernel be loading some different module?

Last edited by fosskers (2012-07-15 00:55:32)

fosskers · 2012-07-15 01:01:38

A ha! dmesg is polluted by the following:

[ 128.113396] b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)
[ 128.319415] ADDRCONF(NETDEV_UP): wlan0: link is not ready

fosskers · 2012-07-15 01:13:17

Alright... this is odd. This randomly showed up in dmesg:

[ 135.980625] wlan0: authenticate with 4c:e6:76:74:ee:fb
[ 135.980836] wlan0: send auth to 4c:e6:76:74:ee:fb (try 1/3)
[ 135.982351] wlan0: authenticated
[ 135.983382] wlan0: associate with 4c:e6:76:74:ee:fb (try 1/3)
[ 135.988556] wlan0: RX AssocResp from 4c:e6:76:74:ee:fb (capab=0x431 status=0 aid=1)
[ 135.988566] wlan0: associated
[ 135.990383] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

...and now suddenly internet speeds are back to normal.

...and are destroyed again when this pops up.

[ 9548.183401] ACPI: EC: GPE storm detected, transactions will use polling mode

Some digging around has shown that people have losing bluetooth and their wireless connection (performance) because of this since 2008.

Last edited by fosskers (2012-07-15 01:49:01)

fosskers · 2012-07-15 13:48:20

After various tests I'm beginning to think that the `GPE storm` is not the culprit.

However, I have noticed that the kernel seems to be loading modules regardless of my rc.conf.
Usually my MODULES line looks like:

MODULES=(b43 acpi-cpufreq cpufreq_ondemand coretemp)

and a quite check to `lsmod` confirms that they're loaded.
However, reducing the MODULES line to:

MODULES=()

And giving everything a shutdown, then restart, I find that the loaded modules are exactly the same.
Is this normal?
Then, could the kernel being loading an incorrect module for my wireless?

tulius · 2012-07-15 15:49:44

fosskers wrote:

However, I have noticed that the kernel seems to be loading modules regardless of my rc.conf.
Usually my MODULES line looks like:
MODULES=(b43 acpi-cpufreq cpufreq_ondemand coretemp)
and a quite check to `lsmod` confirms that they're loaded.
However, reducing the MODULES line to:
MODULES=()
And giving everything a shutdown, then restart, I find that the loaded modules are exactly the same.
Is this normal?

The wiki says: "MODULES: Modules to load at boot-up in addition to auto-loaded ones"
So I guess udev autoloads b43 anyway.

Then, could the kernel being loading an incorrect module for my wireless?

According to this page: http://linuxwireless.org/en/users/Drivers/b43, b43 is the right one.
You can also try the proprietary broadcom-wl driver, but I used it about a year ago and it was quite annoying (lost connection every 5 minutes or so)

I also noticed that GPE storm thing, but it appears quite random and I don't think it affects my wireless performance.

A ha! dmesg is polluted by the following:
[ 128.113396] b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)
[ 128.319415] ADDRCONF(NETDEV_UP): wlan0: link is not ready

My dmesg contains that only once.

After all, the wireless performance varies a lot and I find it difficult to tell if something helps or the improvements are completely random.
For example, I just noticed the connection got better when disabling bluetooth - but this may be a random, too...
Does anyone know a more reliable way to test wireless performance? (better than ping, downloading files with wget and surf the web to see how it feels)

ewaller · 2012-07-15 17:21:34

tulius wrote:

For example, I just noticed the connection got better when disabling bluetooth - but this may be a random, too...

It isn't. Some bluetooth implementations cause havoc with 802.11. Can you try an 802.11 N network rather than a G ?

Does anyone know a more reliable way to test wireless performance? (better than ping, downloading files with wget and surf the web to see how it feels)

I usually look at the link quality and the number of dropped packets as an indicator:

ewaller@odin:~ 1001 %cat /proc/net/wireless 
Inter-| sta-|   Quality        |   Discarded packets               | Missed | WE
 face | tus | link level noise |  nwid  crypt   frag  retry   misc | beacon | 22
 wlan0: 0000   52.  -58.  -256        0      0      0      4    612        0
ewaller@odin:~ 1002 %

If these numbers look reasonable, the problem could be at the higher protocol layers.

fosskers · 2012-07-15 23:08:30

@tullius How did you personally disable bluetooth?

I've been testing my speeds with this website: http://www.speedtest.net/

@ewaller
Here's the output from my /proc/net/wireless:

Inter-| sta-| Quality | Discarded packets | Missed | WE
face | tus | link level noise | nwid crypt frag retry misc | beacon | 22
wlan0: 0000 70. -33. -256 0 0 0 92 2 0

retry = 92 = bad?

Output from same thing when I regress the kernel back to 3.2.14:

Inter-| sta-| Quality | Discarded packets | Missed | WE
face | tus | link level noise | nwid crypt frag retry misc | beacon | 22
wlan0: 0000 66. -44. -256 0 0 0 2 27 0

Last edited by fosskers (2012-07-15 23:32:11)

tulius · 2012-07-16 07:11:27

@fosskers:
Sry, I just told KDE to disable it

@all:
/proc/net/wireless looks pretty bad:

Inter-| sta-| Quality | Discarded packets | Missed | WE
face | tus | link level noise | nwid crypt frag retry misc | beacon | 22
wlan0: 0000 70. -38. -256 0 0 0 514 2 0

After measuring this, I just got kicked out (again):

[ 1072.839997] ieee80211 phy0: wlan0: No probe response from AP 4c:e6:76:22:4f:33 after 500ms, disconnecting.

Now it even refuses to reconnect. This is a full "enable wireless - try connect - fail"-cycle:

[ 1698.359901] b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)
[ 1698.560136] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 1721.394168] wlan0: authenticate with 4c:e6:76:22:4f:33
[ 1721.420074] wlan0: send auth to 4c:e6:76:22:4f:33 (try 1/3)
[ 1721.422002] wlan0: authenticated
[ 1721.423411] wlan0: associate with 4c:e6:76:22:4f:33 (try 1/3)
[ 1721.426883] wlan0: RX AssocResp from 4c:e6:76:22:4f:33 (capab=0x411 status=0 aid=1)
[ 1721.426886] wlan0: associated
[ 1721.428216] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 1729.470178] wlan0: deauthenticated from 4c:e6:76:22:4f:33 (Reason: 2)
[ 1729.473907] cfg80211: Calling CRDA to update world regulatory domain [...]
[ 1730.674444] wlan0: authenticate with 4c:e6:76:22:4f:33
[ 1730.700199] wlan0: send auth to 4c:e6:76:22:4f:33 (try 1/3)
[ 1730.702446] wlan0: authenticated
[ 1730.703423] wlan0: associate with 4c:e6:76:22:4f:33 (try 1/3)
[ 1730.706988] wlan0: RX AssocResp from 4c:e6:76:22:4f:33 (capab=0x411 status=0 aid=1)
[ 1730.706997] wlan0: associated
[ 1738.740963] wlan0: deauthenticated from 4c:e6:76:22:4f:33 (Reason: 2)
[ 1738.748937] cfg80211: Calling CRDA to update world regulatory domain [...]
[ 1739.954181] wlan0: authenticate with 4c:e6:76:22:4f:33
[ 1739.980222] wlan0: send auth to 4c:e6:76:22:4f:33 (try 1/3)
[ 1739.982773] wlan0: authenticated
[ 1739.983401] wlan0: associate with 4c:e6:76:22:4f:33 (try 1/3)
[ 1739.987077] wlan0: RX AssocResp from 4c:e6:76:22:4f:33 (capab=0x411 status=0 aid=1)
[ 1739.987086] wlan0: associated
[ 1746.001760] wlan0: deauthenticating from 4c:e6:76:22:4f:33 by local choice (reason=3)
[ 1746.015596] cfg80211: Calling CRDA to update world regulatory domain [...]

Sometimes it does not find any networks at all (iwlist wlan0 scan shows nothing)

Again, everything was fine with kernel < 3.4. (downgrading helps).
Maybe I should start compiling some kernels myself and search the regression with a bisection...

fosskers · 2012-07-16 12:16:50

Holy mother of dropped packets!

Also, I've been quite curious as to why the kernel versions that kill our respective wirelesses are different.

Wilco · 2012-07-16 12:45:38

You should blakclist brcmsmac, b43, ssb and bcma. Then modprobe wl in /etc/rc.local (because there is a chance of a kernel panic if brcmsmac loads wl or the other way around).

b43 combined with the some of the "official" kernel modules, like brcmsmac, ssb or bcma, create these kinds of problems.

tulius · 2012-07-16 13:53:54

Wilco wrote:

You should blakclist brcmsmac, b43, ssb and bcma. Then modprobe wl in /etc/rc.local (because there is a chance of a kernel panic if brcmsmac loads wl or the other way around).
b43 combined with the some of the "official" kernel modules, like brcmsmac, ssb or bcma, create these kinds of problems.

Are you sure using broadcom-wl is a good idea? The wiki says:

This driver is more likely to cause problems than to resolve them. Most of the problems reported by users on Broadcom chips are caused by this driver. Using this is HIGHLY NOT recommended. Before you even think of trying out this one, make sure to try the other drivers first.

I used broadcom-wl some time ago, and it was horrible.
That was the reason why I switched to b43 in the first place - which worked well until kernel 3.4

fosskers · 2012-07-17 08:08:03

Maybe he doesn't mean broadcom-wl specifically....
But still, the wiki does make it very clear that broadcom-wl is bad, and I feel safer heeding its advice.

zenlord · 2012-07-17 13:12:33

I have a MBP 5.5 and have been using broadcom-wl since day 1. My laptop still has not blown up and wireless connections are usually excellent. The only place giving me headaches is my own home that's been built with lots of iron and concrete in the walls and ceilings...

fosskers · 2012-07-17 22:11:44

Well, guess I'll blacklist the hell out of everything and give broadcom-wl a shot. Worse comes to worse I just switch back. It _is_ the proprietary driver, after all. You'd think it would work.

tulius · 2012-07-18 12:53:02

After installing broadcom-wl the wireless performance is pretty good. However, it tends to loose connection every 5 minutes or so.
This is difficult to debug, as dmesg contains nothing, and the line networkmanager drops isn't very helpful either:

Jul 18 14:46:49 localhost NetworkManager[482]: <info> (eth0): supplicant interface state: disconnected -> scanning

fosskers · 2012-07-18 22:17:52

Did you do all the blacklisting you had to?

tulius · 2012-07-19 07:47:10

sure: /etc/modprobe.d/broadcom-wl.conf:

blacklist b43
blacklist bcma
blacklist ssb
blacklist brmcsmac

fosskers · 2012-07-19 13:40:36

Tried out broadcom-wl, blacklisted everything, but on a power-down and reboot it wouldn't detect wireless networks. The "interface flipping" might have been occurring as well.

Back on b43, and every once and a while I get normal speeds. After a bit of use it slows right down though.
Maybe it's power management after all?

ikatson · 2012-08-14 06:17:39

Same bug here. MacBookPro + broadcom 4322 [14e4:432b]

I cannot check if the speed is ok on kernels older than 3.4, but I just notice with speedtest.net that the speed tends to jump from 15mbps (how it should be) to 1mbps (only on linux).

Unfortunately, most of the time the speed is low. I do not have any clueful kernel messages though.

fosskers · 2012-08-31 09:39:44

Thank you for reporting this. As with tulius, it's good to know we're not alone with this problem.

ikatson · 2012-08-31 10:07:53

broadcom-wl works flawlessly though, without any disconnects, I'm using it for a while already. Just needed to updated some udev rules, cause the wireless interface appeared as eth1 instead of wlan0.

Arch Linux

#1 2012-04-19 13:19:45

[SOLVED] Extremely Slow Wireless on Macbook Pro

#2 2012-04-21 09:07:03

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#3 2012-07-14 12:33:00

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#4 2012-07-14 15:55:51

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#5 2012-07-14 22:49:57

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#6 2012-07-15 01:01:38

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#7 2012-07-15 01:13:17

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#8 2012-07-15 13:48:20

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#9 2012-07-15 15:49:44

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#10 2012-07-15 17:21:34

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#11 2012-07-15 23:08:30

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#12 2012-07-16 07:11:27

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#13 2012-07-16 12:16:50

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#14 2012-07-16 12:45:38

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#15 2012-07-16 13:53:54

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#16 2012-07-17 08:08:03

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#17 2012-07-17 13:12:33

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#18 2012-07-17 22:11:44

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#19 2012-07-18 12:53:02

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#20 2012-07-18 22:17:52

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#21 2012-07-19 07:47:10

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#22 2012-07-19 13:40:36

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#23 2012-08-14 06:17:39

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#24 2012-08-31 09:39:44

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

#25 2012-08-31 10:07:53

Re: [SOLVED] Extremely Slow Wireless on Macbook Pro

Board footer