bss_info_change_notify warning (hacked 3.3.0-rc5+)

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 ]---

Signature · 7 lines

Ben Greear <[email protected]>
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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.

Quoted 2 lines · 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.

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...

Quoted 12 lines · Ben Greear

Quoted 2 lines · 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.

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.

Quoted 4 lines

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

Quoted 15 lines · Johannes Berg

Quoted 14 lines · Ben Greear

Quoted 2 lines · 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.

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?

Quoted 6 lines

Quoted 2 lines

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)

Quoted 4 lines · Ben Greear

Quoted 2 lines · Johannes Berg

Hm. Maybe this is the problem?

Quoted 3 lines

Quoted 1 line

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

Quoted 5 lines · Johannes Berg

Quoted 4 lines · Ben Greear

Quoted 2 lines · Johannes Berg

Hm. Maybe this is the problem?

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

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]

Quoted 17 lines · Ben Greear

Quoted 5 lines · Johannes Berg

Quoted 4 lines · Ben Greear

Quoted 2 lines · Johannes Berg

Hm. Maybe this is the problem?

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

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)

Quoted 7 lines

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

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

Quoted 26 lines · Johannes Berg

Quoted 17 lines · Ben Greear

Quoted 5 lines · Johannes Berg

Quoted 4 lines · Ben Greear

Quoted 2 lines · Johannes Berg

Hm. Maybe this is the problem?

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

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)

Quoted 7 lines

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]

Quoted 3 lines

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.

Quoted 2 lines · 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.

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...

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)

Quoted 7 lines · 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.

Quoted 1 line

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

Quoted 8 lines · Johannes Berg

Quoted 7 lines · 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.

Quoted 8 lines

Quoted 1 line

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

Quoted 23 lines · Ben Greear

Quoted 8 lines · Johannes Berg

Quoted 7 lines · 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.

Quoted 8 lines

Quoted 1 line

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:

Quoted 4 lines

./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.