On Fri, Jan 27, 2017 at 4:30 PM, Julia Cartwright <julia@xxxxxx> 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@xxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
