Re: HOSTAPD Error log

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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(struct net_device *dev)
 {
         if (!test_and_set_bit(__LINK_STATE_NOCARRIER, &dev->state)) {
                 if (dev->reg_state == NETREG_UNINITIALIZED)
                         return;
                 atomic_inc(&dev->carrier_changes);
                 linkwatch_fire_event(dev);
         }
}
 which result into condition checking passed in 'addrconf_qdisc_ok'  function.

In 'net/ipv6/addrconf.c' file
if (event == NETDEV_UP) {
                         if (!addrconf_qdisc_ok(dev)) {
                                 /* device is not ready yet. */                                                       pr_info("ADDRCONF(NETDEV_UP): %s: link is not ready\n",
                                        dev->name);
                                 break;
                         }
in same file: 
static inline bool addrconf_qdisc_ok(const struct net_device *dev) {
return !qdisc_tx_is_noop(dev);
}
In include/net/sch_generic.h file
 static inline bool qdisc_tx_is_noop(const struct net_device *dev)
 {
         unsigned int i;
 
         for (i = 0; i < dev->num_tx_queues; i++) {
                 struct netdev_queue *txq = netdev_get_tx_queue(dev, i);
                 if (rcu_access_pointer(txq->qdisc) != &noop_qdisc)
                         return false;
         }
         return 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@xxxxxxxxx> wrote:
Hi Amit


On Thu, Jul 23, 2015 at 11:09 PM,  <Valdis.Kletnieks@xxxxxx> 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@xxxxxxxxxxxxxxxxx
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



--
        ---P.K.S


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

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux