bss_info_change_notify warning (hacked 3.3.0-rc5+)

bss_info_change_notify warning (hacked 3.3.0-rc5+)

[Ben Greear]

This is with a somewhat hacked 3.3.0-rc5+.  Just
curious if this is a known problem.


Seems very reproducible on my system.


WARNING: at /home/greearb/git/linux-3.3.dev.y/net/mac80211/driver-ops.h:10 ieee80211_bss_info_change_noti)
Hardware name: To be filled by O.E.M.
Modules linked in: 8021q garp stp llc macvlan wanlink(PO) pktgen lockd arc4 joydev ppdev microcode serio_]
Pid: 1855, comm: hostapd Tainted: P         C O 3.3.0-rc5+ #7
Call Trace:
  [<ffffffff81036eda>] warn_slowpath_common+0x80/0x98
  [<ffffffff81036f07>] warn_slowpath_null+0x15/0x17
  [<ffffffffa02c0010>] ieee80211_bss_info_change_notify+0x15f/0x18c [mac80211]
  [<ffffffffa02d472d>] ieee80211_config_beacon+0x58/0x208 [mac80211]
  [<ffffffff8144773b>] ? __mutex_unlock_slowpath+0x10d/0x11f
  [<ffffffffa02d4936>] ieee80211_add_beacon+0x35/0xa4 [mac80211]
  [<ffffffffa01fd715>] nl80211_addset_beacon+0x317/0x34a [cfg80211]
  [<ffffffff813b5a08>] genl_rcv_msg+0x1f4/0x239
  [<ffffffff813b5814>] ? genl_rcv+0x28/0x28
  [<ffffffff813b4836>] netlink_rcv_skb+0x3e/0x8f
  [<ffffffff813b580d>] genl_rcv+0x21/0x28
  [<ffffffff813b4611>] netlink_unicast+0xe9/0x152
  [<ffffffff813b4d6a>] netlink_sendmsg+0x1f8/0x216
  [<ffffffff81384122>] __sock_sendmsg_nosec+0x5f/0x6a
  [<ffffffff8138416a>] __sock_sendmsg+0x3d/0x48
  [<ffffffff81384a0a>] sock_sendmsg+0xa3/0xbc
  [<ffffffff811d12c2>] ? blk_finish_plug+0x13/0x34
  [<ffffffff810a8b87>] ? generic_file_aio_write+0xa6/0xb6
  [<ffffffff81383b68>] ? copy_from_user+0x9/0xb
  [<ffffffff813846b2>] ? move_addr_to_kernel+0x2b/0x65
  [<ffffffff8138e909>] ? copy_from_user+0x9/0xb
  [<ffffffff8138ec56>] ? verify_iovec+0x4f/0xa3
  [<ffffffff8138516c>] __sys_sendmsg+0x20f/0x29c
  [<ffffffff8144c242>] ? sub_preempt_count+0x92/0xa6
  [<ffffffff81052ecf>] ? __srcu_read_unlock+0x3b/0x59
  [<ffffffff8111d9c0>] ? fsnotify+0x255/0x285
  [<ffffffff81385356>] sys_sendmsg+0x3d/0x5b
  [<ffffffff8144dfb9>] system_call_fastpath+0x16/0x1b
---[ end trace 7abcbdd8b95b5194 ]---

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: bss_info_change_notify warning (hacked 3.3.0-rc5+)

[Bryan Phillippe]

Yes, it's a known problem.  It's very reproducible for me on a non-hacked 3.3-rc1 as well: changing from AP to client mode, or setting up multiple APs, or changing from 2.4Ghz to 5Ghz all seem to trigger this warning with various stack traces.


--
-bp


On Mar 7, 2012, at 11:32 AM, Ben Greear wrote:

