HI All,
I  facing CPU HALT issue on linux kernel 4.0.4 after running below
mentioned command:
#hostapd -B /etc/hostapd.conf


dump_stack:

[  335.262172] [<80013400>] (__irq_svc) from [<8043f524>]
(_raw_spin_unlock_irqrestore+0x20/0x54)
[  335.270975] [<8043f524>] (_raw_spin_unlock_irqrestore) from [<7f116820>]
(ieee80211_wake_queues_by_reason+0x88/0x90 [mac80211])
[  335.282669] [<7f116820>] (ieee80211_wake_queues_by_reason [mac80211])
from [<7f16e5ac>] (ath_complete_reset+0xdc/0x138 [ath9k])
[  335.294187] [<7f16e5ac>] (ath_complete_reset [ath9k]) from [<7f16e9ac>]
(ath_reset_internal+0x180/0x254 [ath9k])
[  335.304389] [<7f16e9ac>] (ath_reset_internal [ath9k]) from [<7f16eaa0>]
(ath_reset_work+0x20/0x40 [ath9k])
[  335.314062] [<7f16eaa0>] (ath_reset_work [ath9k]) from [<80036b18>]
(process_one_work+0x124/0x334)
[  335.323023] [<80036b18>] (process_one_work) from [<80037d60>]
(worker_thread+0x140/0x524)
[  335.331207] [<80037d60>] (worker_thread) from [<8003c040>]
(kthread+0xf4/0x108)
[  335.338524] [<8003c040>] (kthread) from [<8000ed40>]
(ret_from_fork+0x14/0x34)
[  335.345750] INFO: rcu_preempt detected stalls on CPUs/tasks:



This I m facing this issue with both hostadp version (0.7.3 and 2.4).


Thanks,
Amit Gupta




On Tue, Jul 28, 2015 at 11:45 PM, Amit Gupta [off-list ref] wrote:

Hi All,
Thanks for your quick response.

Valdis,
I tried with strace stuff, but I faced CPU halt issue. Actually along with
those error logs..sometime I m facing CPU HALT issue after executing
#hostapd -B /etc/hostapd.conf.



Pranay,
I tried your way to debug kernel for finding the root cause of error log 'Failed
to update rate sets in kernel module'.
But prior to that I started to debugging for

IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

those two logs.

Till now I found that before execution of __dev_open(net/core/dev,c) function
for 'wlan0' network interface, 'netif_carrier_off'(net/sched/sch_generic.c)
function get called for 'wlan0',

