Fail to load module wcn36xx

Fail to load module wcn36xx

[Brian Wrenn]

Hi,

I'm trying to get the WLAN wcn36xx driver to load on PRREMPT RT.

By some fluke I had this module load successfully in the PREEMPT RT
kernel at one point in time, but I have not been able to reproduce
getting to to load since my first trial build.

I'm patching Linaro 4.4.9 with PREEMPT RT patch 4.4.9-rt17.  I've also
manually applied a patch for
kernel/drivers/pinctrl/qcom/pinctrl-msm.c, which replaces uses of
spinlock calls with raw_spinlock calls.

Here's the dmesg output, which indicates unknown symbols as the
problem.  However, I'm not sure why this module can't load those
symbols.

I can successfully load them if I just build plain Linaro 4.4.9,
without PREEMPT RT.

[   14.023055] wcn36xx: Unknown symbol mutex_lock (err 0)
[   14.023105] wcn36xx: Unknown symbol __mutex_init (err 0)
[   14.027153] wcn36xx: Unknown symbol mutex_unlock (err 0)
[   14.027208] wcn36xx: Unknown symbol _raw_spin_unlock (err 0)
[   16.961824] wcn36xx: Unknown symbol mutex_lock (err 0)
[   16.961889] wcn36xx: Unknown symbol __mutex_init (err 0)
[   16.965955] wcn36xx: Unknown symbol mutex_unlock (err 0)
[   16.971391] wcn36xx: Unknown symbol _raw_spin_unlock (err 0)

Thanks for any help,
Brian

Re: Fail to load module wcn36xx

[Julia Cartwright]

On Fri, Jan 27, 2017 at 03:54:59PM -0500, Brian Wrenn wrote:
> Hi,

Hello again.

> I'm trying to get the WLAN wcn36xx driver to load on PRREMPT RT.
>
> By some fluke I had this module load successfully in the PREEMPT RT
> kernel at one point in time, but I have not been able to reproduce
> getting to to load since my first trial build.
>
> I'm patching Linaro 4.4.9 with PREEMPT RT patch 4.4.9-rt17.  I've also
> manually applied a patch for
> kernel/drivers/pinctrl/qcom/pinctrl-msm.c, which replaces uses of
> spinlock calls with raw_spinlock calls.
>
> Here's the dmesg output, which indicates unknown symbols as the
> problem.  However, I'm not sure why this module can't load those
> symbols.
>
> I can successfully load them if I just build plain Linaro 4.4.9,
> without PREEMPT RT.
>
> [   14.023055] wcn36xx: Unknown symbol mutex_lock (err 0)
> [   14.023105] wcn36xx: Unknown symbol __mutex_init (err 0)
> [   14.027153] wcn36xx: Unknown symbol mutex_unlock (err 0)
> [   14.027208] wcn36xx: Unknown symbol _raw_spin_unlock (err 0)
> [   16.961824] wcn36xx: Unknown symbol mutex_lock (err 0)
> [   16.961889] wcn36xx: Unknown symbol __mutex_init (err 0)
> [   16.965955] wcn36xx: Unknown symbol mutex_unlock (err 0)
> [   16.971391] wcn36xx: Unknown symbol _raw_spin_unlock (err 0)

This just seems to indicate that you haven't rebuilt this module for the
RT kernel.  These symbols don't exist w/ RT, because they're switched up
through macros/inlines to make use of the rt_mutex type.

You'll need to ensure you're building the module for the target kernel.

   Julia

Re: Fail to load module wcn36xx

[Brian Wrenn]

So it looks like I found the culprit, which is related to your point.
In my config I had this:

CONFIG_WCN36XX=m

when I needed to have this:

CONFIG_WCN36XX=y

I thought the dependency that would have triggered the 'm' state of
the config item existed, but evidently not.  So indeed I was not
building the module when I thought I was.

Thank you again, Julia!

On Fri, Jan 27, 2017 at 4:19 PM, Julia Cartwright <julia@ni.com> wrote:
> On Fri, Jan 27, 2017 at 03:54:59PM -0500, Brian Wrenn wrote:
>> Hi,
>
> Hello again.
>
>> I'm trying to get the WLAN wcn36xx driver to load on PRREMPT RT.
>>
>> By some fluke I had this module load successfully in the PREEMPT RT
>> kernel at one point in time, but I have not been able to reproduce
>> getting to to load since my first trial build.
>>
>> I'm patching Linaro 4.4.9 with PREEMPT RT patch 4.4.9-rt17.  I've also
>> manually applied a patch for
>> kernel/drivers/pinctrl/qcom/pinctrl-msm.c, which replaces uses of
>> spinlock calls with raw_spinlock calls.
>>
>> Here's the dmesg output, which indicates unknown symbols as the
>> problem.  However, I'm not sure why this module can't load those
>> symbols.
>>
>> I can successfully load them if I just build plain Linaro 4.4.9,
>> without PREEMPT RT.
>>
>> [   14.023055] wcn36xx: Unknown symbol mutex_lock (err 0)
>> [   14.023105] wcn36xx: Unknown symbol __mutex_init (err 0)
>> [   14.027153] wcn36xx: Unknown symbol mutex_unlock (err 0)
>> [   14.027208] wcn36xx: Unknown symbol _raw_spin_unlock (err 0)
>> [   16.961824] wcn36xx: Unknown symbol mutex_lock (err 0)
>> [   16.961889] wcn36xx: Unknown symbol __mutex_init (err 0)
>> [   16.965955] wcn36xx: Unknown symbol mutex_unlock (err 0)
>> [   16.971391] wcn36xx: Unknown symbol _raw_spin_unlock (err 0)
>
> This just seems to indicate that you haven't rebuilt this module for the
> RT kernel.  These symbols don't exist w/ RT, because they're switched up
> through macros/inlines to make use of the rt_mutex type.
>
> You'll need to ensure you're building the module for the target kernel.
>
>    Julia

Re: Fail to load module wcn36xx

[Julia Cartwright]

Hey Brian-

Please respond inline in the future.

On Fri, Jan 27, 2017 at 04:24:02PM -0500, Brian Wrenn wrote:
> On Fri, Jan 27, 2017 at 4:19 PM, Julia Cartwright <julia@ni.com> wrote:
> > On Fri, Jan 27, 2017 at 03:54:59PM -0500, Brian Wrenn wrote:
[..]
> >> Here's the dmesg output, which indicates unknown symbols as the
> >> problem.  However, I'm not sure why this module can't load those
> >> symbols.
> >>
> >> I can successfully load them if I just build plain Linaro 4.4.9,
> >> without PREEMPT RT.
> >>
> >> [   14.023055] wcn36xx: Unknown symbol mutex_lock (err 0)
> >> [   14.023105] wcn36xx: Unknown symbol __mutex_init (err 0)
> >> [   14.027153] wcn36xx: Unknown symbol mutex_unlock (err 0)
> >> [   14.027208] wcn36xx: Unknown symbol _raw_spin_unlock (err 0)
> >> [   16.961824] wcn36xx: Unknown symbol mutex_lock (err 0)
> >> [   16.961889] wcn36xx: Unknown symbol __mutex_init (err 0)
> >> [   16.965955] wcn36xx: Unknown symbol mutex_unlock (err 0)
> >> [   16.971391] wcn36xx: Unknown symbol _raw_spin_unlock (err 0)
> >
> > This just seems to indicate that you haven't rebuilt this module for the
> > RT kernel.  These symbols don't exist w/ RT, because they're switched up
> > through macros/inlines to make use of the rt_mutex type.
> >
> > You'll need to ensure you're building the module for the target kernel.
> >
>
> So it looks like I found the culprit, which is related to your point.
> In my config I had this:
> 
> CONFIG_WCN36XX=m
> 
> when I needed to have this:
> 
> CONFIG_WCN36XX=y
> 
> I thought the dependency that would have triggered the 'm' state of
> the config item existed, but evidently not.  So indeed I was not
> building the module when I thought I was.

I want to ensure you walk away with the right conclusion :).

There is nothing fundamentally wrong with building with
CONFIG_WCN36XX=m.  This should Just Work(tm).  The problem is when there
exists a mismatch between the target kernel you are booting, and the
module set that was built with that kernel.

It looks like, what you've done is booted a PREEMPT_RT_FULL build of
Linux, but then tried to load a module which was built against a
non-PREEMPT_RT_FULL configuration.