> This is with a somewhat hacked 3.3.0-rc5+.  Just
> curious if this is a known problem.
> 
> 
> Seems very reproducible on my system.
> 
> 
> WARNING: at /home/greearb/git/linux-3.3.dev.y/net/mac80211/driver-ops.h:10 ieee80211_bss_info_change_noti)
> Hardware name: To be filled by O.E.M.
> Modules linked in: 8021q garp stp llc macvlan wanlink(PO) pktgen lockd arc4 joydev ppdev microcode serio_]
> Pid: 1855, comm: hostapd Tainted: P         C O 3.3.0-rc5+ #7
> Call Trace:
> [<ffffffff81036eda>] warn_slowpath_common+0x80/0x98
> [<ffffffff81036f07>] warn_slowpath_null+0x15/0x17
> [<ffffffffa02c0010>] ieee80211_bss_info_change_notify+0x15f/0x18c [mac80211]
> [<ffffffffa02d472d>] ieee80211_config_beacon+0x58/0x208 [mac80211]
> [<ffffffff8144773b>] ? __mutex_unlock_slowpath+0x10d/0x11f
> [<ffffffffa02d4936>] ieee80211_add_beacon+0x35/0xa4 [mac80211]
> [<ffffffffa01fd715>] nl80211_addset_beacon+0x317/0x34a [cfg80211]
> [<ffffffff813b5a08>] genl_rcv_msg+0x1f4/0x239
> [<ffffffff813b5814>] ? genl_rcv+0x28/0x28
> [<ffffffff813b4836>] netlink_rcv_skb+0x3e/0x8f
> [<ffffffff813b580d>] genl_rcv+0x21/0x28
> [<ffffffff813b4611>] netlink_unicast+0xe9/0x152
> [<ffffffff813b4d6a>] netlink_sendmsg+0x1f8/0x216
> [<ffffffff81384122>] __sock_sendmsg_nosec+0x5f/0x6a
> [<ffffffff8138416a>] __sock_sendmsg+0x3d/0x48
> [<ffffffff81384a0a>] sock_sendmsg+0xa3/0xbc
> [<ffffffff811d12c2>] ? blk_finish_plug+0x13/0x34
> [<ffffffff810a8b87>] ? generic_file_aio_write+0xa6/0xb6
> [<ffffffff81383b68>] ? copy_from_user+0x9/0xb
> [<ffffffff813846b2>] ? move_addr_to_kernel+0x2b/0x65
> [<ffffffff8138e909>] ? copy_from_user+0x9/0xb
> [<ffffffff8138ec56>] ? verify_iovec+0x4f/0xa3
> [<ffffffff8138516c>] __sys_sendmsg+0x20f/0x29c
> [<ffffffff8144c242>] ? sub_preempt_count+0x92/0xa6
> [<ffffffff81052ecf>] ? __srcu_read_unlock+0x3b/0x59
> [<ffffffff8111d9c0>] ? fsnotify+0x255/0x285
> [<ffffffff81385356>] sys_sendmsg+0x3d/0x5b
> [<ffffffff8144dfb9>] system_call_fastpath+0x16/0x1b
> ---[ end trace 7abcbdd8b95b5194 ]---
> 
> -- 
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bss_info_change_notify warning (hacked 3.3.0-rc5+)

[Johannes Berg]

On Wed, 2012-03-07 at 11:32 -0800, Ben Greear wrote:
> This is with a somewhat hacked 3.3.0-rc5+.  Just
> curious if this is a known problem.
> 
> 
> Seems very reproducible on my system.
> 
> 
> WARNING: at /home/greearb/git/linux-3.3.dev.y/net/mac80211/driver-ops.h:10 ieee80211_bss_info_change_noti)

The warning means you're modifying an interface the driver doesn't (yet)
know about.

It's odd that you should be running into this on config_beacon() though
since that can only execute when the interface is up ... can you print
out the interface name in the warning?

johannes

Re: bss_info_change_notify warning (hacked 3.3.0-rc5+)

[Ben Greear]

On 03/07/2012 10:55 PM, Johannes Berg wrote:
> On Wed, 2012-03-07 at 11:32 -0800, Ben Greear wrote:
>> This is with a somewhat hacked 3.3.0-rc5+.  Just
>> curious if this is a known problem.
>>
>>
>> Seems very reproducible on my system.
>>
>>
>> WARNING: at /home/greearb/git/linux-3.3.dev.y/net/mac80211/driver-ops.h:10 ieee80211_bss_info_change_noti)
>
> The warning means you're modifying an interface the driver doesn't (yet)
> know about.
>
> It's odd that you should be running into this on config_beacon() though
> since that can only execute when the interface is up ... can you print
> out the interface name in the warning?

This is still reproducible in 3.3.0-rc6+ from yesterday.


I create the VAP with this command:

