Hi,
We are trying to implement a protocol to evaluate the performance our
algorithm using QCA9880.
To implement our protocol, a receiver have to change the bandwidth
when a Action frame (what we define) is successfully received.
We know that the QCA9880 can change bandwidth by using iw command in
monitor mode.
So, we use similar function path used by "iw dev set freq ..."
When the receiver detects the reception of the Action frame we call
"ieee80211_set_monitor_channel" at the end of ieee80211_rx as follows:
/*************** net/mac80211/rx.c ******************/
// receive action frame, change bandwidth 80 -> 20
rtnl_lock(); //lock rtnetlink used in pre_doit of nl80211
chandef = local->monitor_chandef; // copy current chandef
chandef.width = NL80211_CHAN_WIDTH_20; // set bandwidth
chandef.center_freq1 = 5180; // set center freq...
ieee80211_set_monitor_channel(wiphy, &chandef);
rtnl_unlock();
/********************************************************/
However, the receiver invokes kernel panic when receives the Action frame.
As fas as we know, the panic is occurred in ath10k_config_chan of
ath10k device driver.
To the best our knowledge, our implementation exploits same function
path of iw command in nl80211, cfg80211, mac80211 and ath10k.
Moreover, we confirm that the input parameters (wiphy, chandef) in our
implementation are identical to the parameters used by iw command.
Is there any reason why we cannot change bandwidth?
Of course, iw command work correctly.
If you have any idea to solve this, please let me know.
Thanks a lot for your reading.
Sincerely yours,
Okhwan Lee , Ph.D. student
Hi,
This linked images are the printed error messages when the kernel is in panic.
http://www.mwnl.snu.ac.kr/~ohlee/1.jpg
http://www.mwnl.snu.ac.kr/~ohlee/2.jpg
Thank you for your help.
Okhwan
--
Okhwan Lee
Sent with Airmail
켜짐 2014년 10월 24일 에서 오후 4:49:23, Michal Kazior ([email protected](mailto:[email protected])) 작성됨:
> On 23 October 2014 08:57, Okhwan Lee wrote:
> > Hi,
> >
> > Thank you for your answer.
> >
> >> The panic printout would be most helpful. My best guess is this
> >> crashes in ath10k_dbg() at the very beginning of ath10k_config_chan
> >> because ar->chandef.chan is NULL. This is probably the case since you
> >> use monitor_chandef which is probably "empty" at the point you invoke
> >> your code.
> >
> > First, we confirm that ar->chandef.chan is not NULL.
> > We find out the the error occurs when "wait_for_completion_timeout" is called.
> > Ath10k is trying to stop vdev (monitor_dev) when change the channel setting.
> > We have no idea about the details of function, but it make waiting
> > time duration for previous event.
> > We also test by replacing wait_for_completion_timeout to
> > wait_for_completion (i.e., it use maximum timeout value)
> > But the kernel panic is still there.
> >
> > However, it is not easy to printout the messages when the panic is occurred,
> > because the system stop (similar to bluescreen in widnows?).
> > After reboot the system, the log messagess from panic is not recored
> > in kernel log messages (/var/log/syslog, dmesg, kernel_llog) .
>
> Can you at least do a photo of the panic, post it to an image hosting
> site and link it, please?
>
>
> Michał
On 24 October 2014 13:30, Okhwan Lee <[email protected]> wrote:
> Hi,
>
> This linked images are the printed error messages when the kernel is in panic.
> http://www.mwnl.snu.ac.kr/~ohlee/1.jpg
> http://www.mwnl.snu.ac.kr/~ohlee/2.jpg
Thanks.
Panic doesn't seem to include anything directly related to ath10k
which suggests this may be some nasty memory corruption issue. You
might want to enable memory debugging when building kernel (Kernel
Hacking) - hopefully it'll get some extra info before the panic.
How did you come to a conclusion that ath10k's monitor vdev stopping
and wait_for_completion_timeout() are involved?
Michał
Hi,
Thanks for your help.
We just disable some functions step by step.
Then we can conclude that wait_for_completion_timeout makes kernel panic.
We guess that monitor vdev stopping after reception of a Action frame requires more time than the case when using iw command.
Instead of wait_for_completion_timeout, we also use alternative function, wait_for_completion (uses maximum timeout value),
but the panic is still there.
We don’t have the expert on kernel memory debugging from now on.
We have to study more how to handle it.
Again, thank you.
Okhwan Lee
Sent with Airmail
켜짐 2014년 10월 24일 에서 오후 8:38:44, Michal Kazior ([email protected](mailto:[email protected])) 작성됨:
>
On 22 October 2014 12:14, Okhwan Lee <[email protected]> wrote:
> Hi,
>
> We are trying to implement a protocol to evaluate the performance our
> algorithm using QCA9880.
>
> To implement our protocol, a receiver have to change the bandwidth
> when a Action frame (what we define) is successfully received.
> We know that the QCA9880 can change bandwidth by using iw command in
> monitor mode.
> So, we use similar function path used by "iw dev set freq ..."
> When the receiver detects the reception of the Action frame we call
> "ieee80211_set_monitor_channel" at the end of ieee80211_rx as follows:
>
> /*************** net/mac80211/rx.c ******************/
>
> // receive action frame, change bandwidth 80 -> 20
>
> rtnl_lock(); //lock rtnetlink used in pre_doit of nl80211
> chandef = local->monitor_chandef; // copy current chandef
> chandef.width = NL80211_CHAN_WIDTH_20; // set bandwidth
> chandef.center_freq1 = 5180; // set center freq...
> ieee80211_set_monitor_channel(wiphy, &chandef);
> rtnl_unlock();
>
> /********************************************************/
If my understanding is correct you're doing it wrong.
You probably want to modify chanctx of a vif the frame is associated
with and notify the driver via appropriate mac80211 helpers instead of
the hack above. Remember to get your locking right.
> However, the receiver invokes kernel panic when receives the Action frame.
> As fas as we know, the panic is occurred in ath10k_config_chan of
> ath10k device driver.
The panic printout would be most helpful. My best guess is this
crashes in ath10k_dbg() at the very beginning of ath10k_config_chan
because ar->chandef.chan is NULL. This is probably the case since you
use monitor_chandef which is probably "empty" at the point you invoke
your code.
> To the best our knowledge, our implementation exploits same function
> path of iw command in nl80211, cfg80211, mac80211 and ath10k.
> Moreover, we confirm that the input parameters (wiphy, chandef) in our
> implementation are identical to the parameters used by iw command.
>
> Is there any reason why we cannot change bandwidth?
> Of course, iw command work correctly.
The iw set channel is for monitor interfaces only so trying to make it
work with, e.g. a station interface will bring you pain.
Michał
On 23 October 2014 08:57, Okhwan Lee <[email protected]> wrote:
> Hi,
>
> Thank you for your answer.
>
>> The panic printout would be most helpful. My best guess is this
>> crashes in ath10k_dbg() at the very beginning of ath10k_config_chan
>> because ar->chandef.chan is NULL. This is probably the case since you
>> use monitor_chandef which is probably "empty" at the point you invoke
>> your code.
>
> First, we confirm that ar->chandef.chan is not NULL.
> We find out the the error occurs when "wait_for_completion_timeout" is called.
> Ath10k is trying to stop vdev (monitor_dev) when change the channel setting.
> We have no idea about the details of function, but it make waiting
> time duration for previous event.
> We also test by replacing wait_for_completion_timeout to
> wait_for_completion (i.e., it use maximum timeout value)
> But the kernel panic is still there.
>
> However, it is not easy to printout the messages when the panic is occurred,
> because the system stop (similar to bluescreen in widnows?).
> After reboot the system, the log messagess from panic is not recored
> in kernel log messages (/var/log/syslog, dmesg, kernel_llog) .
Can you at least do a photo of the panic, post it to an image hosting
site and link it, please?
Michał
Hi,
Thank you for your answer.
> The panic printout would be most helpful. My best guess is this
> crashes in ath10k_dbg() at the very beginning of ath10k_config_chan
> because ar->chandef.chan is NULL. This is probably the case since you
> use monitor_chandef which is probably "empty" at the point you invoke
> your code.
First, we confirm that ar->chandef.chan is not NULL.
We find out the the error occurs when "wait_for_completion_timeout" is called.
Ath10k is trying to stop vdev (monitor_dev) when change the channel setting.
We have no idea about the details of function, but it make waiting
time duration for previous event.
We also test by replacing wait_for_completion_timeout to
wait_for_completion (i.e., it use maximum timeout value)
But the kernel panic is still there.
However, it is not easy to printout the messages when the panic is occurred,
because the system stop (similar to bluescreen in widnows?).
After reboot the system, the log messagess from panic is not recored
in kernel log messages (/var/log/syslog, dmesg, kernel_llog) .
> The iw set channel is for monitor interfaces only so trying to make it
> work with, e.g. a station interface will bring you pain.
We already know about this. So, we test this in monitor mode.
Thank you for your answer.
Sincerely yours,
Okhwan
2014-10-22 19:40 GMT+09:00 Michal Kazior <[email protected]>:
> On 22 October 2014 12:14, Okhwan Lee <[email protected]> wrote:
>> Hi,
>>
>> We are trying to implement a protocol to evaluate the performance our
>> algorithm using QCA9880.
>>
>> To implement our protocol, a receiver have to change the bandwidth
>> when a Action frame (what we define) is successfully received.
>> We know that the QCA9880 can change bandwidth by using iw command in
>> monitor mode.
>> So, we use similar function path used by "iw dev set freq ..."
>> When the receiver detects the reception of the Action frame we call
>> "ieee80211_set_monitor_channel" at the end of ieee80211_rx as follows:
>>
>> /*************** net/mac80211/rx.c ******************/
>>
>> // receive action frame, change bandwidth 80 -> 20
>>
>> rtnl_lock(); //lock rtnetlink used in pre_doit of nl80211
>> chandef = local->monitor_chandef; // copy current chandef
>> chandef.width = NL80211_CHAN_WIDTH_20; // set bandwidth
>> chandef.center_freq1 = 5180; // set center freq...
>> ieee80211_set_monitor_channel(wiphy, &chandef);
>> rtnl_unlock();
>>
>> /********************************************************/
>
> If my understanding is correct you're doing it wrong.
>
> You probably want to modify chanctx of a vif the frame is associated
> with and notify the driver via appropriate mac80211 helpers instead of
> the hack above. Remember to get your locking right.
>
>
>> However, the receiver invokes kernel panic when receives the Action frame.
>> As fas as we know, the panic is occurred in ath10k_config_chan of
>> ath10k device driver.
>
> The panic printout would be most helpful. My best guess is this
> crashes in ath10k_dbg() at the very beginning of ath10k_config_chan
> because ar->chandef.chan is NULL. This is probably the case since you
> use monitor_chandef which is probably "empty" at the point you invoke
> your code.
>
>
>> To the best our knowledge, our implementation exploits same function
>> path of iw command in nl80211, cfg80211, mac80211 and ath10k.
>> Moreover, we confirm that the input parameters (wiphy, chandef) in our
>> implementation are identical to the parameters used by iw command.
>>
>> Is there any reason why we cannot change bandwidth?
>> Of course, iw command work correctly.
>
> The iw set channel is for monitor interfaces only so trying to make it
> work with, e.g. a station interface will bring you pain.
>
>
> Michał
