bcmwl-kernel-source fails to build on lowlatency kernel [FATAL: modpost: GPL-incompatible module wl.ko uses GPL-only symbol '__rcu_read_unlock']

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

Hello,

In my case, wl only fails to build if the Preemption Model is set to "Preemptible Kernel".
With a kernel compile with "Voluntary Kernel Preemption", wl compiles fine through dkms.

Hope this helps.

Aurélien

I have also experience this error when i tried to build wl module with my custom kernel which has "Preemption Model" set to "Preemptible Kernel (Low-Latency Desktop)".

I have also tried to set the "Preemption Model" option to" Voluntary Kernel Preemption (Nothing)" and the wl module was built successfully .

thanks Aurélien

Builds on -generic kernel, does not on -lowlatency.

I can confirm that it does not build on -lowlatency.

I can confirm that this does not build on a lowlatency custom kernel v.3.10.0-rc7 and with bcmwl-kernel-source_6.30.223.30+bdcom-0ubuntu2_amd64.deb.

Am I correct in reading posts 3 and 4 - the only way to get the broadcom wireless driver to compile against a 5.8 low-latecy kernel is to build a custom kernel?

I am away from the machine at the moment, but I suspect simply adding voluntary-preemption=on to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub will not work unless the kernel has been compiled with the correct "Preemption Model".

What has the "Preemption Model" got to do with GPL symbols in the kernel header files?

I was disappointed to find there was no activity on this problem for a week. It is hard to believe no-one knows of a circumvention.

I've not been able to use the wireless adapter ever since I "upgraded" my laptop to 13.04, and will need to use it tomorrow but will not have access to an ethernet link...

Fortunately, I am using ubuntu studio. It uses the low-latency kernel, but I had forgotten the distro also installs and maintains the generic kernel. I rebooted with 3.8.0-26-generic and was very happy to discover the dkms source compiled cleanly. The machine is running fine on wifi with the generic kernel.

So what is it about the low-latency kernel headers that is different to generic, and also breaks the compile of bcmwl-kernel-source? Surely it isn't necessary?

AFAIK the only solution is by (illegally) modifying the bcmwl license to
be GPL, which Ubuntu will never do (but you could, privately).

For some reason some kernel functions can only be used with GPL-licensed modules, which bcmwl isn't.

I currently don't know if a "technical" workaround exists, other than not
using the low-latency kernel.

On Fri, 12 Jul 2013, Brian Burch wrote:

> I was disappointed to find there was no activity on this problem for a
> week. It is hard to believe no-one knows of a circumvention.
>
> I've not been able to use the wireless adapter ever since I "upgraded"
> my laptop to 13.04, and will need to use it tomorrow but will not have
> access to an ethernet link...
>
> Fortunately, I am using ubuntu studio. It uses the low-latency kernel,
> but I had forgotten the distro also installs and maintains the generic
> kernel. I rebooted with 3.8.0-26-generic and was very happy to discover
> the dkms source compiled cleanly. The machine is running fine on wifi
> with the generic kernel.
>
> So what is it about the low-latency kernel headers that is different to
> generic, and also breaks the compile of bcmwl-kernel-source? Surely it
> isn't necessary?

On 12/07/13 13:06, Bernardo Reino wrote:
> AFAIK the only solution is by (illegally) modifying the bcmwl license to
> be GPL, which Ubuntu will never do (but you could, privately).

That is very interesting. Thank you very much for your helpful comments.

> For some reason some kernel functions can only be used with GPL-licensed
> modules, which bcmwl isn't.

But I wonder why a) the same kernel functions compile OK against the
generic headers, and also b) compile OK against custom low-latency
kernel headers.

> I currently don't know if a "technical" workaround exists, other than not
> using the low-latency kernel.

It sounds to me as if something is different in the low-latency header
files that is erroneously checking for GPL compliancy, even for a source
file that is using logic that ought not to be protected.

I won't be able to do much for a week or so, but if no-one else has
anything to say in the meantime, I will look into the discrepancy
carefully to see what is happening. Based on your thoughts, I can hack
the source around until I see the cause more clearly.

Brian

> On Fri, 12 Jul 2013, Brian Burch wrote:
>
>> I was disappointed to find there was no activity on this problem for a
>> week. It is hard to believe no-one knows of a circumvention.
>>
>> I've not been able to use the wireless adapter ever since I "upgraded"
>> my laptop to 13.04, and will need to use it tomorrow but will not have
>> access to an ethernet link...
>>
>> Fortunately, I am using ubuntu studio. It uses the low-latency kernel,
>> but I had forgotten the distro also installs and maintains the generic
>> kernel. I rebooted with 3.8.0-26-generic and was very happy to discover
>> the dkms source compiled cleanly. The machine is running fine on wifi
>> with the generic kernel.
>>
>> So what is it about the low-latency kernel headers that is different to
>> generic, and also breaks the compile of bcmwl-kernel-source? Surely it
>> isn't necessary?