./local/sbin/iw phy wiphy0 interface add vap0 type __ap


vap0:  Failed check-sdata-in-driver check, flags: 0x0
------------[ cut here ]------------
WARNING: at /home/greearb/git/linux-3.3.dev.y/net/mac80211/driver-ops.h:13 check_sdata_in_driver+0x35/0x3)
Hardware name: To be filled by O.E.M.
Modules linked in: 8021q garp stp llc macvlan wanlink(PO) pktgen lockd joydev ppdev arc4 snd_hda_codec_re]
Pid: 3081, comm: hostapd Tainted: P        WC O 3.3.0-rc6+ #7
Call Trace:
  [<ffffffff81036f45>] warn_slowpath_common+0x80/0x98
  [<ffffffff81036f72>] warn_slowpath_null+0x15/0x17
  [<ffffffffa025b503>] check_sdata_in_driver+0x35/0x37 [mac80211]
  [<ffffffffa025bfcd>] ieee80211_set_txq_params+0x91/0xf4 [mac80211]
  [<ffffffffa019eaf9>] nl80211_set_wiphy+0x1f2/0x500 [cfg80211]
  [<ffffffff81447a9e>] ? __mutex_lock_slowpath+0x16/0x18
  [<ffffffffa00703ff>] ? i915_restore_palette+0x93/0xdd [i915]
  [<ffffffff813b5c00>] genl_rcv_msg+0x1f4/0x239
  [<ffffffff813b5a0c>] ? genl_rcv+0x28/0x28
  [<ffffffff813b4a2e>] netlink_rcv_skb+0x3e/0x8f
  [<ffffffff813b5a05>] genl_rcv+0x21/0x28
  [<ffffffff813b4809>] netlink_unicast+0xe9/0x152
  [<ffffffff813b4f62>] netlink_sendmsg+0x1f8/0x216
  [<ffffffff81384202>] __sock_sendmsg_nosec+0x5f/0x6a
  [<ffffffff8138424a>] __sock_sendmsg+0x3d/0x48
  [<ffffffff81384aea>] sock_sendmsg+0xa3/0xbc
  [<ffffffff810a81f7>] ? unlock_page+0x25/0x2a
  [<ffffffff810c2a40>] ? __do_fault+0x373/0x3b6
  [<ffffffff81383c48>] ? copy_from_user+0x9/0xb
  [<ffffffff81384792>] ? move_addr_to_kernel+0x2b/0x65
  [<ffffffff8138e9e9>] ? copy_from_user+0x9/0xb
  [<ffffffff8138ed36>] ? verify_iovec+0x4f/0xa3
  [<ffffffff8138524c>] __sys_sendmsg+0x20f/0x29c
  [<ffffffff81383799>] ? sock_destroy_inode+0x2e/0x32
  [<ffffffff8110503b>] ? destroy_inode+0x3b/0x54
  [<ffffffff810dec6f>] ? virt_to_head_page+0x9/0x2c
  [<ffffffff810e0e73>] ? kmem_cache_free+0x15/0x6e
  [<ffffffff8144c782>] ? sub_preempt_count+0x92/0xa6
  [<ffffffff81108894>] ? vfsmount_lock_local_unlock+0x46/0x53
  [<ffffffff8110934e>] ? mntput_no_expire+0x31/0x104
  [<ffffffff81109446>] ? mntput+0x25/0x27
  [<ffffffff81385436>] sys_sendmsg+0x3d/0x5b
  [<ffffffff8144e4f9>] system_call_fastpath+0x16/0x1b
---[ end trace 54cbe076448eb2c8 ]---

>
> johannes


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: bss_info_change_notify warning (hacked 3.3.0-rc5+)

[Johannes Berg]

