regression after, " ath9k_htc: Add support for mesh interfaces"

regression after, " ath9k_htc: Add support for mesh interfaces"

[Oleksij Rempel]

Hi Javier,

i warning after patch "ath9k_htc: Add support for mesh interfaces".
I get this warning only on pc with CONFIG_MAC80211_MESH not set. 
Probably you missed config check some where.

commit 594e65b633e0b76db1d8e7359e4efb2d60fba20d
Author: Javier Cardona <javier@cozybit.com>
Date:   Wed May 8 10:16:46 2013 -0700

     ath9k_htc: Add support for mesh interfaces

     More specifically, enable AP-style beaconing on mesh
     ifaces and change the hw capabilities to reflect mesh
     support.

     Coexistence with a virtual STA interface was tested as
     working fine.

     Signed-off-by: Javier Cardona <javier@cozybit.com>
     [rebase, add iface combinations]
     Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
     Signed-off-by: John W. Linville <linville@tuxdriver.com>
-- 
Regards,
Oleksij

Re: regression after, " ath9k_htc: Add support for mesh interfaces"

[Thomas Pedersen]

On Fri, Jun 21, 2013 at 9:56 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Hi Javier,
>
> i warning after patch "ath9k_htc: Add support for mesh interfaces".
> I get this warning only on pc with CONFIG_MAC80211_MESH not set. Probably
> you missed config check some where.

Where do you hit the warning?

--
Thomas

Re: regression after, " ath9k_htc: Add support for mesh interfaces"

[Oleksij Rempel]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

Am 25.06.2013 02:54, schrieb Thomas Pedersen:
> On Fri, Jun 21, 2013 at 9:56 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>> Hi Javier,
>>
>> i warning after patch "ath9k_htc: Add support for mesh interfaces".
>> I get this warning only on pc with CONFIG_MAC80211_MESH not set. Probably
>> you missed config check some where.
>
> Where do you hit the warning?
>

on adapter init.
see attachment.
-- 
Regards,
Oleksij

[-- Attachment #2: log --]
[-- Type: text/plain, Size: 3486 bytes --]

[32344.392947] usb 2-5: ath9k_htc: Firmware htc_9271.fw requested
[32344.393141] usbcore: registered new interface driver ath9k_htc
[32344.720343] usb 2-5: ath9k_htc: Transferred FW: htc_9271.fw, size: 51000
[32344.958084] ath9k_htc 2-5:1.0: ath9k_htc: HTC initialized with 33 credits
[32345.146220] ath9k_htc 2-5:1.0: ath9k_htc: FW Version: 1.4
[32345.146224] ath: EEPROM regdomain: 0x809c
[32345.146226] ath: EEPROM indicates we should expect a country code
[32345.146228] ath: doing EEPROM country->regdmn map search
[32345.146229] ath: country maps to regdmn code: 0x52
[32345.146232] ath: Country alpha2 being used: CN
[32345.146233] ath: Regpair used: 0x52
[32345.146279] ------------[ cut here ]------------
[32345.146295] WARNING: at /home/lex/tmp/lin/linux/net/wireless/core.c:429 wiphy_register+0x4c0/0x502 [cfg80211]()
[32345.146297] Modules linked in: ath9k_htc ftdi_sio vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) bnep rfcomm bluetooth binfmt_misc snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec arc4 snd_hwdep ath9k ath9k_common ath9k_hw snd_pcm_oss snd_mixer_oss snd_pcm ath mac80211 snd_page_alloc snd_seq_dummy snd_seq_oss snd_seq_midi coretemp cfg80211 kvm_intel snd_rawmidi usb_storage kvm snd_seq_midi_event snd_seq firewire_ohci snd_seq_device firewire_core crc_itu_t lpc_ich mfd_core serio_raw sr_mod cdrom snd_timer snd soundcore
[32345.146335] CPU: 0 PID: 5867 Comm: kworker/0:2 Tainted: G           O 3.10.0-rc4-wl-dirty #194
[32345.146337] Hardware name:                  /DG45ID, BIOS IDG4510H.86A.0135.2011.0225.1100 02/25/2011
[32345.146343] Workqueue: events request_firmware_work_func
[32345.146345]  0000000000000000 ffff88011298dbf0 ffffffff8152a065 ffff88011298dc28
[32345.146349]  ffffffff81042dd7 0000000000000000 ffff88011a3e0200 ffff88011a3e0000
[32345.146353]  00000000ffffffea 000000000000035e ffff88011298dc38 ffffffff81042e09
[32345.146357] Call Trace:
[32345.146363]  [<ffffffff8152a065>] dump_stack+0x19/0x1b
[32345.146368]  [<ffffffff81042dd7>] warn_slowpath_common+0x65/0x7d
[32345.146372]  [<ffffffff81042e09>] warn_slowpath_null+0x1a/0x1c
[32345.146380]  [<ffffffffa01dbd50>] wiphy_register+0x4c0/0x502 [cfg80211]
[32345.146385]  [<ffffffff81107968>] ? __kmalloc+0xec/0xfc
[32345.146394]  [<ffffffffa0283c1c>] ? ieee80211_register_hw+0x1fa/0x6fc [mac80211]
[32345.146403]  [<ffffffffa0283ebc>] ieee80211_register_hw+0x49a/0x6fc [mac80211]
[32345.146409]  [<ffffffffa02eab8b>] ath9k_htc_probe_device+0x724/0x8f5 [ath9k_htc]
[32345.146414]  [<ffffffff8144e207>] ? __kmalloc_reserve.isra.43+0x2c/0x6a
[32345.146419]  [<ffffffff813b0db8>] ? usb_submit_urb+0x308/0x325
[32345.146424]  [<ffffffffa02e270f>] ath9k_htc_hw_init+0x11/0x2e [ath9k_htc]
[32345.146429]  [<ffffffffa02e4068>] ath9k_hif_usb_firmware_cb+0x1a3/0x1b7 [ath9k_htc]
[32345.146433]  [<ffffffff81356682>] request_firmware_work_func+0x35/0x53
[32345.146437]  [<ffffffff8105b133>] process_one_work+0x18a/0x28b
[32345.146440]  [<ffffffff8105b602>] worker_thread+0x132/0x1fe
[32345.146444]  [<ffffffff8105b4d0>] ? rescuer_thread+0x26d/0x26d
[32345.146448]  [<ffffffff8106006b>] kthread+0x8d/0x95
[32345.146451]  [<ffffffff8105ffde>] ? __kthread_parkme+0x65/0x65
[32345.146455]  [<ffffffff8152ea1c>] ret_from_fork+0x7c/0xb0
[32345.146458]  [<ffffffff8105ffde>] ? __kthread_parkme+0x65/0x65
[32345.146461] ---[ end trace 8151c73e918b8da9 ]---
[32345.147098] ath9k_htc: Failed to initialize the device
[32345.171120] usb 2-5: ath9k_htc: USB layer deinitialized

