[SOLVED] Broadcom wireless and Kernel 3.14.3

beder · 05-09-2014, 08:01 AM

Hello,

I updated my Slackware machine to Kernel 3.14.3 from -current, and since then I'm unable to build the broadcom-sta driver needed for my Wireless card

This is the error I get while trying to build it:

Code:

make: Entering directory `/usr/src/linux-3.14.3'
CFG80211 API is prefered for this kernel version
/tmp/SBo/build-broadcom-wl/Makefile:85: Neither CFG80211 nor Wireless Extension is enabled in kernel
make: Leaving directory `/usr/src/linux-3.14.3'
make: Entering directory `/usr/src/linux-3.14.3'
CFG80211 API is prefered for this kernel version
Using CFG80211 API
  LD      /tmp/SBo/build-broadcom-wl/built-in.o
  CC [M]  /tmp/SBo/build-broadcom-wl/src/shared/linux_osl.o
  CC [M]  /tmp/SBo/build-broadcom-wl/src/wl/sys/wl_linux.o
  CC [M]  /tmp/SBo/build-broadcom-wl/src/wl/sys/wl_iw.o
  CC [M]  /tmp/SBo/build-broadcom-wl/src/wl/sys/wl_cfg80211_hybrid.o
  LD [M]  /tmp/SBo/build-broadcom-wl/wl.o
  Building modules, stage 2.
CFG80211 API is prefered for this kernel version
Using CFG80211 API
  MODPOST 1 modules
WARNING: modpost: missing MODULE_LICENSE() in /tmp/SBo/build-broadcom-wl/wl.o
see include/linux/module.h for more information
WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
  CC      /tmp/SBo/build-broadcom-wl/wl.mod.o
  LD [M]  /tmp/SBo/build-broadcom-wl/wl.ko
make: Leaving directory `/usr/src/linux-3.14.3'

If I move on with the build anyway, this is what I get when trying to modprobe wl:

Code:

  433.735645] wl: module license 'unspecified' taints kernel.
[  433.735650] Disabling lock debugging due to kernel taint
[  433.738144] wl: Unknown symbol lockdep_init_map (err 0)

I found a thread on an Arch forum with someone with the same problem, but I couldn't quite make out how they fixed (seems like a patch in their broadcom-wl package, but I'm not sure): https://bbs.archlinux.org/viewtopic.php?pid=1215189

BTW in the generic kernel config from -current there is a CONFIG_CFG80211=m, which looks correct for me

enorbet · 05-09-2014, 09:02 AM

It is rather common that when I buy hardware I write, sometimes during registering, to tell them that I chose their brand because it is well supported in Linux. Conversely I also often write to manufacturers whose products I considered and say "I was excited about your Model XYZ and almost bought it but then chose your competitor's Model ABC because they don't use Broadcom wireless, not well supported in Linux which I consider unconscionable today with so many growing Linux users."

I apologize that this doesn't help fix what you have but is it expensive or otherwise difficult to save yourself such issues by getting one that works OOB?

turtleli · 05-09-2014, 05:21 PM

The missing CFG80211 message is just noise, that happens to me as well.

If you're willing to recompile the kernel then disable the lock debugging options. I get the same "Unknown symbol" error if CONFIG_DEBUG_LOCK_ALLOC=y.

beder · 05-09-2014, 09:36 PM

Quote:

Originally Posted by enorbet

It is rather common that when I buy hardware I write, sometimes during registering, to tell them that I chose their brand because it is well supported in Linux. ....
I apologize that this doesn't help fix what you have but is it expensive or otherwise difficult to save yourself such issues by getting one that works OOB?

This is my work machine, I didn't have a choice on the brand nor the components of it.
I appreciate your sentiment, but I just want to get things to work out

Quote:

Originally Posted by turtleli

The missing CFG80211 message is just noise, that happens to me as well.
If you're willing to recompile the kernel then disable the lock debugging options. I get the same "Unknown symbol" error if CONFIG_DEBUG_LOCK_ALLOC=y.

I supposed this message might be noise, and the part on dmesg is what might actually give some clue...

I think the guys from Arch actually got this to work, but I couldn't quite get their patch to compile with the slackbuild

turtleli · 05-09-2014, 09:59 PM

Just to clarify, I do have a working broadcom-sta wl driver with kernel 3.14.3. It requires a kernel with the lock debugging options disabled (I think it's Kernel Hacking -> Lock Debugging or something similar, I'm currently booted into Windows so I don't know the exact name) and then recompiling the broadcom-sta driver. No additional patches should be necessary.

WhiteWolf1776 · 05-10-2014, 07:20 AM

This thread lists the module names, etc:

http://www.linuxquestions.org/questi...429/page3.html

beder · 05-11-2014, 04:26 PM

Quote:

Originally Posted by turtleli

Just to clarify, I do have a working broadcom-sta wl driver with kernel 3.14.3. It requires a kernel with the lock debugging options disabled (I think it's Kernel Hacking -> Lock Debugging or something similar, I'm currently booted into Windows so I don't know the exact name) and then recompiling the broadcom-sta driver. No additional patches should be necessary.

Ah, ok, I misinterpreted your first answer indeed, thanks for clarifying.
I will try this on Monday when I get to that machine

beder · 05-12-2014, 12:35 PM

Quote:

Originally Posted by turtleli

Just to clarify, I do have a working broadcom-sta wl driver with kernel 3.14.3. It requires a kernel with the lock debugging options disabled (I think it's Kernel Hacking -> Lock Debugging or something similar, I'm currently booted into Windows so I don't know the exact name) and then recompiling the broadcom-sta driver. No additional patches should be necessary.

Hey,

I have recompiled the kernel with debug disabled, and wireless is working again!
So thank you for your response