HOSTAPD Error log
Amit Gupta
amitkgupta09 at gmail.com
Wed Jul 29 09:34:51 EDT 2015
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 <amitkgupta09 at gmail.com> 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 <pranjas at gmail.com>
> wrote:
>
>> Hi Amit
>>
>>
>> On Thu, Jul 23, 2015 at 11:09 PM, <Valdis.Kletnieks at vt.edu> wrote:
>> > On Thu, 23 Jul 2015 12:31:18 +0530, Amit Gupta said:
>> >
>> >> 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'
>> >>
>> >>
>> >> Eventhough I am getting this error log from user space
>> application(hostapd)
>> >> code, my wifi device is working fine. But I want to remove this error
>> log
>> >> and want to know the root cause this error log.
>> >
>> > My gut reaction is that hostapd is issuing ioctl() calls in the wrong
>> order
>> > and/or failing to allow a long enough delay or wait for a specific
>> event.
>> >
>> > 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.
>>
>> >
>> > 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
More information about the Kernelnewbies
mailing list