Re: regression after, " ath9k_htc: Add support for mesh interfaces"

[Thomas Pedersen]

On Mon, Jun 24, 2013 at 11:14 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Am 25.06.2013 02:54, schrieb Thomas Pedersen:
>
>> On Fri, Jun 21, 2013 at 9:56 PM, Oleksij Rempel <linux@rempel-privat.de>
>> wrote:
>>>
>>> Hi Javier,
>>>
>>> i warning after patch "ath9k_htc: Add support for mesh interfaces".
>>> I get this warning only on pc with CONFIG_MAC80211_MESH not set. Probably
>>> you missed config check some where.
>>
>>
>> Where do you hit the warning?
>>
>
> on adapter init.
> see attachment.

That warning is triggered by wiphy_verify_combinations():

                        if (WARN_ON((wiphy->interface_modes & types) != types))
                                return -EINVAL;

But before that, the mesh iftype bit is cleared in ieee80211_register_hw():

#ifndef CONFIG_MAC80211_MESH
        /* mesh depends on Kconfig, but drivers should set it if they want */
        local->hw.wiphy->interface_modes &= ~BIT(NL80211_IFTYPE_MESH_POINT);
#endif

It seems the intention was to avoid an #ifdef CONFIG_MAC80211_MESH in
every driver, but then mac80211 also has to clear the MESH_POINT bit
for each ieee80211_iface_limit? I don't really see a cleaner way of
resolving this.

Johannes?

--
Thomas

Re: regression after, " ath9k_htc: Add support for mesh interfaces"

[Johannes Berg]

On Tue, 2013-06-25 at 13:05 -0700, Thomas Pedersen wrote:

> That warning is triggered by wiphy_verify_combinations():
> 
>                         if (WARN_ON((wiphy->interface_modes & types) != types))
>                                 return -EINVAL;
> 
> But before that, the mesh iftype bit is cleared in ieee80211_register_hw():
> 
> #ifndef CONFIG_MAC80211_MESH
>         /* mesh depends on Kconfig, but drivers should set it if they want */
>         local->hw.wiphy->interface_modes &= ~BIT(NL80211_IFTYPE_MESH_POINT);
> #endif
> 
> It seems the intention was to avoid an #ifdef CONFIG_MAC80211_MESH in
> every driver, but then mac80211 also has to clear the MESH_POINT bit
> for each ieee80211_iface_limit? I don't really see a cleaner way of
> resolving this.

