14e4:432b Regression in wireless performance when on battery power

1. Steps I took that caused me to encounter the problem:
disconnect the A/C power cable from the laptop, laptop then runs on battery power

2. expected behavior:
same network speed as on A/C power

3. behaviour actually encoutered:
very slow network speed

network speed on A/C power:
bheinsius@bheinsius-Latitude-E6400:~$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=1.62 ms
64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=1.29 ms
64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=1.29 ms
64 bytes from 192.168.0.1: icmp_req=4 ttl=64 time=1.42 ms

network speed on battery power:
bheinsius@bheinsius-Latitude-E6400:~$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=43.4 ms
64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=63.9 ms
64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=85.6 ms
64 bytes from 192.168.0.1: icmp_req=4 ttl=64 time=108 ms

workaround from bug 651008:
-- begin quote
(This will not fix all problems for all: see comment 24.)
Disable the power saving measures implemented by /usr/lib/pm-utils/power.d/wireless.
To disable them do:
sudo touch /etc/pm/power.d/wireless

You now should have an empty file named wireless without the executable bit set in /etc/pm/power.d.
Check with:
ls -lh /etc/pm/power.d/
You should see a file like this:
-rw-r--r-- 1 root root 0 2010-12-31 18:53 wireless

Reference: man pm-powersave
-- end quote

Bart Heinsius, please execute the following command, as it will automatically gather debugging information, in a terminal:
apport-collect 991232

As well, if you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.

Please let us know your results. Thanks in advance.

apport-collect 991232 gives errors:

Waiting to hear from Launchpad about your decision...
Created new window in existing browser session.
No packages found matching linux.
ERROR: hook /usr/share/apport/general-hooks/ubuntu.py crashed:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/apport/report.py", line 718, in add_hooks_info
    symb['add_info'](self, ui)
  File "/usr/share/apport/general-hooks/ubuntu.py", line 45, in add_info
    match_error_messages(report)
  File "/usr/share/apport/general-hooks/ubuntu.py", line 129, in match_error_messages
    if report['ProblemType'] == 'Package':
  File "/usr/lib/python2.7/UserDict.py", line 23, in __getitem__
    raise KeyError(key)
KeyError: 'ProblemType'
Traceback (most recent call last):
  File "/usr/share/apport/apport-gtk", line 499, in <lambda>
    GLib.idle_add(lambda: self.collect_info(on_finished=self.ui_update_view))
  File "/usr/lib/python2.7/dist-packages/apport/ui.py", line 867, in collect_info
    icthread.exc_raise()
  File "/usr/lib/python2.7/dist-packages/apport/REThread.py", line 34, in run
    self._retval = self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.7/dist-packages/apport/ui.py", line 111, in thread_collect_info
    if report['ProblemType'] == 'Crash' and \
  File "/usr/lib/python2.7/UserDict.py", line 23, in __getitem__
    raise KeyError(key)
KeyError: 'ProblemType'

I installed the latest upstream kernel available.
after boot there's no wireless networking.
so could not test if problem is resolved in latest upstream kernel available.

will add the tag: 'kernel-unable-to-test-upstream'.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 991232

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Christopher M. Penalver, what you wrote is unclear to me.

1. what to enter in Summary and Further Information fields?
2. then mark as duplicate of this bug (991232)?

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

