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 <[email protected]> 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 <[email protected]> > wrote: > >> Hi Amit >> >> >> On Thu, Jul 23, 2015 at 11:09 PM, <[email protected]> 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 >> > [email protected] >> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > >> >> >> >> -- >> ---P.K.S >> > >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