It would help if the Broadcom's brcmsmac developers would pick up the pace a little and get something into the kernel that is stable, effective, open source and supported. I only tried switching back to iwl because brcmsmac is both deaf and drops out frequently on my BCM4313 chipset.

Not to mention it's taken them until literally the last six months to get AP mode in.

It would win Broadcom so much goodwill (a real first) if they supported the project to full fruition.

OK, I have spent quite a while bashing my head against this brick wall now, trying to suss out why the lowlatency kernel build chokes, whilst the generic does not. I suspect it is heavily buried somewhere either in the compiler flags or in the deeper headers.

This is what I have found so far: if you compile low latency, as soon as wl_cfg80211.c includes an invocation either to rtnl_lock or rtnl_unlock (a fairly essential thing to do), the compile adds a U symbol for the __rcu_read_lock and __rcu_read_unlock. Remove the all the rtnl_lock and rtnl_unlock calls and the rcu symbols vanish too. Under generic they are never there; it relies on whatever module defines rtnetlink to request those symbols. The rtnetlink.h header is identical tween the two and there is only minimal #if stuff, none of which seems to relate to low latency stuff.

any ideas anyone?

Dug deeper, got more answers, but also more questions: rcupdate.h is heavily conditional on PREEMPT causing __rcu_read_lock/unlock to be extern rather than inline.
However, this leaves the most fundamental question of all: why are some functions OK to call from non-GPL code but others not? should these functions be marked as OK to call?

On 24/07/13 19:00, Stephen Parry wrote:
> Dug deeper, got more answers, but also more questions: rcupdate.h is heavily conditional on PREEMPT causing __rcu_read_lock/unlock to be extern rather than inline.
> However, this leaves the most fundamental question of all: why are some functions OK to call from non-GPL code but others not? should these functions be marked as OK to call?

Thanks very much for your efforts, Stephen. I won't have time to catch
up with your very useful research this week. However, I am still very
interested in a solution and your approach seems more productive than
building a custom low-latency kernel and hoping the driver will compile.

Still, given the earlier reports, I wonder which of the many hundreds of
kernel build options were defaulted to "something that works", rather
than the set of options in the standard ubuntu low-latency build
("something that doesn't work")? These two build paths must be
generating different kernel header files, mustn't they?

Sorry to be lazy (MUST get back to work!), but has this problem been
reported against low-latency kernels for other distros? The answer might
provide a valuable diff of kernel build options.

Brian

I'll weigh in here: I maintain the corresponding driver for ArchLinux; at Arch, the default kernel is pretty much "plain vanilla", and it suffers from this very same problem, since CONFIG_PREEMPT_RCU is on by default.
I've been hoping for a resolution to this problem since March, as it has affected Arch since kernel 3.8 and the changes it prompted to this driver at that time (introducing the calls to rcu_read_lock/unlock in the driver).

For a while, I was under the impression that this problem had been fixed for Ubuntu / low latency, and had been scratching my head to find out how, but I guess I am on the wrong track: it is still a problem on Ubuntu as well.

By the way, see also: https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1154036

It looks if events are preceeding me, but here is what I've found so far:

1. The earlier comments about using a custom kernel are just a red herring. I build a custom kernel using the standard lowlatency configuration and (not surprisingly) the bcmwl dkms module failed to compile.

2. A diff between the distro /boot/config-3.8.0-27-lowlatency and config-3.8.0-27-generic shows VERY few changes, mainly PREEMPT stuff and (probably) consequential LOCK variables - see attachment for full diff.

3. I built my custom kernel from the distro source package, not git. I intend to hack the patch proposed in https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1154036 (posted in march 2013!!) and try to apply it to my kernel source.

Hi all,

IANAL but I think it should be no problem to link non-GPL with GPL symbols. For some reason kernel's modpost checks for this and aborts.

Modifying the license of a module would certainly be illegal. Modifying modpost.c to remove that check (s/fatal/warn/) would just produce a warning but still allow the linking.

Could anybody give a legal opinion regarding this?

Bernado, could you save me some time please?

Originally, I thought you were proposing to patch some of the kernel source. However, when I started work I quickly discovered the three target files are in the bcmwl package and the kernel is untouched.

I have compared your proposed file 0006-add-support-for-linux-3.8.0.patch with the original in my distributed copy from bcmwl-6.20.155.1+bdcom. I can see your proposal is a "rolled up" patch that includes the original distro change as well as your new one.

