bcmwl causes system freeze

[monochromec]

I'll file a bugzilla port on kernel.org with the kernel logs and post the reference here asap.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: bcmwl-kernel-source 6.30.223.248+bdcom-0ubuntu2 [modified: usr/src/bcmwl-6.30.223.248+bdcom/dkms.conf]
ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic x86_64
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
Date: Tue May 5 13:18:34 2015
InstallationDate: Installed on 2014-04-26 (373 days ago)
InstallationMedia: Lubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2)
SourcePackage: bcmwl
UpgradeStatus: Upgraded to vivid on 2015-04-24 (10 days ago)

[monochromec (monochromec)]

Needless to say, the above information doesn't reflect the system state as I had to remove the wl kernel module in order to file this issue. Watch out for the kernel logs on bugzilla.kernel.org

[monochromec (monochromec)]

When trying to reproduce the issue, I noticed that I could log into the GUI as created by the session manager (lightdm) if I left the cable in the onboard NIC. That means the system does go ahead when it can at least create one network connection other than lo (which is the default auto in my 15.04 configuration). If the NIC is not connected, the system will exhibit the symptoms as described above.

I attach both kernel logs (with and without a cable attached). More than happy to open a kernel bug report although that I do not think that this is solely a kernel issue. Please advise.

The last kernel version known to work is 3.17.8-031708; any later version up to 4.0.1 as installed from the Ubuntu kernel mainline archive fails with the symptoms described above. I also tried to reproduce this on version 4.1 but couldn't due to a GPL licensing issue (cf. https://github.com/longsleep/bcmwl-ubuntu/issues/2).

[monochromec (monochromec)]

Kernel log with cable attached to NIC.

[monochromec (monochromec)]

As a kludge (I wouldn't go as far as calling it a proper workaround), it's possible to substitute the wl LKM with the FOSS b43 LKM.

Assuming both b43-fwcutter and firmware-b43-installer (/ b43-legacy-installer) are installed, you can use a slightly modified version of boradcom-sta.conf in /etc/modprobe.d to load either b43 or wl depending on your kernel version. Just ensure that you enable wl in your /etc/modules file and NOT b43.

[monochromec (monochromec)]

Driver bug confirmed.

I'll open bugzilla bug report on kernel.org with the details.

[monochromec (monochromec)]

Bugzilla bug: https://bugzilla.kernel.org/show_bug.cgi?id=97881

[monochromec (monochromec)]

Kernel maintainer closed issue, referring back to Broadcom. I guess that leaves the responsibility with the package maintainer. As b43 is still showing the group temporal key issue rendering it essentially unusable in the current kernel line (confirmed on 3.19 and 4.0.1), it would be great if we could treat this bug with high priority.

Let me know if you need more information - more than happy to resolve this asap.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[ralphb (dev-endlos)]

Some additional comments:

My machine is a Dell XPS 13 using the BCM 4360 chip. The driver works perfectly fine with my Linksys wireless router (b/g mode). When I connect to my TP-Link router, however, authentication works fine, but sending and receiving additional packets nearly instantly freezes my machine (with Caps Lock flashing). Suffice to say that all other devices in my house connect just fine to the TP-Link router.

I'd be happy to provide additional information, but I don't know how to supply any post-mortem data.

[monochromec (monochromec)]

I was able to reproduce the issue on a stock Jessie install on a Vostro 1320 (featuring a BCM 3412). Kernel versions after 3.17 (including 3.18.12, 3.19.0, 3.19.6 and 4.0.1, at least these are the ones I checked myself) seem to have an issue which causes the kernel to lock up. BCM4331 causes an immediate freeze, whereas BCM 1312 (and as ralphb pointed out above BCM 4360) only show these symptoms after actual payload transmission. This goes for bcmwl versions 6.30.223.248 and 6.20.155.1.

I heard at a LUG meeting that Fedora 21/22 apparently contain special patches which at least support an MBP mid-2013. I will verify this and report results back asap.

Given that the kernel maintainer closed this issue (a move which I can only follow partly as wl works fine on pre-3.18 kernels) and BCM chips are pretty popular among laptop manufacturers: Could somebody upstream please assign this and bump it up so that we can get a resolution quickly?

More than happy to provide additional information in the meantime - just let me know what is needed (unfortunately, the wl driver doesn't seem to support debugging information generation beyond the usual).

[monochromec (monochromec)]

Hey Ralph,

Thanks for your feedback. While the issue is in the process of being narrowed down - would it be possible for you to supply the following information:

- Version of the kernel you're using alongside the distro version,
- Version of the wl module (you can get this with "apt-cache showpkg bcmwl-kernel-source" if you installed it from a repo),
- And most importantly. the exact TP-Link model which you are using alongside its software version (including whether you're using the stock software that came with the device or any third-party software such as OpenWRT, etc).

Thanks in advance for your help & feedback!

[ralphb (dev-endlos)]

Sure, happy to oblige:

- Kernel: 3.19.0-16-generic
- bcmwl-kernel-source: 6.30.223.248+bdcom-0ubuntu2
- TP-Link router:
  + Hardware Version: WR841N v8 0000000
  + Firmware Version: 3.13.33 Build 130506 Rel.48660n - no modifications whatsoever

Hope that helps. (Note that in the meantime I actually replaced the Wifi module in my machine by an Intel one, as I couldn't wait for this bug to be fixed.)

[monochromec (monochromec)]

Thanks for your feedback, Ralph - much appreciated!

I've found a solution for this bug. When research recent changes to the WL module source code, I came across a Fedora patch for kernel versions 3.18 and later (https://gist.github.com/hobarrera/ac0e6225210ac5bb13f6#file-broadcom-sta-6-30-223-248-linux-3-18-null-pointer-crash-patch). After incorporating this patch in the DKMS hierarchy for the affected kernels (see above), the module builds and works OK.

I attach the corresponding patch file - please incorporate this fix in the bcmwl package asap (and don't forget to adjust dkms.conf accordingly :-).

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Patch for kernel versions 3.18 and later" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Moritz Heiber (mheiber)]

Could we please fast-track this solution? My laptop is crashing every other hour because of it :/

[monochromec (monochromec)]

Moritz,

Instead of waiting for the upstream packagers to fix this, try one of the following:

- Use a pre-3.18 kernel. 3.16.33 and 3.16.34 are quite stable,
- Install the bmcwl package (version 6.30.233.248) and apply the patch manually in the /usr/src hierarchy which dkms uses to build the module. Don't forget to change the dkms.conf file to reflect the increased number of patches.