On Fri, 2012-03-09 at 10:31 -0800, Ben Greear wrote:
> On 03/07/2012 10:55 PM, Johannes Berg wrote:
> > On Wed, 2012-03-07 at 11:32 -0800, Ben Greear wrote:
> >> This is with a somewhat hacked 3.3.0-rc5+.  Just
> >> curious if this is a known problem.
> >>
> >>
> >> Seems very reproducible on my system.
> >>
> >>
> >> WARNING: at /home/greearb/git/linux-3.3.dev.y/net/mac80211/driver-ops.h:10 ieee80211_bss_info_change_noti)
> >
> > The warning means you're modifying an interface the driver doesn't (yet)
> > know about.
> >
> > It's odd that you should be running into this on config_beacon() though
> > since that can only execute when the interface is up ... can you print
> > out the interface name in the warning?
> 
> This is still reproducible in 3.3.0-rc6+ from yesterday.
> 
> 
> I create the VAP with this command:
> 
> ./local/sbin/iw phy wiphy0 interface add vap0 type __ap
> 
> 
> vap0:  Failed check-sdata-in-driver check, flags: 0x0

That's it? That doesn't create a warning here, and somehow you're
running into nl80211_set_wiphy() which isn't called if you execute just
that iw command.

johannes

Re: bss_info_change_notify warning (hacked 3.3.0-rc5+)

[Ben Greear]

On 03/12/2012 12:10 AM, Johannes Berg wrote:
> On Fri, 2012-03-09 at 10:31 -0800, Ben Greear wrote:
>> On 03/07/2012 10:55 PM, Johannes Berg wrote:
>>> On Wed, 2012-03-07 at 11:32 -0800, Ben Greear wrote:
>>>> This is with a somewhat hacked 3.3.0-rc5+.  Just
>>>> curious if this is a known problem.
>>>>
>>>>
>>>> Seems very reproducible on my system.
>>>>
>>>>
>>>> WARNING: at /home/greearb/git/linux-3.3.dev.y/net/mac80211/driver-ops.h:10 ieee80211_bss_info_change_noti)
>>>
>>> The warning means you're modifying an interface the driver doesn't (yet)
>>> know about.
>>>
>>> It's odd that you should be running into this on config_beacon() though
>>> since that can only execute when the interface is up ... can you print
>>> out the interface name in the warning?
>>
>> This is still reproducible in 3.3.0-rc6+ from yesterday.
>>
>>
>> I create the VAP with this command:
>>
>> ./local/sbin/iw phy wiphy0 interface add vap0 type __ap
>>
>>
>> vap0:  Failed check-sdata-in-driver check, flags: 0x0
>
> That's it? That doesn't create a warning here, and somehow you're
> running into nl80211_set_wiphy() which isn't called if you execute just
> that iw command.

Well, there's a lot of other stuff going on too.  Power is set, for one
thing, hostapd is started, etc.

I will see if I can come up with a easy way to reproduce this, but
it might be a few days as I'm stacked up with work at the moment.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: bss_info_change_notify warning (hacked 3.3.0-rc5+)

[Ben Greear]

On 03/07/2012 11:45 AM, Bryan Phillippe wrote:
>
> Yes, it's a known problem.  It's very reproducible for me on a non-hacked 3.3-rc1 as well: changing from AP to client mode, or setting up multiple APs, or changing from 2.4Ghz to 5Ghz all seem to trigger this warning with various stack traces.

I'm still seeing this and related warnings on 3.3.0.  At least some
of them comes from calls the 'hostapd' process makes (I printed
current->comm in the warning).

I am not having luck writing a simple script that reproduce this,
but my application that creates a VAP and bunch of virtual station
hits it every time on startup.

Bryan:  Do you have a simple script that reproduces this problem?

Johannes:  Any ideas on likely causes of this problem?  Might help
me zero in on the problem quicker...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: bss_info_change_notify warning (hacked 3.3.0-rc5+)

[Johannes Berg]

On Wed, 2012-03-28 at 11:56 -0700, Ben Greear wrote:
> On 03/07/2012 11:45 AM, Bryan Phillippe wrote:
> >
> > Yes, it's a known problem.  It's very reproducible for me on a non-hacked 3.3-rc1 as well: changing from AP to client mode, or setting up multiple APs, or changing from 2.4Ghz to 5Ghz all seem to trigger this warning with various stack traces.
> 
> I'm still seeing this and related warnings on 3.3.0.  At least some
> of them comes from calls the 'hostapd' process makes (I printed
> current->comm in the warning).
> 
> I am not having luck writing a simple script that reproduce this,
> but my application that creates a VAP and bunch of virtual station
> hits it every time on startup.
> 
> Bryan:  Do you have a simple script that reproduces this problem?
> 
> Johannes:  Any ideas on likely causes of this problem?  Might help
> me zero in on the problem quicker...