My problem is that I am not familiar enough with the package delivery mechanism. Your patch file seems to compare git trees, but I am puzzled by the fact that the distro has a "patches" subdirectory with that file in it. If I replace the original patch file with your new copy and then reinstall the package, will the patch be automatically applied (sounds like magic to me!)... or is it just shipped as documentation?

I was all ready to rework your patches to apply them to the "src" subdirectory when I realised my effort might not be necessary. Could you advise me, please?

@Brian,

I'm sure sure I understand you correctly. I haven't proposed/posted any patches. My only (UNTESTED) suggestion was to patch modpost.c to bypass the error.

I haven't tested this because I don't use the lowlatency kernel (I might test it given sufficient time though :). modpost is probably part of linux-headers package, but I cannot check right now.

Bernardo - I apologise for confusing you with the author of the patch - please disregard my comment!

I spent some time learning about the bcmwl patch referred to in #18 above. I tried a lot os things that frustratingly made no difference, but here is what counts as partial success:-

1. Backup the unpacked distro version of /usr/src/bcmwl-6.20.155.1+bdcom/patches/0006-add-support-for-linux-3.8.0.patch.
2. Move the new patch file to replace the original. A diff shows the patches have a lot in common, but also a lot of new conditional compile blocks that apply to the 3.8.0 kernels and alter the use of the gpl symbol.
3. sudo dkms status confirms bcmwl was already installed against my three kernels: generic, low-latency ans custom low-latency.
4. sudo dkms build bcmwl/6.20.155.1+bdcom -k 3.8.0-27-lowlatency and my custom kernel ran successfully (i.e. no failure due to invalid use of gpl symbol).
5. sudo dkms install bcmwl/6.20.155.1+bdcom -k 3.8.0-27-lowlatency passes the sanity check, installs wl.ko and rens depmod successfully.
6. /var/lib/dkms/bcmwl/kernel-3.8.0-27-lowlatency-i686/log/make.log shows the five compiles are ok, but the last stage issues the message "WARNING: "rcu_read_unlock_special" [/var/lib/dkms/bcmwl/6.20.155.1+bdcom/build/wl.ko] undefined!" before creating the wl.ko module. I don't know whether this warning is important or not - perhaps the patch is not complete?

Unfortunately, when I reboot the bcmwl driver does not load. I guess there is another step I need to make (update-initramfs perhaps?)

I don't know whether update-initramfs was necessary, but it certainly didn't do any harm!

The low-latency dmesg now shows the wl and cfg80211 modules are being loaded, but there is a problem:

[ 24.624284] wl: module license 'MIXED/Proprietary' taints kernel.
[ 24.624290] Disabling lock debugging due to kernel taint
[ 24.626241] wl: Unknown symbol rcu_read_unlock_special (err 0)

The unlnown symbol is the same as in the warning I noticed in the dkms install log, so it is important after all...

Also, once the system has booted lsmod does not show the wl module any more, and the eth1 interface does not exist.

I will do some research on that symbol in the bcmwl patch.

Interesting :)

If the module builds OK but doesn't load, you could try loading it manually "modprobe wl" and see if any errors show up on the console/syslog/dmesg.

AFAIK the patch you've applied adds support for 3.8 as well as for lowlatency. If this works OK you could try isolating the lowlatency part, as the patch for 3.8 (and 3.9 and 3.10) is already in the Ubuntu package (I'm using 6.30.223 with kernel 3.10 under Ubuntu 12.04 and it works great).

Note that even if this patch actually makes the module work, its legal situation is, as far as I can judge (without being a judge :), not certain.

"modprobe wl" just triggers the identical message (above) about the unknown symbol rcu_read_unlock_special, both on the console and also in syslog.

I'll compare the patch file I'm using with the version in 3.9/10 - perhaps it has an error that was fixed later.

Bernado, I downloaded the three packages for bcmwl for the saucy distro (bcmwl-6.30.223.30+bdcom), but none of them contain 0006-add-support-for-linux-3.8.0.patch.

There is more stuff available, but it currently has restricted access, so I don't know whether the file will be there.

Could you tell me where I can download a copy of 0006 and the later patches? I currently have up to 0007-nl80211-move-scan-API-to-wdev.patch, but it might be helpful if I had everything from 0006 up to the latest.

Weird. Note: I'm on 12.04, not 13.04, but it shouldn't matter.

I have bcmwl-kernel-source 6.30.223.30+bdcom-0ubuntu3, downloaded from here:
https://launchpad.net/ubuntu/+source/bcmwl/6.30.223.30+bdcom-0ubuntu3/+build/4761504

That one includes in /patches:
0001, 0002, 0003, 0004 (kernel 3.2), 0005 (kernel 3.4), 0006 (kernel 3.8), 0007 (wdev), 0008 (kernel 3.9), 0009 (kernel 3.10)

