* Fail to load module wcn36xx @ 2017-01-27 20:54 Brian Wrenn 2017-01-27 21:19 ` Julia Cartwright 0 siblings, 1 reply; 5+ messages in thread From: Brian Wrenn @ 2017-01-27 20:54 UTC (permalink / raw) To: linux-rt-users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fail to load module wcn36xx 2017-01-27 20:54 Fail to load module wcn36xx Brian Wrenn @ 2017-01-27 21:19 ` Julia Cartwright 2017-01-27 21:24 ` Brian Wrenn 0 siblings, 1 reply; 5+ messages in thread From: Julia Cartwright @ 2017-01-27 21:19 UTC (permalink / raw) To: Brian Wrenn; +Cc: linux-rt-users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fail to load module wcn36xx 2017-01-27 21:19 ` Julia Cartwright @ 2017-01-27 21:24 ` Brian Wrenn 2017-01-27 21:30 ` Julia Cartwright 0 siblings, 1 reply; 5+ messages in thread From: Brian Wrenn @ 2017-01-27 21:24 UTC (permalink / raw) To: Julia Cartwright; +Cc: linux-rt-users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fail to load module wcn36xx 2017-01-27 21:24 ` Brian Wrenn @ 2017-01-27 21:30 ` Julia Cartwright 2017-01-27 21:43 ` Brian Wrenn 0 siblings, 1 reply; 5+ messages in thread From: Julia Cartwright @ 2017-01-27 21:30 UTC (permalink / raw) To: Brian Wrenn; +Cc: linux-rt-users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fail to load module wcn36xx 2017-01-27 21:30 ` Julia Cartwright @ 2017-01-27 21:43 ` Brian Wrenn 0 siblings, 0 replies; 5+ messages in thread From: Brian Wrenn @ 2017-01-27 21:43 UTC (permalink / raw) To: Julia Cartwright; +Cc: linux-rt-users 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-01-27 22:31 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-01-27 20:54 Fail to load module wcn36xx Brian Wrenn 2017-01-27 21:19 ` Julia Cartwright 2017-01-27 21:24 ` Brian Wrenn 2017-01-27 21:30 ` Julia Cartwright 2017-01-27 21:43 ` Brian Wrenn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).