Hm. Maybe this is the problem?

http://p.sipsolutions.net/d432de678ae3ff17.txt

johannes

Re: bss_info_change_notify warning (hacked 3.3.0-rc5+)

[Ben Greear]

On 03/28/2012 11:59 AM, Johannes Berg wrote:
> On Wed, 2012-03-28 at 11:56 -0700, Ben Greear wrote:
>> On 03/07/2012 11:45 AM, Bryan Phillippe wrote:
>>>
>>> Yes, it's a known problem.  It's very reproducible for me on a non-hacked 3.3-rc1 as well: changing from AP to client mode, or setting up multiple APs, or changing from 2.4Ghz to 5Ghz all seem to trigger this warning with various stack traces.
>>
>> I'm still seeing this and related warnings on 3.3.0.  At least some
>> of them comes from calls the 'hostapd' process makes (I printed
>> current->comm in the warning).
>>
>> I am not having luck writing a simple script that reproduce this,
>> but my application that creates a VAP and bunch of virtual station
>> hits it every time on startup.
>>
>> Bryan:  Do you have a simple script that reproduces this problem?
>>
>> Johannes:  Any ideas on likely causes of this problem?  Might help
>> me zero in on the problem quicker...
>
> Hm. Maybe this is the problem?
>
> http://p.sipsolutions.net/d432de678ae3ff17.txt

I don't see any code that matches that in 3.3.0 (nothing with nl80211_start_ap, for instance)

Thanks,
Ben

>
> johannes


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: bss_info_change_notify warning (hacked 3.3.0-rc5+)

[Johannes Berg]

On Wed, 2012-03-28 at 12:10 -0700, Ben Greear wrote:
> On 03/28/2012 11:59 AM, Johannes Berg wrote:
> > On Wed, 2012-03-28 at 11:56 -0700, Ben Greear wrote:
> >> On 03/07/2012 11:45 AM, Bryan Phillippe wrote:
> >>>
> >>> Yes, it's a known problem.  It's very reproducible for me on a non-hacked 3.3-rc1 as well: changing from AP to client mode, or setting up multiple APs, or changing from 2.4Ghz to 5Ghz all seem to trigger this warning with various stack traces.
> >>
> >> I'm still seeing this and related warnings on 3.3.0.  At least some
> >> of them comes from calls the 'hostapd' process makes (I printed
> >> current->comm in the warning).
> >>
> >> I am not having luck writing a simple script that reproduce this,
> >> but my application that creates a VAP and bunch of virtual station
> >> hits it every time on startup.
> >>
> >> Bryan:  Do you have a simple script that reproduces this problem?
> >>
> >> Johannes:  Any ideas on likely causes of this problem?  Might help
> >> me zero in on the problem quicker...
> >
> > Hm. Maybe this is the problem?
> >
> > http://p.sipsolutions.net/d432de678ae3ff17.txt
> 
> I don't see any code that matches that in 3.3.0 (nothing with nl80211_start_ap, for instance)

ah, well, it's set_beacon there or so

johannes

Re: bss_info_change_notify warning (hacked 3.3.0-rc5+)

[Ben Greear]

On 03/28/2012 12:13 PM, Johannes Berg wrote:
> On Wed, 2012-03-28 at 12:10 -0700, Ben Greear wrote:
>> On 03/28/2012 11:59 AM, Johannes Berg wrote:

>>> Hm. Maybe this is the problem?
>>>
>>> http://p.sipsolutions.net/d432de678ae3ff17.txt
>>
>> I don't see any code that matches that in 3.3.0 (nothing with nl80211_start_ap, for instance)
>
> ah, well, it's set_beacon there or so
>
> johannes


I tried this patch, but it still spews (see below)