Note that the patch for 3.10 (0009) is PATCH_MATCH'ed to kernels 3.10 and 3.11. But this should be irrelevant.

Thanks Bernardo. Your link was basically the same as where I had already downloaded from.

Never having worked with it before, I am struggling to rapidly understand the maintenance, packaging and build structures of ubuntu dkms. I failed to find a patch file of the correct name, but I can now see the content of what will become it within the bcmwl_6.30.223.30+bdcom-0ubuntu3.diff file, so I have something to work with - even though I don't actually have the patch file used during the dkms install of the bcmwl module.

bcmwl_6.20.155 running under my generic kernel is the only way I can use the wifi adapter at the moment. My low-latency and custom kernels are installed on the same system and share the same package. I don't want to risk breaking the only combination that currently works, and I can't see a safe and easy way to have both versions of bcmwl on the same system. I will stick with slow and painful source file comparisons for the moment - unless you tell me a quicker way...

I changed my mind after a trip away. When trying to use bcmwl_6.20.155 under the generic kernel, the system was very unreliable and often just froze.

I noticed the 6.30.223.30 link you gave me was for the amd46 deb, so I found bcmwl-kernel-source_6.30.223.30+bdcom-0ubuntu3_i386.deb and installed that version (despite the worrying warning it would replace 6.20.155). I was very disappointed to see the install failed with "the usual" GPL-incompatible symbol __rcu_read_unblock.

I rebooted to the generic kernel (not really necessary) and dkms status showed the new module had been added already. I ran a dkms install against only the generic kernel and that worked fine. After rebooting, the wifi is working, although I haven't been using it long enough to comment on its stability.

I feel this is progress. Even though I haven't moved forward, I've learnt a lot and am now running the latest source. I think I will try making an 0010 patch file for the low latecy changes.

I've done a lot of work trying to get the patch to work, including trying to resolve the subsequent problem where the wl.ko module builds but fails to load because rcu_read_unlock_special cannot be used on the current 3.8.0-30-lowlatency kernel. This issue is reported in https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/1154036.

Exasperated after digging around and finding far more knowledgeable people than me were stumped, I gave up. I edited my local copy of 0001-MODULE_LICENSE.patch to replace the string "Mixed/Proprietary" with "GPL". The broadcom wireless driver is now working on my system.

I look forward to removing the kludge as soon as this bug is fixed properly.

@Brian,

Sorry that after all your efforts you ended up going to the "easy" (though questionable) solution. Since there is no reason to expect Broadcom to fully GPL the driver, I guess the only solution (besides using the in-kernel driver, which to me -- bcm4313 -- is still a no-go) would be patching modpost.c (which -- theorically -- solves the compilation issue, but perhaps not the run-time (modprobe) issue).

I guess this is all due to some -- political -- decision of the kernel people (Linus), so I'm not sure if/how we can deal with this, other than asking Linus.

Thanks for your thoughts, Bernardo.

I've lost and can't find the links any more, but I previously found Alberto Milone was communicating with the kernel devs about the problem where rcu_read_unlock_special is not useable, even though it is apparently defined in the low latency symbol table. I actually hacked a lot of the kernel source into my own bcmwl source, but this was my final sticking point. Given that Alberto knows what he is doing and I'm just feeling my way, anything I had to say would have just been duplication.

This is a wider issue than just broadcom's proprietary driver. I also found someone with a similar problem compiling the ati video driver under the low latency kernel. There was also someone blogging about "gpl hell" and proprietary drivers.

I think most linux users (including me) are completely unaware of the politics behind this issue. We bought our hardware and want to run linux - why deny us that?

Do the linux devs want to drive us back to windoze???? Should I go back to the 3.5 kernel, which happily co-exists with these drivers, and then never upgrade? And anyway, what is so special about the low latency kernel - the generic supports the latest bcmwl driver without a murmer of disapproval! I don't think this is a case of a conspiracy, just "the usual" c#*k up alternative theory.

I upgraded my dell laptop to 13.10 ubuntu-studio about 2 weeks ago, which uses kernel 3.11.0-15.8-lowlatency.

I just assumed that dkms was building and using my locally-patched driver. I have just checked and discovered I was mistaken... it is using the distro package bcmwl-kernel-source version 6.30.223.141+bdcom-0ubuntu1.

I can see 0001-MODULE_LICENSE.patch still defines a Mixed/Proprietary License, so it seems someone has altered the GPL kernel source restrictions. My thanks to whoever did that! It has released quite a few users from having to maintain their own dkms source.

As far as I am concerned, this bug can be marked as fixed in 13.10.

Good news!

Brian