The problem is that the data structures there are const, so we can't
modify them. I think the other drivers just have an #ifdef on
MAC80211_MESH or so in there.

johannes

Re: regression after, " ath9k_htc: Add support for mesh interfaces"

[Thomas Pedersen]

On Wed, Jun 26, 2013 at 12:31 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2013-06-25 at 13:05 -0700, Thomas Pedersen wrote:
>
>> That warning is triggered by wiphy_verify_combinations():
>>
>>                         if (WARN_ON((wiphy->interface_modes & types) != types))
>>                                 return -EINVAL;
>>
>> But before that, the mesh iftype bit is cleared in ieee80211_register_hw():
>>
>> #ifndef CONFIG_MAC80211_MESH
>>         /* mesh depends on Kconfig, but drivers should set it if they want */
>>         local->hw.wiphy->interface_modes &= ~BIT(NL80211_IFTYPE_MESH_POINT);
>> #endif
>>
>> It seems the intention was to avoid an #ifdef CONFIG_MAC80211_MESH in
>> every driver, but then mac80211 also has to clear the MESH_POINT bit
>> for each ieee80211_iface_limit? I don't really see a cleaner way of
>> resolving this.
>
> The problem is that the data structures there are const, so we can't
> modify them. I think the other drivers just have an #ifdef on
> MAC80211_MESH or so in there.

Indeed, ath5k and rt2x00 at least already do this.

Thanks,

--
Thomas

Re: regression after, " ath9k_htc: Add support for mesh interfaces"

[Oleksij Rempel]

Am 26.06.2013 20:52, schrieb Thomas Pedersen:
> On Wed, Jun 26, 2013 at 12:31 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On Tue, 2013-06-25 at 13:05 -0700, Thomas Pedersen wrote:
>>
>>> That warning is triggered by wiphy_verify_combinations():
>>>
>>>                          if (WARN_ON((wiphy->interface_modes & types) != types))
>>>                                  return -EINVAL;
>>>
>>> But before that, the mesh iftype bit is cleared in ieee80211_register_hw():
>>>
>>> #ifndef CONFIG_MAC80211_MESH
>>>          /* mesh depends on Kconfig, but drivers should set it if they want */
>>>          local->hw.wiphy->interface_modes &= ~BIT(NL80211_IFTYPE_MESH_POINT);
>>> #endif
>>>
>>> It seems the intention was to avoid an #ifdef CONFIG_MAC80211_MESH in
>>> every driver, but then mac80211 also has to clear the MESH_POINT bit
>>> for each ieee80211_iface_limit? I don't really see a cleaner way of
>>> resolving this.
>>
>> The problem is that the data structures there are const, so we can't
>> modify them. I think the other drivers just have an #ifdef on
>> MAC80211_MESH or so in there.
>
> Indeed, ath5k and rt2x00 at least already do this.
>
> Thanks,

I just discovered one more issue with mesh on ath9k* devices.
if i try to do "ifconfig mesh0 down" this task will freeze and after 
some time kernel will oops.

Steps to reproduce:
iw dev wlan2 interface add mesh0 type mp mesh_id mesh
iwconfig mesh0 channel 1
ifconfig mesh0 10.0.0.1 netmask 255.255.255.0 up
sleep 30
ifconfig mesh0 down

-- 
Regards,
Oleksij

Re: regression after, " ath9k_htc: Add support for mesh interfaces"

[Thomas Pedersen]

On Wed, Jun 26, 2013 at 12:16 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Am 26.06.2013 20:52, schrieb Thomas Pedersen:
> I just discovered one more issue with mesh on ath9k* devices.
> if i try to do "ifconfig mesh0 down" this task will freeze and after some
> time kernel will oops.
>
> Steps to reproduce:
> iw dev wlan2 interface add mesh0 type mp mesh_id mesh
> iwconfig mesh0 channel 1
> ifconfig mesh0 10.0.0.1 netmask 255.255.255.0 up
> sleep 30
> ifconfig mesh0 down

are you running wireless-testing master HEAD? There is a fix for that
deadlock in mac80211-next ("mac80211: update mesh beacon on
workqueue") still waiting to get into wireless-testing.

--
Thomas