void netif_carrier_off <http://lxr.free-electrons.com/ident?v=4.0;i=netif_carrier_off>(struct net_device <http://lxr.free-electrons.com/ident?v=4.0;i=net_device> *dev <http://lxr.free-electrons.com/ident?v=4.0;i=dev>)
 {
         if (!test_and_set_bit <http://lxr.free-electrons.com/ident?v=4.0;i=test_and_set_bit>(__LINK_STATE_NOCARRIER, &dev <http://lxr.free-electrons.com/ident?v=4.0;i=dev>->state <http://lxr.free-electrons.com/ident?v=4.0;i=state>)) {
                 if (dev <http://lxr.free-electrons.com/ident?v=4.0;i=dev>->reg_state <http://lxr.free-electrons.com/ident?v=4.0;i=reg_state> == NETREG_UNINITIALIZED)
                         return;
                 atomic_inc <http://lxr.free-electrons.com/ident?v=4.0;i=atomic_inc>(&dev <http://lxr.free-electrons.com/ident?v=4.0;i=dev>->carrier_changes);
                 linkwatch_fire_event <http://lxr.free-electrons.com/ident?v=4.0;i=linkwatch_fire_event>(dev <http://lxr.free-electrons.com/ident?v=4.0;i=dev>);
         }
}

 which result into condition checking passed in 'addrconf_qdisc_ok
<http://lxr.free-electrons.com/ident?v=4.0;i=addrconf_qdisc_ok>'*
function.*

In 'net/ipv6/addrconf.c' file

if (event <http://lxr.free-electrons.com/ident?v=4.0;i=event> == NETDEV_UP <http://lxr.free-electrons.com/ident?v=4.0;i=NETDEV_UP>) {
                         if (!addrconf_qdisc_ok <http://lxr.free-electrons.com/ident?v=4.0;i=addrconf_qdisc_ok>(dev <http://lxr.free-electrons.com/ident?v=4.0;i=dev>)) {
                                 */* device is not ready yet. */*                                                       pr_info <http://lxr.free-electrons.com/ident?v=4.0;i=pr_info>(*"ADDRCONF(NETDEV_UP): %s: link is not ready\n"*,
                                        dev <http://lxr.free-electrons.com/ident?v=4.0;i=dev>->name <http://lxr.free-electrons.com/ident?v=4.0;i=name>);
                                 break;
                         }

in same file:

static inline bool <http://lxr.free-electrons.com/ident?v=4.0;i=bool> addrconf_qdisc_ok <http://lxr.free-electrons.com/ident?v=4.0;i=addrconf_qdisc_ok>(const struct net_device <http://lxr.free-electrons.com/ident?v=4.0;i=net_device> *dev <http://lxr.free-electrons.com/ident?v=4.0;i=dev>) {

return !qdisc_tx_is_noop <http://lxr.free-electrons.com/ident?v=4.0;i=qdisc_tx_is_noop>(dev <http://lxr.free-electrons.com/ident?v=4.0;i=dev>);

}

In include/net/sch_generic.h file

 static inline bool <http://lxr.free-electrons.com/ident?v=4.0;i=bool> qdisc_tx_is_noop <http://lxr.free-electrons.com/ident?v=4.0;i=qdisc_tx_is_noop>(const struct net_device <http://lxr.free-electrons.com/ident?v=4.0;i=net_device> *dev <http://lxr.free-electrons.com/ident?v=4.0;i=dev>)

 {

         unsigned int i <http://lxr.free-electrons.com/ident?v=4.0;i=i>;


         for (i <http://lxr.free-electrons.com/ident?v=4.0;i=i> = 0; i <http://lxr.free-electrons.com/ident?v=4.0;i=i> < dev <http://lxr.free-electrons.com/ident?v=4.0;i=dev>->num_tx_queues; i <http://lxr.free-electrons.com/ident?v=4.0;i=i>++) {
                 struct netdev_queue <http://lxr.free-electrons.com/ident?v=4.0;i=netdev_queue> *txq = netdev_get_tx_queue <http://lxr.free-electrons.com/ident?v=4.0;i=netdev_get_tx_queue>(dev <http://lxr.free-electrons.com/ident?v=4.0;i=dev>, i <http://lxr.free-electrons.com/ident?v=4.0;i=i>);
                 if (rcu_access_pointer <http://lxr.free-electrons.com/ident?v=4.0;i=rcu_access_pointer>(txq->qdisc) != &noop_qdisc <http://lxr.free-electrons.com/ident?v=4.0;i=noop_qdisc>)
                         return false <http://lxr.free-electrons.com/ident?v=4.0;i=false>;
         }
         return true <http://lxr.free-electrons.com/ident?v=4.0;i=true>;
 }


I am still looking to find the cause execution of net_carrier_off function
before execution of __dev_open function for 'wlan0' network interface. This
behavior I am not observing with my other wired and pseudo network
interfaces.

'Failed to update rate sets in kernel module'
This error log may come because of previous issue as wlan0 device is not
active till this point.


One more thing  I tried, I cross compiled 'hostapd' version 2.4 for my
target board and executed that on target board.I did not get above
mentioned error log and till now no CPU halt issue.

Previously i was working with hostapd 0.7.3.


So is it like, hostapd old version is not compatible with new linux kernel
version as hostapd 0.7.3 version is running with no issue at linux 3.4.

Any advice and suggestions will be appreciable/helpful.

Thanks,
Amit Gupta


On Fri, Jul 24, 2015 at 11:06 AM, Pranay Srivastava [off-list ref]
wrote:

quoted

Hi Amit


On Thu, Jul 23, 2015 at 11:09 PM,  [off-list ref] wrote:

quoted

On Thu, 23 Jul 2015 12:31:18 +0530, Amit Gupta said:

quoted

Configuration file: /etc/hostapd.conf
[  199.672712] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Failed to update rate sets in kernel module
[  199.687566] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Using interface wlan0 with hwaddr 00:0e:8e:38:29:e6 and ssid

'test_wifi_2'

quoted

quoted

Eventhough I am getting this error log from user space

application(hostapd)

quoted

quoted

code, my wifi device is working fine. But I want to remove this error

log

quoted

quoted

and want to know the root cause this error log.

My gut reaction is that hostapd is issuing ioctl() calls in the wrong

order

quoted

and/or failing to allow a long enough delay or wait for a specific

event.

quoted

I'd recommend running something like:

# strace -f hostapd -B /etc/hostapd.conf > /tmp/strace.out 2>&1

The driver gets notified of this change via netlink socks. I also face
the same issue and so far I found this

Hostapd calls
  --->i802_set_rate_sets

which then creates a nlmsg which is handled in driver as

--driver--
     -->nl80211_set_bss
               --->rdev_change_bss

now change_bss is defined as

ieee80211_change_bss (net/mac80211/cfg.c) unless ofcourse your driver
provides something else.

There seems to be no error from here.

So maybe it's the send_recv call in hostapd in function
i802_set_rate_sets? I'll look into it more.

quoted

and go look for what failing call was made just before the write call
that output 'Failed to update'.  Hopefully, tracing the flow of that
call will reveal a  kernel code path that output the 'link is not ready'
message.  Then you'll know what 'if (somecondition)' landed you in that
situation.

Knowing that, it will become a lot easier to figure out what happened.

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

--
        ---P.K.S

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150729/5ff0b6c5/attachment-0001.html