On my newish Acer AS5750 I enabled ACPI so that I could enable screen dimming (since it wasn't working as expected). Then once unplugged from the wall socket Wifi latency increased and then quit completely after approx. one minute (BCM43227). Makes portability pretty useless!! Luckily I found the following blog post: http://uselessuseofcat.com/?p=67

jbeezo, please do not toggle this bug without clearly documenting the rationale for the change.

penalvch, very sorry. Just trying to bring more eyes to the problem.
I just noticed that it's already a known issue: http://wiki.debian.org/wl

@Bart,

Were you able to test the mainline kernel as suggested in comment #4? The latest mainline kernel can be downloaded from:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/

@Joseph Salisbury:

I tried but with no success.
I installed the mainline kernel and accompanying headers but the broadcom
driver won't load without the bcmwl-kernel-source (re-)installed but that
doesn't work because:

Module build for the currently running kernel was skipped since the
> kernel source for this kernel does not seem to be installed.

-Bart

On Mon, May 21, 2012 at 3:32 PM, Joseph Salisbury <
<email address hidden>> wrote:

> @Bart,
>
> Were you able to test the mainline kernel as suggested in comment #4?
> The latest mainline kernel can be downloaded from:
>
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-precise/
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/991232
>
> Title:
> 14e4:432b Regression in wireless performance when on battery power
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/991232/+subscriptions
>

@Joseph Salisbury:

wrt mainline kernel, turned out I missed the one of the kernel header packages.
retrying I get:

bheinsius@bheinsius-Latitude-E6400:~$ sudo dpkg -i bcmwl-kernel-source_5.100.82.38+bdcom-0ubuntu6.1_i386.deb
...
Building initial module for 3.4.0-030400-generic-pae
ERROR (dkms apport): kernel package linux-headers-3.4.0-030400-generic-pae is not supported
Error! Bad return status for module build on kernel: 3.4.0-030400-generic-pae (i686)
Consult /var/lib/dkms/bcmwl/5.100.82.38+bdcom/build/make.log for more information.
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-3.4.0-030400-generic-pae
bheinsius@bheinsius-Latitude-E6400:~$

and

bheinsius@bheinsius-Latitude-E6400:~$ more /var/lib/dkms/bcmwl/5.100.82.38+bdcom/build/make.log
DKMS make.log for bcmwl-5.100.82.38+bdcom for kernel 3.4.0-030400-generic-pae (i686)
Mon May 21 16:55:06 CEST 2012
make: Entering directory `/usr/src/linux-headers-3.4.0-030400-generic-pae'
  LD /var/lib/dkms/bcmwl/5.100.82.38+bdcom/build/built-in.o
  CC [M] /var/lib/dkms/bcmwl/5.100.82.38+bdcom/build/src/shared/linux_osl.o
  CC [M] /var/lib/dkms/bcmwl/5.100.82.38+bdcom/build/src/wl/sys/wl_linux.o
/var/lib/dkms/bcmwl/5.100.82.38+bdcom/build/src/wl/sys/wl_linux.c:43:24: fatal error: asm/system.h: No such file or directory
compilation terminated.
make[1]: *** [/var/lib/dkms/bcmwl/5.100.82.38+bdcom/build/src/wl/sys/wl_linux.o] Error 1
make: *** [_module_/var/lib/dkms/bcmwl/5.100.82.38+bdcom/build] Error 2
make: Leaving directory `/usr/src/linux-headers-3.4.0-030400-generic-pae'
bheinsius@bheinsius-Latitude-E6400:~$

@Bart

You mention this is a regression.l Can you test the latest v3.0 kernel to confirm this bug does not exist there? The v3.0 kernel can be downloaded from:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.0.31-oneiric/

@Joseph Salisbury:

not sure this is a regression, the original bug report was
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/651008 which expired
because it was reported on maverick for which support had expired. the
problem still existed in 12.04, Christopher M. Penalver (penalvch) asked me
to file a new report for 12.04, I copied the subject from that bug report.

On Mon, May 21, 2012 at 6:08 PM, Joseph Salisbury <
<email address hidden>> wrote:

> @Bart
>
> You mention this is a regression.l Can you test the latest v3.0 kernel
> to confirm this bug does not exist there? The v3.0 kernel can be
> downloaded from:
>
> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.0.31-oneiric/
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/991232
>
> Title:
> 14e4:432b Regression in wireless performance when on battery power
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/991232/+subscriptions
>

The bug was a regression in Maverick relative to Lucid, but it has been present in every release since Maverick, so at this point it's just a bug that has been around for at least 2 years.

It may not be practical to fix the bug in the bcmwl drivers, but the workaround is only a two-line patch with minimal impact. I have attached the patch that implements the workaround only for wl drivers and retains the same behavior for all others.

marking this confirmed. it affects multiple users, and i am replicating this behavior with the Broadcom Corporation BCM4322 802.11a/b/g/n Wireless LAN Controller [14e4:432b] (rev 01) on the mainline kernel daily build.

nathwill@loki-1545:~$ uname -a
Linux loki-1545 3.5.0-999-generic #201207190406 SMP Thu Jul 19 08:07:34 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
nathwill@loki-1545:~$ ip route
default via 192.168.1.1 dev wlan0 proto static
10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.100 metric 9
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
nathwill@loki-1545:~$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=9.72 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=12.7 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=3.62 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=64 time=3.60 ms
64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=5.33 ms
64 bytes from 192.168.1.1: icmp_req=6 ttl=64 time=4.63 ms
64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=4.28 ms
^C
--- 192.168.1.1 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6010ms
rtt min/avg/max/mdev = 3.609/6.282/12.767/3.289 ms
nathwill@loki-1545:~$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=0.931 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=26.1 ms
64 bytes from 192.168.1.1: icmp_req=5 ttl=64 time=49.2 ms
64 bytes from 192.168.1.1: icmp_req=7 ttl=64 time=43.5 ms
64 bytes from 192.168.1.1: icmp_req=8 ttl=64 time=9.15 ms
64 bytes from 192.168.1.1: icmp_req=10 ttl=64 time=2.89 ms
64 bytes from 192.168.1.1: icmp_req=11 ttl=64 time=8.06 ms
64 bytes from 192.168.1.1: icmp_req=13 ttl=64 time=1.50 ms
64 bytes from 192.168.1.1: icmp_req=15 ttl=64 time=32.2 ms
64 bytes from 192.168.1.1: icmp_req=16 ttl=64 time=5.03 ms
64 bytes from 192.168.1.1: icmp_req=18 ttl=64 time=28.8 ms
64 bytes from 192.168.1.1: icmp_req=19 ttl=64 time=72.2 ms
^C
--- 192.168.1.1 ping statistics ---
21 packets transmitted, 12 received, 42% packet loss, time 20068ms
rtt min/avg/max/mdev = 0.931/23.311/72.203/21.884 ms

noting also that i do not see the latency when disabling power-saving measures via as described in OP.

@Ryan,

Can you provide some information on the status of the patch with regards to getting it merged upstream? Has it been sent upstream, what sort of feedback has it received, is it getting applied to a subsystem maintainer's tree, etc?

People affected by this bug are probably wondering why the kernel team doesn't just apply the patch and fix it. The reason is that the kernel team is reluctant (not opposed) to apply any patch to a stable kernel that is not from upstream. Applying patches that don't come from upstream add greatly to the support of the kernel as other upstream patches may touch the same area as the non-upstream patch and may prevent them from applying cleanly.