[greearb@build-32 mac80211]$ git diff
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 56a363f..c4f5f82 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6313,7 +6313,7 @@ static struct genl_ops nl80211_ops[] = {
                 .policy = nl80211_policy,
                 .flags = GENL_ADMIN_PERM,
                 .doit = nl80211_addset_beacon,
-               .internal_flags = NL80211_FLAG_NEED_NETDEV |
+               .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
                                   NL80211_FLAG_NEED_RTNL,
         },
         {
@@ -6321,7 +6321,7 @@ static struct genl_ops nl80211_ops[] = {
                 .policy = nl80211_policy,
                 .flags = GENL_ADMIN_PERM,
                 .doit = nl80211_addset_beacon,
-               .internal_flags = NL80211_FLAG_NEED_NETDEV |
+               .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
                                   NL80211_FLAG_NEED_RTNL,
         },
         {



ieee80211 wiphy0: device now idle
ADDRCONF(NETDEV_UP): wlan0: link is not ready
cfg80211: Calling CRDA for country: US
cfg80211: Regulatory domain changed to country: US
cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
cfg80211:   (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
ADDRCONF(NETDEV_UP): wlan0: link is not ready
ADDRCONF(NETDEV_UP): sta1: link is not ready
ADDRCONF(NETDEV_UP): sta1: link is not ready
ADDRCONF(NETDEV_UP): sta0: link is not ready
ADDRCONF(NETDEV_UP): sta0: link is not ready
ADDRCONF(NETDEV_UP): sta4: link is not ready
ADDRCONF(NETDEV_UP): sta4: link is not ready
ADDRCONF(NETDEV_UP): sta3: link is not ready
ADDRCONF(NETDEV_UP): sta3: link is not ready
ADDRCONF(NETDEV_UP): sta2: link is not ready
ADDRCONF(NETDEV_UP): sta2: link is not ready
ieee80211 wiphy0: device no longer idle - in use
ieee80211 wiphy0: device now idle
------------[ cut here ]------------
WARNING: at /home/greearb/git/linux-3.3.dev.y/net/mac80211/driver-ops.h:12 check_sdata_in_driver+0x26/0x2b [mac80211]()
Hardware name: To Be Filled By O.E.M.
vap0:  Failed check-sdata-in-driver check, flags: 0x0
Modules linked in: ath5k arc4 ath9k mac80211 ath9k_common ath9k_hw ath cfg80211 xt_CT iptable_raw 8021q garp stp llc macvlan wanlink(PO) pktgen fuse w83627ehf 
hwmon_vid coretemp hwmon nfs lockd fscache auth_rpcgss nfs_acl sunrpc ipv6 uinput snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq 
snd_seq_device snd_pcm microcode iTCO_wdt pcspkr i2c_i801 serio_raw iTCO_vendor_support snd_timer r8169 snd soundcore mii snd_page_alloc i915 drm_kms_helper drm 
i2c_algo_bit video [last unloaded: arc4]
Pid: 7307, comm: hostapd Tainted: P        W  O 3.3.0+ #41
Call Trace:
  [<c04263d1>] warn_slowpath_common+0x65/0x7a
  [<f96a28d1>] ? check_sdata_in_driver+0x26/0x2b [mac80211]
  [<c042644a>] warn_slowpath_fmt+0x26/0x2a
  [<f96a28d1>] check_sdata_in_driver+0x26/0x2b [mac80211]
  [<f96a3438>] ieee80211_set_txq_params+0x97/0xec [mac80211]
  [<c059edb5>] ? nla_parse+0x3f/0x98
  [<f9556c74>] nl80211_set_wiphy+0x1cb/0x4ba [cfg80211]
  [<c07264ef>] genl_rcv_msg+0x1ce/0x200
  [<c0726321>] ? genl_rcv+0x22/0x22
  [<c0725567>] netlink_rcv_skb+0x30/0x76
  [<c072631a>] genl_rcv+0x1b/0x22
  [<c07253a3>] netlink_unicast+0xc1/0x11c
  [<c07259fe>] netlink_sendmsg+0x1d2/0x1ea
  [<c06fe57e>] __sock_sendmsg_nosec+0x4a/0x52
  [<c06fe5b0>] __sock_sendmsg+0x2a/0x33
  [<c06fead5>] sock_sendmsg+0x93/0xa7
  [<c06fead5>] ? sock_sendmsg+0x93/0xa7
  [<c0488b26>] ? __generic_file_aio_write+0x24c/0x27d
  [<c05945bd>] ? _copy_from_user+0x31/0x118
  [<c07069ec>] ? copy_from_user+0x8/0xa
  [<c0706ce6>] ? verify_iovec+0x3e/0x78
  [<c06ff4ea>] __sys_sendmsg+0x18d/0x20b
  [<c070b265>] ? dev_name_hash+0x1e/0x31
  [<c05944b6>] ? copy_to_user+0x2f/0x105
  [<c070e88a>] ? dev_ioctl+0x417/0x56a
  [<c04b19ea>] ? kmem_cache_alloc+0x24/0x99
  [<c0702e39>] ? sk_prot_alloc+0x23/0xd1
  [<c07a9164>] ? _raw_spin_unlock+0x8/0xa
  [<c06fe0df>] ? sock_destroy_inode+0x23/0x26
  [<c06fe0df>] ? sock_destroy_inode+0x23/0x26
  [<c04ccd36>] ? __d_free+0x3c/0x3f
  [<c04ccd36>] ? __d_free+0x3c/0x3f
  [<c06ff667>] sys_sendmsg+0x2b/0x43
  [<c070053e>] sys_socketcall+0x16a/0x1d4
  [<c0471d68>] ? __audit_syscall_exit+0x102/0x117
  [<c07adb58>] sysenter_do_call+0x12/0x28
---[ end trace dec15cdc90696e7d ]---


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: bss_info_change_notify warning (hacked 3.3.0-rc5+)

[Johannes Berg]

On Wed, 2012-03-28 at 12:45 -0700, Ben Greear wrote:
> On 03/28/2012 12:13 PM, Johannes Berg wrote:
> > On Wed, 2012-03-28 at 12:10 -0700, Ben Greear wrote:
> >> On 03/28/2012 11:59 AM, Johannes Berg wrote:
> 
> >>> Hm. Maybe this is the problem?
> >>>
> >>> http://p.sipsolutions.net/d432de678ae3ff17.txt
> >>
> >> I don't see any code that matches that in 3.3.0 (nothing with nl80211_start_ap, for instance)
> >
> > ah, well, it's set_beacon there or so
> >
> > johannes
> 
> 
> I tried this patch, but it still spews (see below)

> WARNING: at /home/greearb/git/linux-3.3.dev.y/net/mac80211/driver-ops.h:12 check_sdata_in_driver+0x26/0x2b [mac80211]()

>   [<c04263d1>] warn_slowpath_common+0x65/0x7a
>   [<f96a28d1>] ? check_sdata_in_driver+0x26/0x2b [mac80211]
>   [<c042644a>] warn_slowpath_fmt+0x26/0x2a
>   [<f96a28d1>] check_sdata_in_driver+0x26/0x2b [mac80211]
>   [<f96a3438>] ieee80211_set_txq_params+0x97/0xec [mac80211]

but now it's coming from elsewhere, see this patch?

http://p.sipsolutions.net/b8506c9d7ce8a119.txt

johannes

Re: bss_info_change_notify warning (hacked 3.3.0-rc5+)

[Ben Greear]

On 03/28/2012 11:38 PM, Johannes Berg wrote:
> On Wed, 2012-03-28 at 12:45 -0700, Ben Greear wrote:
>> On 03/28/2012 12:13 PM, Johannes Berg wrote:
>>> On Wed, 2012-03-28 at 12:10 -0700, Ben Greear wrote:
>>>> On 03/28/2012 11:59 AM, Johannes Berg wrote:
>>
>>>>> Hm. Maybe this is the problem?
>>>>>
>>>>> http://p.sipsolutions.net/d432de678ae3ff17.txt
>>>>
>>>> I don't see any code that matches that in 3.3.0 (nothing with nl80211_start_ap, for instance)
>>>
>>> ah, well, it's set_beacon there or so
>>>
>>> johannes
>>
>>
>> I tried this patch, but it still spews (see below)
>
>> WARNING: at /home/greearb/git/linux-3.3.dev.y/net/mac80211/driver-ops.h:12 check_sdata_in_driver+0x26/0x2b [mac80211]()
>
>>    [<c04263d1>] warn_slowpath_common+0x65/0x7a
>>    [<f96a28d1>] ? check_sdata_in_driver+0x26/0x2b [mac80211]
>>    [<c042644a>] warn_slowpath_fmt+0x26/0x2a
>>    [<f96a28d1>] check_sdata_in_driver+0x26/0x2b [mac80211]
>>    [<f96a3438>] ieee80211_set_txq_params+0x97/0xec [mac80211]
>
> but now it's coming from elsewhere, see this patch?
>
> http://p.sipsolutions.net/b8506c9d7ce8a119.txt

That fixes the problem for me, or at least the easily-reproducible part.

I did have to modify the patch to work on 3.3.0 since it has no start_ap
and the beacon method is named a bit differently.

I'm going to apply this to my patch set and will let you know if
I see anything else strange.

Thanks!
Ben

>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: bss_info_change_notify warning (hacked 3.3.0-rc5+)

[Johannes Berg]

On Thu, 2012-03-29 at 09:09 -0700, Ben Greear wrote:
> On 03/28/2012 11:38 PM, Johannes Berg wrote:
> > On Wed, 2012-03-28 at 12:45 -0700, Ben Greear wrote:
> >> On 03/28/2012 12:13 PM, Johannes Berg wrote:
> >>> On Wed, 2012-03-28 at 12:10 -0700, Ben Greear wrote:
> >>>> On 03/28/2012 11:59 AM, Johannes Berg wrote:
> >>
> >>>>> Hm. Maybe this is the problem?
> >>>>>
> >>>>> http://p.sipsolutions.net/d432de678ae3ff17.txt
> >>>>
> >>>> I don't see any code that matches that in 3.3.0 (nothing with nl80211_start_ap, for instance)
> >>>
> >>> ah, well, it's set_beacon there or so
> >>>
> >>> johannes
> >>
> >>
> >> I tried this patch, but it still spews (see below)
> >
> >> WARNING: at /home/greearb/git/linux-3.3.dev.y/net/mac80211/driver-ops.h:12 check_sdata_in_driver+0x26/0x2b [mac80211]()
> >
> >>    [<c04263d1>] warn_slowpath_common+0x65/0x7a
> >>    [<f96a28d1>] ? check_sdata_in_driver+0x26/0x2b [mac80211]
> >>    [<c042644a>] warn_slowpath_fmt+0x26/0x2a
> >>    [<f96a28d1>] check_sdata_in_driver+0x26/0x2b [mac80211]
> >>    [<f96a3438>] ieee80211_set_txq_params+0x97/0xec [mac80211]
> >
> > but now it's coming from elsewhere, see this patch?
> >
> > http://p.sipsolutions.net/b8506c9d7ce8a119.txt
> 
> That fixes the problem for me, or at least the easily-reproducible part.
> 
> I did have to modify the patch to work on 3.3.0 since it has no start_ap
> and the beacon method is named a bit differently.
> 
> I'm going to apply this to my patch set and will let you know if
> I see anything else strange.

Ok, I'll send all of this upstream too. I'll add Cc: stable, and when I
need a patch to apply to stable I might ask you for yours then :)

johannes

Re: bss_info_change_notify warning (hacked 3.3.0-rc5+)

[Bryan Phillippe]

On Mar 28, 2012, at 11:56 AM, Ben Greear wrote:

> On 03/07/2012 11:45 AM, Bryan Phillippe wrote:
>> 
>> Yes, it's a known problem.  It's very reproducible for me on a non-hacked 3.3-rc1 as well: changing from AP to client mode, or setting up multiple APs, or changing from 2.4Ghz to 5Ghz all seem to trigger this warning with various stack traces.
> 
> I'm still seeing this and related warnings on 3.3.0.  At least some
> of them comes from calls the 'hostapd' process makes (I printed
> current->comm in the warning).
> 
> I am not having luck writing a simple script that reproduce this,
> but my application that creates a VAP and bunch of virtual station
> hits it every time on startup.
> 
> Bryan:  Do you have a simple script that reproduces this problem?

Hi Ben.  I apologize for the delay in responding; I was out of town
for a week.  No, I do not.  Which is frustrating, because it was
happening pretty reliably for me before, but it's much more
difficult to force to happen now.  In the past, it was switching
back and forth between AP and client mode (kill hostapd, start
wpa_supplicant, for example).  Or restarting hostapd frequently
in different radio modes.

> Johannes:  Any ideas on likely causes of this problem?  Might help
> me zero in on the problem quicker...

If I've been following the thread accurately, it looks like some
headway has been made on this and some fixes checked in?  I'd like
to retest, if that is the case.  I'm using compat-wireless trees
downloaded as tarballs - do you have a version you recommend I test
with?

Thanks,
--
-bp