Glad I could help,
   Julia

Re: Fail to load module wcn36xx

[Brian Wrenn]

On Fri, Jan 27, 2017 at 4:30 PM, Julia Cartwright <julia@ni.com> wrote:
> Hey Brian-
>
> Please respond inline in the future.
>
> On Fri, Jan 27, 2017 at 04:24:02PM -0500, Brian Wrenn wrote:
>> On Fri, Jan 27, 2017 at 4:19 PM, Julia Cartwright <julia@ni.com> wrote:
>> > On Fri, Jan 27, 2017 at 03:54:59PM -0500, Brian Wrenn wrote:
> [..]
>> >> Here's the dmesg output, which indicates unknown symbols as the
>> >> problem.  However, I'm not sure why this module can't load those
>> >> symbols.
>> >>
>> >> I can successfully load them if I just build plain Linaro 4.4.9,
>> >> without PREEMPT RT.
>> >>
>> >> [   14.023055] wcn36xx: Unknown symbol mutex_lock (err 0)
>> >> [   14.023105] wcn36xx: Unknown symbol __mutex_init (err 0)
>> >> [   14.027153] wcn36xx: Unknown symbol mutex_unlock (err 0)
>> >> [   14.027208] wcn36xx: Unknown symbol _raw_spin_unlock (err 0)
>> >> [   16.961824] wcn36xx: Unknown symbol mutex_lock (err 0)
>> >> [   16.961889] wcn36xx: Unknown symbol __mutex_init (err 0)
>> >> [   16.965955] wcn36xx: Unknown symbol mutex_unlock (err 0)
>> >> [   16.971391] wcn36xx: Unknown symbol _raw_spin_unlock (err 0)
>> >
>> > This just seems to indicate that you haven't rebuilt this module for the
>> > RT kernel.  These symbols don't exist w/ RT, because they're switched up
>> > through macros/inlines to make use of the rt_mutex type.
>> >
>> > You'll need to ensure you're building the module for the target kernel.
>> >
>>
>> So it looks like I found the culprit, which is related to your point.
>> In my config I had this:
>>
>> CONFIG_WCN36XX=m
>>
>> when I needed to have this:
>>
>> CONFIG_WCN36XX=y
>>
>> I thought the dependency that would have triggered the 'm' state of
>> the config item existed, but evidently not.  So indeed I was not
>> building the module when I thought I was.
>
> I want to ensure you walk away with the right conclusion :).
>
> There is nothing fundamentally wrong with building with
> CONFIG_WCN36XX=m.  This should Just Work(tm).  The problem is when there
> exists a mismatch between the target kernel you are booting, and the
> module set that was built with that kernel.
>
> It looks like, what you've done is booted a PREEMPT_RT_FULL build of
> Linux, but then tried to load a module which was built against a
> non-PREEMPT_RT_FULL configuration.
>
> Glad I could help,
>    Julia

Yes, it was indeed built against a non-PREEMPT_RT_FULL config
initially.  I just thought I had forced it to recompile when I did a
make clean before make, which maybe I did wrongly.

After I toggled the flag from 'm' to 'y', I noticed something got
built even without a clean build.  In particular...

  CC      drivers/net/wireless/ath/wcn36xx/main.o
  CC      drivers/net/wireless/ath/wcn36xx/dxe.o
  CC      drivers/net/wireless/ath/wcn36xx/txrx.o
  CC      drivers/net/wireless/ath/wcn36xx/smd.o
In file included from drivers/net/wireless/ath/wcn36xx/dxe.c:26:0:
include/linux/soc/qcom/smem_state.h:15:92: warning: ‘struct
device_node’ declared inside parameter list [enabled by default]
 struct qcom_smem_state *qcom_smem_state_register(struct device_node
*of_node, const struct qcom_smem_state_ops *ops, void *data);

                     ^
include/linux/soc/qcom/smem_state.h:15:92: warning: its scope is only
this definition or declaration, which is probably not what you want
[enabled by default]
  CC      drivers/net/wireless/ath/wcn36xx/pmc.o
  CC      drivers/net/wireless/ath/wcn36xx/debug.o

So toggling that flag must have indicated to the make file that it
must rebuild the module in some way.

Thanks again, and have a great weekend.