* RE: [PATCH V2] vlan priority handling in WMM
From: voncken @ 2013-07-05 14:39 UTC (permalink / raw)
To: 'Johannes Berg'; +Cc: linux-wireless
In-Reply-To: <1373018378.8548.6.camel@jlt4.sipsolutions.net>
> >+ vlan_priority = (skb->vlan_tci & VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT;
> >+ if (vlan_priority > 0)
>> + return vlan_priority;
>Is this really correct? For once, checking vlan_priority for non-zero seems weird since that ought to be a valid value -- is there no other way to determine that the value is valid?
The vlan Tag contain three bit for priority. The value 0 indicate no priority (on this case the VLAN tag contain only VID). The vlan_tci field is set to zero if the frame do not contain the vlan tag. So if we have not a vlan tag or no priority in VLAN tag the priority value is always 0.
>Also, this gives you a 2-bit value, while the return value should be a 3-bit value, maybe you need to shift this up by one to spread into the correct buckets?
Sorry but I don't understand. The vlan_tci field it is a __u16 value (defined in include/linux/skbuff.h), the VLAN_PRIO_MASK is set to 0xE000 and VLAN_PRIO_SHIFT is set to 13 (defined in include/linux/if_vlan.h), the vlan_priority is an unsigned char. For me the vlan_priority contain a 3-bit value (0xE000 >>13 = 0x0003), why 2 ?
If you are agree with me, I'll resend a V3 patch with a correct subject.
Cedric
>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
^ permalink raw reply
* RE: [PATCH] mwifiex: don't ignore SDIO interrupts during shutdown
From: Amitkumar Karwar @ 2013-07-05 14:44 UTC (permalink / raw)
To: 'Daniel Drake', Bing Zhao
Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <CAMLZHHSSfPnWK957Yd+vrLrsPHtUDW3b4ZxSjMe2SdpaQPk5hQ@mail.gmail.com>
Hi Daniel,
>Also, at which point do we wait upon all async commands to complete
>before shutting down?
All sync and async commands are queued into same queue. Sync and async type indicates if the thread just queues the command or it queues the command and waits until command response is received.
Next command is sent to firmware only after receiving response of previous command. As we don't queue any command after SHUTDOWN command is queued, SHUTDOWN command is the last command sent to firmware. SHUTDOWN is a sync command. Hence remove handler thread waits until it's response.
Please let me know if there are any doubts.
Thanks,
Amit
^ permalink raw reply
* Re: [PATCH] mwifiex: don't ignore SDIO interrupts during shutdown
From: Daniel Drake @ 2013-07-05 14:45 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Bing Zhao, linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <5FF020A1CFFEEC49BD1E09530C4FF5951035636350@SC-VEXCH1.marvell.com>
On Fri, Jul 5, 2013 at 8:26 AM, Amitkumar Karwar <akarwar@marvell.com> wrote:
> I think, we should probably look into mwifiex_sdio_suspend() routine instead of mwifiex_sdio_remove() to debug interrupt storm issue. Please correct me if I am missing something.
The system is going into an unpowered suspend. This means that
mwifiex_sdio_suspend() returns -ENOSYS.
The card then gets removed by mwifiex_sdio_remove().
mwifiex_sdio_remove() calls mwifiex_remove_card() without having taken
any care to finish pending commands, etc. mwifiex_remove_card()
immediately sets surprise_removed which triggers the questionable
"ignore all interrupts" behaviour. If there were any async commands
pending, they complete now, with an interrupt. The interrupt doesn't
get acked, so it becomes an interrupt storm.
Hope that is clearer.
Daniel
^ permalink raw reply
* [PATCH] ath10k: remove unneeded semicolon
From: Kalle Valo @ 2013-07-05 14:46 UTC (permalink / raw)
To: ath9k-devel; +Cc: fengguang.wu, linux-wireless
Coccinelly found:
drivers/net/wireless/ath/ath10k/htt_rx.c:1163:2-3: Unneeded semicolon
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index de058d7..ad28866 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1160,7 +1160,7 @@ void ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
ath10k_dbg_dump(ATH10K_DBG_HTT_DUMP, NULL, "htt event: ",
skb->data, skb->len);
break;
- };
+ }
/* Free the indication buffer */
dev_kfree_skb_any(skb);
^ permalink raw reply related
* Passing a custom MAC to ath6kl
From: Hector Palacios @ 2013-07-05 15:21 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, ath6kl-devel
Greetings,
Is there a way to pass a custom MAC address to the ath6kl upstream driver?
In the ISC version of the driver, a softmac.c file is provided that reads a MAC from a
file if a module parameter softmac_enable=1 is passed.
Is there any reason why this has not made it upstream?
Best regards,
--
Hector Palacios
^ permalink raw reply
* RE: [PATCH] mwifiex: don't ignore SDIO interrupts during shutdown
From: Amitkumar Karwar @ 2013-07-05 15:24 UTC (permalink / raw)
To: 'Daniel Drake'
Cc: Bing Zhao, linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <CAMLZHHSduu3guHuw__XKZfhrFWc8r7W6DwLp3SMdtLQ56CRh6Q@mail.gmail.com>
Hi Daniel,
>mwifiex_sdio_remove() calls mwifiex_remove_card() without having taken
>any care to finish pending commands, etc. mwifiex_remove_card()
>immediately sets surprise_removed which triggers the questionable
>"ignore all interrupts" behaviour. If there were any async commands
>pending, they complete now, with an interrupt. The interrupt doesn't
>get acked, so it becomes an interrupt storm.
>Hope that is clearer.
Thanks for the clarification.
As per our current design, mwifiex_sdio_remove() will be called in following scenarios.
1) Card is powered off / card is unplugged
As we are not allowed to interact with hardware (read/disable interrupts), other driver specific cleanup work is performed.
2) Driver is unloaded
Here apart from cleanup work in case 1, we do send SHUTDOWN etc. command to firmware to perform hardware cleanup(this code is under if(user_rmmod) check).
In your case, as card is powering off, is it ok to access hardware registers to ACK interrupts? If yes, we can disable interrupts before returning "-ENOSYS" in suspend handler.
Modifying mwifiex_sdio_remove() to fix interrupt storm issue would break card unplugged scenario.
Please let me know your thoughts.
Thanks,
Amit
^ permalink raw reply
* Re: [PATCH] mwifiex: don't ignore SDIO interrupts during shutdown
From: Daniel Drake @ 2013-07-05 15:37 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Bing Zhao, linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <5FF020A1CFFEEC49BD1E09530C4FF5951035636352@SC-VEXCH1.marvell.com>
On Fri, Jul 5, 2013 at 9:24 AM, Amitkumar Karwar <akarwar@marvell.com> wrote:
> In your case, as card is powering off, is it ok to access hardware registers to ACK interrupts? If yes, we can disable interrupts before returning "-ENOSYS" in suspend handler.
You tell me - you know the hardware and the driver better than I do. I
don't see any external reason why we are not allowed to communicate to
the hardware here. The other suspend paths do run some communication.
However, disabling interrupts at this point does seem like a bad
solution to me, and something that would come back and bite us in the
future. mwifiex_sdio_suspend() is not directly related to the cause of
the problem.
The problem that we should focus on is that mwifiex_remove_card()
makes the driver enter a state where if an interrupt arrives, it will
be handled badly. Therefore it should be mwifiex_remove_card() or
something directly related to it (maybe the callsite,
mwifiex_sdio_remove) that takes the necessary steps to make sure that
interrupts will not arrive in future.
> Modifying mwifiex_sdio_remove() to fix interrupt storm issue would break card unplugged scenario.
Why would it break that scenario?
Daniel
^ permalink raw reply
* Re: Passing a custom MAC to ath6kl
From: Kalle Valo @ 2013-07-05 15:49 UTC (permalink / raw)
To: Hector Palacios; +Cc: linux-wireless, ath6kl-devel
In-Reply-To: <51D6E484.9060000@digi.com>
Hector Palacios <hector.palacios@digi.com> writes:
> Is there a way to pass a custom MAC address to the ath6kl upstream driver?
Not right now. It has been a common feature request so I'm hoping
someone will implement it soon.
> In the ISC version of the driver, a softmac.c file is provided that
> reads a MAC from a file if a module parameter softmac_enable=1 is
> passed. Is there any reason why this has not made it upstream?
Providing mac address through a file is too ugly for upstream. We need
to implement it properly using the proper interface.
--
Kalle Valo
^ permalink raw reply
* Re: Passing a custom MAC to ath6kl
From: Hector Palacios @ 2013-07-05 15:56 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless@vger.kernel.org, ath6kl-devel@qca.qualcomm.com
In-Reply-To: <87vc4pf1ln.fsf@kamboji.qca.qualcomm.com>
Dear Kalle,
On 07/05/2013 05:49 PM, Kalle Valo wrote:
> Hector Palacios <hector.palacios@digi.com> writes:
>
>> Is there a way to pass a custom MAC address to the ath6kl upstream driver?
>
> Not right now. It has been a common feature request so I'm hoping
> someone will implement it soon.
>
>> In the ISC version of the driver, a softmac.c file is provided that
>> reads a MAC from a file if a module parameter softmac_enable=1 is
>> passed. Is there any reason why this has not made it upstream?
>
> Providing mac address through a file is too ugly for upstream. We need
> to implement it properly using the proper interface.
I totally agree. What would be the proper interface for that?
Best regards,
--
Hector Palacios
^ permalink raw reply
* RE: [PATCH] mwifiex: don't ignore SDIO interrupts during shutdown
From: Amitkumar Karwar @ 2013-07-05 16:43 UTC (permalink / raw)
To: 'Daniel Drake'
Cc: Bing Zhao, linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <CAMLZHHQuHAZGW0M0qhQi5PoCW78jgF8rw2ZsmbApT2REBRXZtA@mail.gmail.com>
Hi Daniel,
>I don't see any external reason why we are not allowed to communicate to
>the hardware here. The other suspend paths do run some communication.
The reason is mwifiex_sdio_remove() gets called even if user removes an externally connected wifi card. In that case the hardware is not present so there is no point in reading/writing hardware registers.
If mwifiex_sdio_remove() is called when card is not powered off or unplugged, we do take care of hardware de-initialization using user_rmmod flag. Interrupt storm issue doesn't exist there.
>However, disabling interrupts at this point does seem like a bad
>solution to me, and something that would come back and bite us in the
>future. mwifiex_sdio_suspend() is not directly related to the cause of
>the problem.
This approach looks correct to me. While returning failure in suspend handler, 'pm_flag & MMC_PM_KEEP_POWER' is false. Card is going to be powered off soon. There won't be any further communication with card, so disabling interrupts at this point of time is logical.
When system is resumed, bus rescan etc. will happen and card will be redetected.
Can you please try this change?
Thanks and regards,
Amitkumar Karwar
^ permalink raw reply
* Re: [PATCH] mwifiex: don't ignore SDIO interrupts during shutdown
From: Daniel Drake @ 2013-07-05 16:48 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Bing Zhao, linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <5FF020A1CFFEEC49BD1E09530C4FF5951035636353@SC-VEXCH1.marvell.com>
On Fri, Jul 5, 2013 at 10:43 AM, Amitkumar Karwar <akarwar@marvell.com> wrote:
>
> Hi Daniel,
>
>>I don't see any external reason why we are not allowed to communicate to
>>the hardware here. The other suspend paths do run some communication.
>
> The reason is mwifiex_sdio_remove() gets called even if user removes an externally connected wifi card. In that case the hardware is not present so there is no point in reading/writing hardware registers.
There is no point in the one case that you mention. But there is a
very good reason to do so in the case that I am talking about. So why
not do it? There is no harm to do it if the hardware is not present,
right?
> This approach looks correct to me. While returning failure in suspend handler, 'pm_flag & MMC_PM_KEEP_POWER' is false. Card is going to be powered off soon. There won't be any further communication with card, so disabling interrupts at this point of time is logical.
> When system is resumed, bus rescan etc. will happen and card will be redetected.
This doesn't make much sense to me either. Why don't we just disable
the interrupt handler at the point when interrupts can no longer be
correctly handled by the driver?
Daniel
^ permalink raw reply
* RE: [PATCH] mwifiex: don't ignore SDIO interrupts during shutdown
From: Amitkumar Karwar @ 2013-07-05 17:05 UTC (permalink / raw)
To: 'Daniel Drake'
Cc: Bing Zhao, linux-wireless@vger.kernel.org, linville@tuxdriver.com
In-Reply-To: <CAMLZHHSZvKWnaBXycNsh64oExhpa0amcUi-6eC-FOaeNZ-TP1A@mail.gmail.com>
Hi Daniel,
>There is no point in the one case that you mention. But there is a
>very good reason to do so in the case that I am talking about. So why
>not do it? There is no harm to do it if the hardware is not present,
>right?
I got your point. We didn't test the behavior of sdio_read/sdio_write API's when hardware is not present. But they should just return an error.
>This doesn't make much sense to me either. Why don't we just disable
>the interrupt handler at the point when interrupts can no longer be
>correctly handled by the driver?
Agreed. Following change will fix the issue. Right? Instead of going for your earlier changes to ack interrupts until we disable them.
@@ -152,6 +152,9 @@ mwifiex_sdio_remove(struct sdio_func *func)
mwifiex_init_shutdown_fw(priv, MWIFIEX_FUNC_SHUTDOWN);
}
+ /* Disable host interrupt mask register for SDIO */
+ mwifiex_sdio_disable_host_int(adapter);
+
mwifiex_remove_card(card->adapter, &add_remove_card_sem);
kfree(card);
}
Thanks,
Amitkumar Karwar
^ permalink raw reply
* Re: Passing a custom MAC to ath6kl
From: Arend van Spriel @ 2013-07-05 18:02 UTC (permalink / raw)
To: Hector Palacios
Cc: Kalle Valo, linux-wireless@vger.kernel.org,
ath6kl-devel@qca.qualcomm.com
In-Reply-To: <51D6EC90.40009@digi.com>
On 07/05/2013 05:56 PM, Hector Palacios wrote:
> Dear Kalle,
>
> On 07/05/2013 05:49 PM, Kalle Valo wrote:
>> Hector Palacios <hector.palacios@digi.com> writes:
>>
>>> Is there a way to pass a custom MAC address to the ath6kl upstream
>>> driver?
>>
>> Not right now. It has been a common feature request so I'm hoping
>> someone will implement it soon.
>>
>>> In the ISC version of the driver, a softmac.c file is provided that
>>> reads a MAC from a file if a module parameter softmac_enable=1 is
>>> passed. Is there any reason why this has not made it upstream?
>>
>> Providing mac address through a file is too ugly for upstream. We need
>> to implement it properly using the proper interface.
>
> I totally agree. What would be the proper interface for that?
Add .ndo_set_mac_address() callback in main.c and go from there.
int (*ndo_set_mac_address)(struct net_device *dev, void *addr);
Regards,
Arend
> Best regards,
> --
> Hector Palacios
> --
> 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
>
^ permalink raw reply
* Re: Passing a custom MAC to ath6kl
From: Kalle Valo @ 2013-07-05 20:23 UTC (permalink / raw)
To: Arend van Spriel
Cc: Hector Palacios, linux-wireless@vger.kernel.org,
ath6kl-devel@qca.qualcomm.com
In-Reply-To: <51D70A22.20607@broadcom.com>
Arend van Spriel <arend@broadcom.com> writes:
> On 07/05/2013 05:56 PM, Hector Palacios wrote:
>> Dear Kalle,
>>
>> On 07/05/2013 05:49 PM, Kalle Valo wrote:
>>> Hector Palacios <hector.palacios@digi.com> writes:
>>>
>>>> Is there a way to pass a custom MAC address to the ath6kl upstream
>>>> driver?
>>>
>>> Not right now. It has been a common feature request so I'm hoping
>>> someone will implement it soon.
>>>
>>>> In the ISC version of the driver, a softmac.c file is provided that
>>>> reads a MAC from a file if a module parameter softmac_enable=1 is
>>>> passed. Is there any reason why this has not made it upstream?
>>>
>>> Providing mac address through a file is too ugly for upstream. We need
>>> to implement it properly using the proper interface.
>>
>> I totally agree. What would be the proper interface for that?
>
> Add .ndo_set_mac_address() callback in main.c and go from there.
>
> int (*ndo_set_mac_address)(struct net_device *dev, void *addr);
And the challenge with ath6kl is that we need to stop the firmware,
change mac address in the firmware and restart the firmware. So it's not
trivial to add that but it shouldn't be too difficult either. Patches
more than welcome :)
--
Kalle Valo
^ permalink raw reply
* Re: [ath9k-devel] ath: Unable to remove station entry
From: Oleksij Rempel @ 2013-07-06 5:31 UTC (permalink / raw)
To: Michael Tokarev; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <51D68B55.3070309@msgid.tls.msk.ru>
Hi Michael,
there is no way to avoid latest wireless-testing kernel. I had similar
problems for some kernel version. But now it seems to work more or less
ok. For example it will nuke complete system only by triggering some bug
in xhcd driver :)
Am 05.07.2013 11:01, schrieb Michael Tokarev:
> Hello.
>
> Recently I bought a TP-Link TL-WN821N v3 802.11n USB adaptor,
> and tried to use it as an access point for a small Wireless LAN.
>
> It works fine so far, except of one issue.
>
> Quite often to be really annoying, it stops working with the
> following message in kernel log:
>
> Jul 5 09:51:26 gnome vmunix: [133814.449408] ath: Unable to remove station entry for: 38:aa:3c:02:07:f1
>
> after this, the interface is stuck, it can't be seen over WIFI,
> and any attempt to do anything with it inside the host results
> in more processes entering D state (initially right when this
> happens, there's a kworker process in D state).
>
> For example, `rmmod ath9k_htc' - which appears to be a topmost
> module on the stack - results in rmmod entering D state, with
> the following stack:
>
> rmmod D 000000010266c10c 0 10684 10643 0x00000000
> ffffffff8148b020 0000000000000082 0000000000012400 ffff88012ae9d7d0
> ffff880114843fd8 ffff880114843fd8 ffff880114843fd8 ffff88012ae9d7d0
> 0000000125aa5040 ffffffff8148b020 0000000000012400 ffff8801298cb500
> Call Trace:
> [<ffffffff81367a59>] ? __schedule+0x3a9/0x960
> [<ffffffff810558f0>] ? usleep_range+0x40/0x40
> [<ffffffff81368e38>] ? __mutex_lock_slowpath+0xc8/0x140
> [<ffffffff813689ba>] ? mutex_lock+0x1a/0x40
> [<ffffffffa025bc66>] ? ath9k_wmi_cmd+0xc6/0x200 [ath9k_htc]
> [<ffffffffa02614d8>] ? ath9k_regread+0x38/0x50 [ath9k_htc]
> [<ffffffffa0076849>] ? ath_hw_keyreset+0x59/0x220 [ath]
> [<ffffffffa0076a2d>] ? ath_key_delete+0x1d/0xdc [ath]
> [<ffffffffa025edc5>] ? ath9k_htc_set_key+0x85/0x130 [ath9k_htc]
> [<ffffffffa0230d19>] ? ieee80211_key_disable_hw_accel+0x89/0x130 [mac80211]
> [<ffffffffa0230ddc>] ? __ieee80211_key_destroy+0x1c/0x80 [mac80211]
> [<ffffffffa0231505>] ? ieee80211_free_keys+0x45/0x80 [mac80211]
> [<ffffffffa02233a7>] ? ieee80211_do_stop+0x1f7/0x5c0 [mac80211]
> [<ffffffff812d9f40>] ? dev_deactivate_many+0x1f0/0x240
> [<ffffffffa0223785>] ? ieee80211_stop+0x15/0x20 [mac80211]
> [<ffffffff812bc505>] ? __dev_close_many+0x85/0xd0
> [<ffffffff812bc638>] ? dev_close_many+0x98/0x110
> [<ffffffff812bc788>] ? rollback_registered_many+0xd8/0x250
> [<ffffffff812bc90e>] ? unregister_netdevice_many+0xe/0x60
> [<ffffffffa0222f00>] ? ieee80211_remove_interfaces+0xc0/0x100 [mac80211]
> [<ffffffffa0211096>] ? ieee80211_unregister_hw+0x46/0x110 [mac80211]
> [<ffffffffa02624c4>] ? ath9k_htc_disconnect_device+0x54/0xd0 [ath9k_htc]
> [<ffffffffa025b3a2>] ? ath9k_hif_usb_disconnect+0x52/0x150 [ath9k_htc]
> [<ffffffffa005dd52>] ? usb_unbind_interface+0x42/0x150 [usbcore]
> [<ffffffff81274546>] ? __device_release_driver+0x76/0xe0
> [<ffffffff81274bf0>] ? driver_detach+0xa0/0xb0
> [<ffffffff812743d0>] ? bus_remove_driver+0x70/0xc0
> [<ffffffffa005d7a6>] ? usb_deregister+0xa6/0xc0 [usbcore]
> [<ffffffffa0262d36>] ? ath9k_htc_exit+0x6/0x16 [ath9k_htc]
> [<ffffffff81080ee2>] ? sys_delete_module+0x132/0x260
> [<ffffffff8136a245>] ? page_fault+0x25/0x30
> [<ffffffff81371552>] ? system_call_fastpath+0x16/0x1b
>
> followed by:
>
> Jul 5 10:02:27 gnome vmunix: [134474.473451] ath: Unable to remove interface at idx: 0
>
> (rmmod is stuck forever).
>
> Now, in order to make the interface to work again, the only way I
> found so far is to _reboot_ the machine. For example, re-plugging
> the USB cord does not help, because, as far as I can see, the driver
> is in some weird state and can't initialize the new interface.
>
> This is a 3.2.0-stable kernel (right now 3.2.46), x86-64 (amd64),
> self-compiled, without additional patches.
>
>
> There are a few references to this message on the 'net, including
> one mentioning this very card (in russian) --
>
> http://forums.opensuse.org/p-russian/dhydhdhdhdhundhdhdh/1046-1077-1083-1077-1079-1086/469022-wifi-usb-tp-link-tl-wn821n.html
>
> they claim the problem has been fixed for _some_ by upgrading the
> BIOS on the motherboard. Maybe this is actually related, because
> as far as I can tell, this started happening _after_ I upgraded
> BIOS on my motherboard, so it may be related to the bios changes.
> I don't recall whenever I noticed this erratic behavour before I
> upgraded BIOS. Looking at the BIOS history, I don't see anything
> interesting about USB in the changelog, except this:
>
> * Fixed issue with Fast Boot so USB devices still work under DOS
> if USB Optimization is enabled.
>
> This is an intel atom-based D2500CC board, with the latest BIOS.
> I had to update bios because of another issue which is now fixed,
> but I can't go back to the old bios because the old one was too
> old and current motherboard refuses to flash it.
>
>
> What can be done to diagnose the problem? I can give a more recent
> kernel a try, but I'd love to see it fixed for a -stable kernel which
> is used by several major distributions. Also, the problem is not
> easy to trigger, the system may work for a few days without issues
> or may stop working in a few hours, irrespective of the load (f.e.
> the above example at 09:51 was me awakening my android phone just
> to see what time it is now, and it trying to connect/disconnect
> to/from the default wifi network -- there were no other devices
> using wifi at that time).
>
> Thanks,
>
> /mjt
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
--
Regards,
Oleksij
^ permalink raw reply
* Re: [ath9k-devel] ath: Unable to remove station entry
From: Michael Tokarev @ 2013-07-06 6:47 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <51D7ABC6.40307@rempel-privat.de>
06.07.2013 09:31, Oleksij Rempel wrote:
> Hi Michael,
Hello!
> there is no way to avoid latest wireless-testing kernel. I had similar problems for some kernel version. But now it seems to work more or less ok. For example it will nuke complete system only by triggering some bug in xhcd driver :)
Hmm. Are you saying that no one cares about -stable, and
bugs are only fixed in latest prereleases? If that's true,
it is very unfortunate situation for the wireless subsystem...
Thanks,
/mjt
> Am 05.07.2013 11:01, schrieb Michael Tokarev:
>> Hello.
>>
>> Recently I bought a TP-Link TL-WN821N v3 802.11n USB adaptor,
>> and tried to use it as an access point for a small Wireless LAN.
>>
>> It works fine so far, except of one issue.
>>
>> Quite often to be really annoying, it stops working with the
>> following message in kernel log:
>>
>> Jul 5 09:51:26 gnome vmunix: [133814.449408] ath: Unable to remove station entry for: 38:aa:3c:02:07:f1
>>
>> after this, the interface is stuck, it can't be seen over WIFI,
>> and any attempt to do anything with it inside the host results
>> in more processes entering D state (initially right when this
>> happens, there's a kworker process in D state).
>>
>> For example, `rmmod ath9k_htc' - which appears to be a topmost
>> module on the stack - results in rmmod entering D state, with
>> the following stack:
>>
>> rmmod D 000000010266c10c 0 10684 10643 0x00000000
>> ffffffff8148b020 0000000000000082 0000000000012400 ffff88012ae9d7d0
>> ffff880114843fd8 ffff880114843fd8 ffff880114843fd8 ffff88012ae9d7d0
>> 0000000125aa5040 ffffffff8148b020 0000000000012400 ffff8801298cb500
>> Call Trace:
>> [<ffffffff81367a59>] ? __schedule+0x3a9/0x960
>> [<ffffffff810558f0>] ? usleep_range+0x40/0x40
>> [<ffffffff81368e38>] ? __mutex_lock_slowpath+0xc8/0x140
>> [<ffffffff813689ba>] ? mutex_lock+0x1a/0x40
>> [<ffffffffa025bc66>] ? ath9k_wmi_cmd+0xc6/0x200 [ath9k_htc]
>> [<ffffffffa02614d8>] ? ath9k_regread+0x38/0x50 [ath9k_htc]
>> [<ffffffffa0076849>] ? ath_hw_keyreset+0x59/0x220 [ath]
>> [<ffffffffa0076a2d>] ? ath_key_delete+0x1d/0xdc [ath]
>> [<ffffffffa025edc5>] ? ath9k_htc_set_key+0x85/0x130 [ath9k_htc]
>> [<ffffffffa0230d19>] ? ieee80211_key_disable_hw_accel+0x89/0x130 [mac80211]
>> [<ffffffffa0230ddc>] ? __ieee80211_key_destroy+0x1c/0x80 [mac80211]
>> [<ffffffffa0231505>] ? ieee80211_free_keys+0x45/0x80 [mac80211]
>> [<ffffffffa02233a7>] ? ieee80211_do_stop+0x1f7/0x5c0 [mac80211]
>> [<ffffffff812d9f40>] ? dev_deactivate_many+0x1f0/0x240
>> [<ffffffffa0223785>] ? ieee80211_stop+0x15/0x20 [mac80211]
>> [<ffffffff812bc505>] ? __dev_close_many+0x85/0xd0
>> [<ffffffff812bc638>] ? dev_close_many+0x98/0x110
>> [<ffffffff812bc788>] ? rollback_registered_many+0xd8/0x250
>> [<ffffffff812bc90e>] ? unregister_netdevice_many+0xe/0x60
>> [<ffffffffa0222f00>] ? ieee80211_remove_interfaces+0xc0/0x100 [mac80211]
>> [<ffffffffa0211096>] ? ieee80211_unregister_hw+0x46/0x110 [mac80211]
>> [<ffffffffa02624c4>] ? ath9k_htc_disconnect_device+0x54/0xd0 [ath9k_htc]
>> [<ffffffffa025b3a2>] ? ath9k_hif_usb_disconnect+0x52/0x150 [ath9k_htc]
>> [<ffffffffa005dd52>] ? usb_unbind_interface+0x42/0x150 [usbcore]
>> [<ffffffff81274546>] ? __device_release_driver+0x76/0xe0
>> [<ffffffff81274bf0>] ? driver_detach+0xa0/0xb0
>> [<ffffffff812743d0>] ? bus_remove_driver+0x70/0xc0
>> [<ffffffffa005d7a6>] ? usb_deregister+0xa6/0xc0 [usbcore]
>> [<ffffffffa0262d36>] ? ath9k_htc_exit+0x6/0x16 [ath9k_htc]
>> [<ffffffff81080ee2>] ? sys_delete_module+0x132/0x260
>> [<ffffffff8136a245>] ? page_fault+0x25/0x30
>> [<ffffffff81371552>] ? system_call_fastpath+0x16/0x1b
>>
>> followed by:
>>
>> Jul 5 10:02:27 gnome vmunix: [134474.473451] ath: Unable to remove interface at idx: 0
>>
>> (rmmod is stuck forever).
>>
>> Now, in order to make the interface to work again, the only way I
>> found so far is to _reboot_ the machine. For example, re-plugging
>> the USB cord does not help, because, as far as I can see, the driver
>> is in some weird state and can't initialize the new interface.
>>
>> This is a 3.2.0-stable kernel (right now 3.2.46), x86-64 (amd64),
>> self-compiled, without additional patches.
>>
>>
>> There are a few references to this message on the 'net, including
>> one mentioning this very card (in russian) --
>>
>> http://forums.opensuse.org/p-russian/dhydhdhdhdhundhdhdh/1046-1077-1083-1077-1079-1086/469022-wifi-usb-tp-link-tl-wn821n.html
>>
>> they claim the problem has been fixed for _some_ by upgrading the
>> BIOS on the motherboard. Maybe this is actually related, because
>> as far as I can tell, this started happening _after_ I upgraded
>> BIOS on my motherboard, so it may be related to the bios changes.
>> I don't recall whenever I noticed this erratic behavour before I
>> upgraded BIOS. Looking at the BIOS history, I don't see anything
>> interesting about USB in the changelog, except this:
>>
>> * Fixed issue with Fast Boot so USB devices still work under DOS
>> if USB Optimization is enabled.
>>
>> This is an intel atom-based D2500CC board, with the latest BIOS.
>> I had to update bios because of another issue which is now fixed,
>> but I can't go back to the old bios because the old one was too
>> old and current motherboard refuses to flash it.
>>
>>
>> What can be done to diagnose the problem? I can give a more recent
>> kernel a try, but I'd love to see it fixed for a -stable kernel which
>> is used by several major distributions. Also, the problem is not
>> easy to trigger, the system may work for a few days without issues
>> or may stop working in a few hours, irrespective of the load (f.e.
>> the above example at 09:51 was me awakening my android phone just
>> to see what time it is now, and it trying to connect/disconnect
>> to/from the default wifi network -- there were no other devices
>> using wifi at that time).
>>
>> Thanks,
>>
>> /mjt
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel@lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>
>
^ permalink raw reply
* Re: [ath9k-devel] ath: Unable to remove station entry
From: Sedat Dilek @ 2013-07-06 7:11 UTC (permalink / raw)
To: Michael Tokarev; +Cc: Oleksij Rempel, linux-wireless, ath9k-devel
In-Reply-To: <51D7BD80.6010507@msgid.tls.msk.ru>
On Sat, Jul 6, 2013 at 8:47 AM, Michael Tokarev <mjt@tls.msk.ru> wrote:
> 06.07.2013 09:31, Oleksij Rempel wrote:
>> Hi Michael,
>
> Hello!
>
>> there is no way to avoid latest wireless-testing kernel. I had similar problems for some kernel version. But now it seems to work more or less ok. For example it will nuke complete system only by triggering some bug in xhcd driver :)
>
> Hmm. Are you saying that no one cares about -stable, and
> bugs are only fixed in latest prereleases? If that's true,
> it is very unfortunate situation for the wireless subsystem...
>
It's always worth to test a higher (experimental) wireless stack to
see if the problem is solved or not.
After some more wisdom, it is hard to isolate the commit(s).
Might be worth to test compat-wireless, from my POV easier.
As usually for wireless-testing... so much components involved
(wireless-card, AP, kernelspace, userspace, etc.)...
( Start to kill any viruses flying in the air around :-). )
( Demolish any walls, walk through the wall, be the wall... :-). )
- Sedat -
> Thanks,
>
> /mjt
>
>> Am 05.07.2013 11:01, schrieb Michael Tokarev:
>>> Hello.
>>>
>>> Recently I bought a TP-Link TL-WN821N v3 802.11n USB adaptor,
>>> and tried to use it as an access point for a small Wireless LAN.
>>>
>>> It works fine so far, except of one issue.
>>>
>>> Quite often to be really annoying, it stops working with the
>>> following message in kernel log:
>>>
>>> Jul 5 09:51:26 gnome vmunix: [133814.449408] ath: Unable to remove station entry for: 38:aa:3c:02:07:f1
>>>
>>> after this, the interface is stuck, it can't be seen over WIFI,
>>> and any attempt to do anything with it inside the host results
>>> in more processes entering D state (initially right when this
>>> happens, there's a kworker process in D state).
>>>
>>> For example, `rmmod ath9k_htc' - which appears to be a topmost
>>> module on the stack - results in rmmod entering D state, with
>>> the following stack:
>>>
>>> rmmod D 000000010266c10c 0 10684 10643 0x00000000
>>> ffffffff8148b020 0000000000000082 0000000000012400 ffff88012ae9d7d0
>>> ffff880114843fd8 ffff880114843fd8 ffff880114843fd8 ffff88012ae9d7d0
>>> 0000000125aa5040 ffffffff8148b020 0000000000012400 ffff8801298cb500
>>> Call Trace:
>>> [<ffffffff81367a59>] ? __schedule+0x3a9/0x960
>>> [<ffffffff810558f0>] ? usleep_range+0x40/0x40
>>> [<ffffffff81368e38>] ? __mutex_lock_slowpath+0xc8/0x140
>>> [<ffffffff813689ba>] ? mutex_lock+0x1a/0x40
>>> [<ffffffffa025bc66>] ? ath9k_wmi_cmd+0xc6/0x200 [ath9k_htc]
>>> [<ffffffffa02614d8>] ? ath9k_regread+0x38/0x50 [ath9k_htc]
>>> [<ffffffffa0076849>] ? ath_hw_keyreset+0x59/0x220 [ath]
>>> [<ffffffffa0076a2d>] ? ath_key_delete+0x1d/0xdc [ath]
>>> [<ffffffffa025edc5>] ? ath9k_htc_set_key+0x85/0x130 [ath9k_htc]
>>> [<ffffffffa0230d19>] ? ieee80211_key_disable_hw_accel+0x89/0x130 [mac80211]
>>> [<ffffffffa0230ddc>] ? __ieee80211_key_destroy+0x1c/0x80 [mac80211]
>>> [<ffffffffa0231505>] ? ieee80211_free_keys+0x45/0x80 [mac80211]
>>> [<ffffffffa02233a7>] ? ieee80211_do_stop+0x1f7/0x5c0 [mac80211]
>>> [<ffffffff812d9f40>] ? dev_deactivate_many+0x1f0/0x240
>>> [<ffffffffa0223785>] ? ieee80211_stop+0x15/0x20 [mac80211]
>>> [<ffffffff812bc505>] ? __dev_close_many+0x85/0xd0
>>> [<ffffffff812bc638>] ? dev_close_many+0x98/0x110
>>> [<ffffffff812bc788>] ? rollback_registered_many+0xd8/0x250
>>> [<ffffffff812bc90e>] ? unregister_netdevice_many+0xe/0x60
>>> [<ffffffffa0222f00>] ? ieee80211_remove_interfaces+0xc0/0x100 [mac80211]
>>> [<ffffffffa0211096>] ? ieee80211_unregister_hw+0x46/0x110 [mac80211]
>>> [<ffffffffa02624c4>] ? ath9k_htc_disconnect_device+0x54/0xd0 [ath9k_htc]
>>> [<ffffffffa025b3a2>] ? ath9k_hif_usb_disconnect+0x52/0x150 [ath9k_htc]
>>> [<ffffffffa005dd52>] ? usb_unbind_interface+0x42/0x150 [usbcore]
>>> [<ffffffff81274546>] ? __device_release_driver+0x76/0xe0
>>> [<ffffffff81274bf0>] ? driver_detach+0xa0/0xb0
>>> [<ffffffff812743d0>] ? bus_remove_driver+0x70/0xc0
>>> [<ffffffffa005d7a6>] ? usb_deregister+0xa6/0xc0 [usbcore]
>>> [<ffffffffa0262d36>] ? ath9k_htc_exit+0x6/0x16 [ath9k_htc]
>>> [<ffffffff81080ee2>] ? sys_delete_module+0x132/0x260
>>> [<ffffffff8136a245>] ? page_fault+0x25/0x30
>>> [<ffffffff81371552>] ? system_call_fastpath+0x16/0x1b
>>>
>>> followed by:
>>>
>>> Jul 5 10:02:27 gnome vmunix: [134474.473451] ath: Unable to remove interface at idx: 0
>>>
>>> (rmmod is stuck forever).
>>>
>>> Now, in order to make the interface to work again, the only way I
>>> found so far is to _reboot_ the machine. For example, re-plugging
>>> the USB cord does not help, because, as far as I can see, the driver
>>> is in some weird state and can't initialize the new interface.
>>>
>>> This is a 3.2.0-stable kernel (right now 3.2.46), x86-64 (amd64),
>>> self-compiled, without additional patches.
>>>
>>>
>>> There are a few references to this message on the 'net, including
>>> one mentioning this very card (in russian) --
>>>
>>> http://forums.opensuse.org/p-russian/dhydhdhdhdhundhdhdh/1046-1077-1083-1077-1079-1086/469022-wifi-usb-tp-link-tl-wn821n.html
>>>
>>> they claim the problem has been fixed for _some_ by upgrading the
>>> BIOS on the motherboard. Maybe this is actually related, because
>>> as far as I can tell, this started happening _after_ I upgraded
>>> BIOS on my motherboard, so it may be related to the bios changes.
>>> I don't recall whenever I noticed this erratic behavour before I
>>> upgraded BIOS. Looking at the BIOS history, I don't see anything
>>> interesting about USB in the changelog, except this:
>>>
>>> * Fixed issue with Fast Boot so USB devices still work under DOS
>>> if USB Optimization is enabled.
>>>
>>> This is an intel atom-based D2500CC board, with the latest BIOS.
>>> I had to update bios because of another issue which is now fixed,
>>> but I can't go back to the old bios because the old one was too
>>> old and current motherboard refuses to flash it.
>>>
>>>
>>> What can be done to diagnose the problem? I can give a more recent
>>> kernel a try, but I'd love to see it fixed for a -stable kernel which
>>> is used by several major distributions. Also, the problem is not
>>> easy to trigger, the system may work for a few days without issues
>>> or may stop working in a few hours, irrespective of the load (f.e.
>>> the above example at 09:51 was me awakening my android phone just
>>> to see what time it is now, and it trying to connect/disconnect
>>> to/from the default wifi network -- there were no other devices
>>> using wifi at that time).
>>>
>>> Thanks,
>>>
>>> /mjt
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel@lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>
>>
>>
>
> --
> 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
^ permalink raw reply
* Re: [PATCH] brcm: add brcmfmac sdio firmware for bcm43241
From: Ben Hutchings @ 2013-07-06 15:39 UTC (permalink / raw)
To: Arend van Spriel
Cc: Linux Wireless, Franky Lin, David Woodhouse, Stephen Warren
In-Reply-To: <51D54FD2.6090107@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 3274 bytes --]
On Thu, 2013-07-04 at 12:34 +0200, Arend van Spriel wrote:
> On 07/04/2013 04:22 AM, Ben Hutchings wrote:
> > On Wed, 2013-05-29 at 15:13 +0200, Arend van Spriel wrote:
[...]
> >> --- a/WHENCE
> >> +++ b/WHENCE
> >> @@ -1652,6 +1652,7 @@ Driver: brcmfmac - Broadcom 802.11n fullmac wireless LAN driver.
> >>
> >> File: brcm/bcm4329-fullmac-4.bin
> >> File: brcm/brcmfmac43236b.bin
> >> +File: brcm/brcmfmac43241.bin
> >> File: brcm/brcmfmac4329.bin
> >> File: brcm/brcmfmac4330.bin
> >> File: brcm/brcmfmac4334.bin
> > [...]
> >
> > Unless you're doing something very clever with macros, I don't believe
> > you've posted any driver code that uses this file... or several of the
> > others. The current driver in net-next (I don't know what you've sent
> > to Nvidia) appears to request only these files:
>
> Hi, Ben
>
> Nvidia was just using the upstream brcmfmac driver. The "clever" thing
> we are doing for the SDIO part of our brcmfmac driver is that the
> firmware filename requested by the driver is always brcmfmac-sdio.bin.
> We explain on wireless.kernel.org that people should link/copy the
> firmware file for their device to brcmfmac-sdio.bin
Not a great idea, but I think you recognise that now.
> and get
> brcmfmac-sdio.txt from their board supplier as it is very board specific
> initialization data.
What if someone wants to put more than one of these devices in the same
system?
[...]
> > So I think, before this patch is applied, you owe me and David patches
> > to:
> >
> > 1. Add brcm/brcmfmac43143.bin, brcm/brcmfmac43242a.bin and
> > brcm/brcmfmac-sdio.txt.
>
> The 43143 and 43242 bin files will be submitted, but these firmwares
> have not yet been released. I have to wait for a green light on that.
>
> > 2. Rename brcm/bcm4329-fullmac-4.bin to brcm/brcmfmac-sdio.bin.
>
> That file is there for brcmfmac in older kernels (< v3.3) as the
> replacement brcmfmac4329.bin does not work with brcmfmac in those older
> kernels.
OK.
> > 3. Add symlinks from all the old names to the new names. (As
> > linux-firmware should support old in-tree drivers indefinitely.)
>
> I will look into this to see what names were used by brcmfmac since it
> was mainlined.
As I said, all the names that have been used should be supported. So
either provide multiple versions of the firmware or add symlinks, as
appropriate.
> > and you owe linux-wireless some driver patches.
> >
> > linux-firmware.git is not the appropriate place to send firmware used
> > only by out-of-tree code, and any firmware blob that has never been
> > referenced by in-tree code is subject to removal.
>
> I am aware and none of the firmwares we released are for out-of-tree
> code. We actually got feedback that using the same firmware filename for
> multiple devices was not very user-friendly. Therefore we will get rid
> of this quirky approach in the next kernel and the firmware files in
> linux-firmware will be listed in brcmfmac using the MODULE_FIRMWARE() macro.
Thanks for clearing this up.
Please re-send the new firmware, and include the firmware version in
WHENCE.
Ben.
--
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Realtek RTL8188CUS driver
From: Ivan A. Ivanchikov @ 2013-07-06 19:45 UTC (permalink / raw)
To: linux-wireless
Good day, gentlemen!
I use arch linux, and have this device
http://www.trendnet.com/downloads/list_subcategory.asp?SUBTYPE_ID=1426
Driver from stock kernel cannot be used, rtl8192cu was loaded but does not work.
I downloaded https://github.com/downloads/dvdhrm/rt8192cu/rt8192cu-3.4.3.4369.20120622.tar.gz
this sources and this patch
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1030858/comments/65
and then my network works. My current kernel version is 3.9.9.
If changes can be integrated for stock kernel?
yours respectfully, Ivan
^ permalink raw reply
* Re: Constant network assoc/disassoc loop with rtl8192cu usb adapter
From: Ilia Mirkin @ 2013-07-07 2:41 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <CAKb7UvjVyZuOjuD3oFT_jxx5T=DNamHA_YiV_yGWcmePHHd-UQ@mail.gmail.com>
On Thu, Jul 4, 2013 at 1:35 AM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> Hello,
>
> I recently got a RTL8188CUS usb adapter (which uses the rtl8192cu
> driver). I'm having trouble getting it to stay associated:
>
> [601369.845916] wlan0: associated
> [601377.106440] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try
> to reconnect now
> [601383.867706] wlan0: associated
> [601391.120270] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try
> to reconnect now
> [601397.910678] wlan0: associated
> [601405.141764] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try
> to reconnect now
>
> and so on. A different usb adapter (Ralink RT2573) has no trouble
> associating to that AP (but it keeps hanging and the kernel isn't
> always able to reset it properly). The network in question is using
> WPA2-PSK.
>
> Is there some setting I could adjust so that it would wait longer
> before deciding that the AP is off? Or something else I can do?
>
> This is on a 3.10-rc6 kernel + the __queue_work warning fix patch at
> https://git.kernel.org/cgit/linux/kernel/git/linville/wireless-testing.git/patch/?id=1621c9466099faf21ad19738d54a7d1845a29b32.
In addition to the messages above, I also occasionally saw sequences of 3-6
rtlwifi:addbareq_rx():<100-1> sta is NULL
messages after an association timeout.
Here are a few things I tried:
(a) increasing the timeout to 20 seconds, from 6. Didn't help.
(b) printing each beacon frame (in rtl_beacon_statistic). This showed
some potentially interesting results... right after association, I see
beacons from various APs (including the right one). But after about 1
second, all the other APs die out, and I only see beacons from 2
related APs (foo and foo-guest, with nearly identical bssid's),
neither of which is the one I want. I think that they're stronger than
the AP I'm trying to connect to. Sometimes the "right" AP's beacons
come back, sometimes not.
(c) Realtek's driver (rtl8188C_8192C_usb_linux_v3.4.4_4749.20121105).
Eventually I got it to compile. It links just fine to the AP, no
wifi-related problems. (The driver hung the system on usb removal, but
that seems more related to poor coding.) So the AP isn't too far away,
and it's not a situation where there's too much noise for the hardware
to handle. Running a ping shows that there aren't any significant
connection drops.
Let me know if there are other things you think I should try. Happy to
test any patches/provide info.
-ilia
^ permalink raw reply
* [PATCH] rtlwifi: Fix Kconfig for some corner cases
From: Larry Finger @ 2013-07-07 2:47 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev, Fengguang Wu
Fengguang Wu reported the following errors in the build of rtlwifi with
a random configuration:
tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux master
head: bcd7351e83728859833e3c5b8aae9a2816914e4b
commit: 06e7cda3ce30dadc3454539127b4cfc3888c349e rtlwifi: Rework Kconfig
date: 5 months ago
config: i386-randconfig-s05-0703
drivers/built-in.o: In function `rtl_usb_cleanup':
usb.c:(.text+0x114895): undefined reference to `usb_kill_anchored_urbs'
usb.c:(.text+0x114964): undefined reference to `usb_kill_anchored_urbs'
usb.c:(.text+0x11497c): undefined reference to `usb_kill_anchored_urbs'
drivers/built-in.o: In function `_usb_writeN_sync':
usb.c:(.text+0x114c9e): undefined reference to `usb_control_msg'
drivers/built-in.o: In function `rtl_usb_disconnect':
(.text+0x114d9c): undefined reference to `usb_put_dev'
drivers/built-in.o: In function `rtl_usb_start':
usb.c:(.text+0x114fb0): undefined reference to `usb_alloc_urb'
usb.c:(.text+0x115049): undefined reference to `usb_free_urb'
--snip--
Although I could not duplicate this result on my machine, it seemed likely
that it was due to the unusual configuration where rtlwifi was being built,
but none of its dependent drivers were selected.
The fix is to select rtlwifi only when it is needed. While making this
change, I simplified the configuration so that variable RTLWIFI is never seen
by the user. In addition, now that the rtlwifi family has six members, I
added a menu so that these drivers no longer appear in the long list of
wireless drivers, but in a separate panel.
Cc: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/rtlwifi/Kconfig | 57 +++++++++++++++++++++---------------
1 file changed, 34 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/Kconfig b/drivers/net/wireless/rtlwifi/Kconfig
index 7253de3..7552841 100644
--- a/drivers/net/wireless/rtlwifi/Kconfig
+++ b/drivers/net/wireless/rtlwifi/Kconfig
@@ -1,27 +1,18 @@
-config RTLWIFI
- tristate "Realtek wireless card support"
- depends on MAC80211
- select FW_LOADER
+menuconfig RTL_CARDS
+ tristate "Realtek rtlwifi family of devices"
+ depends on MAC80211 && (PCI || USB)
---help---
- This is common code for RTL8192CE/RTL8192CU/RTL8192SE/RTL8723AE
- drivers. This module does nothing by itself - the various front-end
- drivers need to be enabled to support any desired devices.
+ This option will enable support for the Realtek mac80211-based
+ wireless drivers. Drivers rtl8192ce, rtl8192cu, rtl8192se, rtl8192de,
+ rtl8723eu, and rtl8188eu share some common code.
- If you choose to build as a module, it'll be called rtlwifi.
-
-config RTLWIFI_DEBUG
- bool "Debugging output for rtlwifi driver family"
- depends on RTLWIFI
- default y
- ---help---
- To use the module option that sets the dynamic-debugging level for,
- the front-end driver, this parameter must be "Y". For memory-limited
- systems, choose "N". If in doubt, choose "Y".
+if RTL_CARDS
config RTL8192CE
tristate "Realtek RTL8192CE/RTL8188CE Wireless Network Adapter"
- depends on RTLWIFI && PCI
+ depends on PCI
select RTL8192C_COMMON
+ select RTLWIFI
---help---
This is the driver for Realtek RTL8192CE/RTL8188CE 802.11n PCIe
wireless network adapters.
@@ -30,7 +21,8 @@ config RTL8192CE
config RTL8192SE
tristate "Realtek RTL8192SE/RTL8191SE PCIe Wireless Network Adapter"
- depends on RTLWIFI && PCI
+ depends on PCI
+ select RTLWIFI
---help---
This is the driver for Realtek RTL8192SE/RTL8191SE 802.11n PCIe
wireless network adapters.
@@ -39,7 +31,8 @@ config RTL8192SE
config RTL8192DE
tristate "Realtek RTL8192DE/RTL8188DE PCIe Wireless Network Adapter"
- depends on RTLWIFI && PCI
+ depends on PCI
+ select RTLWIFI
---help---
This is the driver for Realtek RTL8192DE/RTL8188DE 802.11n PCIe
wireless network adapters.
@@ -48,7 +40,8 @@ config RTL8192DE
config RTL8723AE
tristate "Realtek RTL8723AE PCIe Wireless Network Adapter"
- depends on RTLWIFI && PCI
+ depends on PCI
+ select RTLWIFI
---help---
This is the driver for Realtek RTL8723AE 802.11n PCIe
wireless network adapters.
@@ -57,7 +50,8 @@ config RTL8723AE
config RTL8188EE
tristate "Realtek RTL8188EE Wireless Network Adapter"
- depends on RTLWIFI && PCI
+ depends on PCI
+ select RTLWIFI
---help---
This is the driver for Realtek RTL8188EE 802.11n PCIe
wireless network adapters.
@@ -66,7 +60,8 @@ config RTL8188EE
config RTL8192CU
tristate "Realtek RTL8192CU/RTL8188CU USB Wireless Network Adapter"
- depends on RTLWIFI && USB
+ depends on USB
+ select RTLWIFI
select RTL8192C_COMMON
---help---
This is the driver for Realtek RTL8192CU/RTL8188CU 802.11n USB
@@ -74,7 +69,22 @@ config RTL8192CU
If you choose to build it as a module, it will be called rtl8192cu
+config RTLWIFI
+ tristate
+ select FW_LOADER
+
+config RTLWIFI_DEBUG
+ bool "Debugging output for rtlwifi driver family"
+ depends on RTLWIFI
+ default y
+ ---help---
+ To use the module option that sets the dynamic-debugging level for,
+ the front-end driver, this parameter must be "Y". For memory-limited
+ systems, choose "N". If in doubt, choose "Y".
+
config RTL8192C_COMMON
tristate
depends on RTL8192CE || RTL8192CU
default m
+
+endif
--
1.8.1.4
^ permalink raw reply related
* Re: Fwd: User-level question: on wil6210
From: Vladimir Kondratiev @ 2013-07-07 7:51 UTC (permalink / raw)
To: Chang Liu
Cc: John W. Linville, Sujith Manoharan, erez.kirshenbaum,
linux-wireless
In-Reply-To: <CAGvsL42j1S-EFjQRn4hM3zf5s=MKJf9MVTNqOpyqJEp1DAMQ-Q@mail.gmail.com>
> On Friday, July 05, 2013 12:38:39 PM Chang Liu wrote:
>
> Dear Vladimir, and also John, Sujith and Vladimir,
>
> Thanks, thanks you all for such a kind help! I was wondering you are too
> busy to deal with this, but you do help a lot! I wish you could help me
> through this when you get a little free time. Currently I am a student and
> I am doing a project related with 60GHz communication. Now I have got the
> DELL 5000 Wireless Dock (WIFIg) and a Dell 6430u laptop, and I am trying
> to build up the 60GHz WIFI link (not the WIFI on 2.4G or 5G, and to make it
> clear, i will just call it 60G link) between the Dock and the laptop.
>
>
> This week I got all the devices and I find that, with the driver Dell
> offers, the link is successfully built in win7 platform. Dell offers a
> software to automatically detects the Dock and build the link. A snapshot
> of the link status is as follows:
>
>
> Status: SSID: D5000_C5907B; Channel: 2(60.48GHz); Security Mode: open;
> Firmware Version: 0.0.1.2989; BSSID: 04:ce:14:04:98:26
This is for WBE (not WiFi) link. It uses same infrastructure, but you can't
get WiFi connection.
>
> According to this, the hardware is working well. I tried this after I sent
> you the mail last time, so I didn't have chance to mention it.
>
>
> When I turn to Linux environment, I got problems building up the same link.
> My idea is to install the driver wil6210 as stated in
> (http://wireless.kernel.org/en/users/Drivers/wil6210) and follow the
> instructions on the page to set up the link between the laptop and the
> Dock.
>
>
> 0. Here comes the first question.
> In the webpage it also says
>
> "Chip consists of the root bridge 1ae9:0101, with 4 ports 1ae9:0201. One
> port routed to separate Atheros card 168c:0034, it is handled by the ath9k
> driver. Another port connected to the wil6210 device 1ae9:0301, that is on
> the same chip. 2 empty ports may be populated when connecting in WBE
> (PCIE-over-60g) mode. ">
> Does this mean that the wil6210 1ae9:0301 is actually for 60Gwifi while the
> atheros card 168c:0034 is for 2.4G/5G wifi?
Yes, exactly
> Since I can build the link in
> Windows platform, I believe I have the device wil6210 1ae9:0301 inside the
> laptop.
No. Device 1ae9:0301 may be hidden by firmware. Run "lspci -d 1ae9:0301"
to see whether device is present.
> Also you mentioned last time:
>
> On this card, there is firmware that is stored in the on-card flash memory,
> and is not loaded by the driver. Unfortunately, firmware on your laptop
> (and all laptops like this) flashed with device 1ae9:0301 disabled. This
> firmware support only so called WBE, that is essentially PCIE over 60g, for
> wireless docking. Wireless docking stations that are used with WBE are NOT
> access points; as far as I know there is no 60g access points available at
> this moment. You can run AP on another Linux laptop with wil6210.
>
> In order to support wifi, appropriate firmware need to be flashed on this
> card, and then you will see wi-fi device 1ae9:0301. To flash firmware, you
> need to contact Wilocity (adding Erez).
>
>
>
> You emphasized that the Dock is NOT an access point. You mean it's not an AP
> for 2.4GWIFI or 5GWIFI connection, right?
No, I mean it is not AP for 60g connection. Again, WBE is _NOT_ WiFi, and WBE
dock is not 60g AP.
> If I just want to build the 60G
> link, or WBE(do you mean wireless bus extension?), I don't need to ask for
> a new firmware, is it what you mean? With the current device (I mean the
> Dock and the laptop), I can build the 60G link between the laptop and the
> Dock as long as I get the driver (wil6210) installed in the laptop while do
> nothing to the Dock itself, is it right?
With your current firmware, you can establish WBE link; on Windows only since
WBE is not supported on Linux yet. You can not establish WiFi link with your
firmware with neither Linux nor Windows.
>
> 1. Have I installed the driver correctly?
I'd suggest to use latest kernel. At this moment, 3.10. I am not working on
back-porting, it is not tested. You are on your own if you want to use backport.
<skip>
> Does this mean that I have installed the driver wil6210 correctly?
Looks like it is compiled without errors. Without device present, I can't say
whether it works properly.
> (I didn't
> reload the module iwl4965, for I don't want WIFI, just 60G link).
>
>
> 2. About the network interface name and physical name <devname><phyname>.
> I assumed I installed the driver correctly. so I tried to build the link. My
> plan was to follow the webpage I mentioned above. First as I said in last
> letter, the identity (1ae9:0301) representing wil6210 is not shown with the
> command lspci -nn:
>
>
> root@george:/home/george# lspci -nn
<skip>
> [8086:1e22] (rev 04) 02:00.0 PCI bridge [0604]: Device [1ae9:0101] (rev 03)
> 03:00.0 PCI bridge [0604]: Device [1ae9:0200] (rev 03)
> 03:02.0 PCI bridge [0604]: Device [1ae9:0201] (rev 13)
> 03:03.0 PCI bridge [0604]: Device [1ae9:0201] (rev 13)
> 04:00.0 Network controller [0280]: Atheros Communications Inc. AR9462
> Wireless Network Adapter [168c:0034] (rev 01) 07:00.0 SD Host controller
> [0805]: O2 Micro, Inc. Device [1217:8221] (rev 05)
you have no 1ae9:301 device
>
>
> You mentioned the reason is because the firmware. We are contacting Wilocity
> now to get the firmware.
>
>
> What confuses me most now is the "network interface name". As shown on the
> page (http://wireless.kernel.org/en/users/Drivers/wil6210), I need to find
> the network interface name to execute the commands, which it represents
> with $WLAN. I cannot find where the interface comes from. I think it should
> be something like wlan*, when I tried ifconfig, it shows:
It comes from driver when it initializes its device. Without device, you will
not see network interface. Name will be like wlan0.
<skip>
> so there is no wlan*. Also these commands with iw shows nothing:
>
>
> root@george:/home/george# iw --version
> iw version 3.4
> root@george:/home/george# iw list
> root@george:/home/george# iw phy
> root@george:/home/george# iw dev
>
>
> So my biggest problem, what is the <phyname> , and what is the <devname>?
> Could you give me an example of the format? Where could I find it, or
> should set it myself? I searched google and they say wlan0 for 2.4G/5Gwifi
> will show up as long as the device and the driver are installed correctly.
> Is it the same situation for this case? If so, is the reason that I cannot
> see the interface the firmware you mentioned?
Yes, you have WBE-only firmware, so you have no device. No device - driver
don't bind to it - no network interface registered.
> Another little request is about the configuration instruction. Could you
> gave me some links on how to configure the driver wil6210? The only source
> I have now is the webpage I mentioned above and the help file for iw,
> wpa_supplicant. I lack experience, and I'm glad to learn more.
Read wiki for wpa_supplicant and iw
>
>
> Also, you mentioned I should download the latest iw and wpa_supplicant from
> Git, but I found a lot of folders I have no idea which could be a preferred
> choice. Could I beg you to give me a little more clue?
wpa_supplicant:
git clone git://w1.fi/srv/git/hostap.git
iw:
git clone http://git.sipsolutions.net/iw.git
> About the kernel, I
> would prefer to compile it and add it to the kernel because I may need to
> look inside the code later, so i keep the kernel version as 3.5 now.
Exactly for this reason, you better get kernel 3.10; then you have driver merged
into the kernel.
Thanks, Vladimir
^ permalink raw reply
* Re: [PATCH] rtlwifi: Fix Kconfig for some corner cases
From: Ben Hutchings @ 2013-07-07 9:42 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, netdev, Fengguang Wu
In-Reply-To: <1373165244-9536-1-git-send-email-Larry.Finger@lwfinger.net>
On Sat, 2013-07-06 at 21:47 -0500, Larry Finger wrote:
> Fengguang Wu reported the following errors in the build of rtlwifi with
> a random configuration:
>
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux master
> head: bcd7351e83728859833e3c5b8aae9a2816914e4b
> commit: 06e7cda3ce30dadc3454539127b4cfc3888c349e rtlwifi: Rework Kconfig
> date: 5 months ago
> config: i386-randconfig-s05-0703
>
> drivers/built-in.o: In function `rtl_usb_cleanup':
> usb.c:(.text+0x114895): undefined reference to `usb_kill_anchored_urbs'
> usb.c:(.text+0x114964): undefined reference to `usb_kill_anchored_urbs'
> usb.c:(.text+0x11497c): undefined reference to `usb_kill_anchored_urbs'
> drivers/built-in.o: In function `_usb_writeN_sync':
> usb.c:(.text+0x114c9e): undefined reference to `usb_control_msg'
> drivers/built-in.o: In function `rtl_usb_disconnect':
> (.text+0x114d9c): undefined reference to `usb_put_dev'
> drivers/built-in.o: In function `rtl_usb_start':
> usb.c:(.text+0x114fb0): undefined reference to `usb_alloc_urb'
> usb.c:(.text+0x115049): undefined reference to `usb_free_urb'
> --snip--
>
> Although I could not duplicate this result on my machine, it seemed likely
> that it was due to the unusual configuration where rtlwifi was being built,
> but none of its dependent drivers were selected.
I think it just requires:
CONFIG_USB=m
CONFIG_RTLWIFI=y
> The fix is to select rtlwifi only when it is needed.
I don't think so. Consider this configuration:
CONFIG_PCI=y
CONFIG_USB=m
CONFIG_RTL_CARDS=y
CONFIG_RTL8192CE=y
CONFIG_RTL8192CU=m
CONFIG_RTLWIFI=y # maximum of RTL8192CE=y and RTL8192CU=m
The same breakage occurs.
> While making this
> change, I simplified the configuration so that variable RTLWIFI is never seen
> by the user.
[...]
This will break existing configurations as RTL_CARDS defaults to n.
Perhaps you should introduce separate modules for the common PCI and USB
support code, similarly to how the rt2x00 modules are organised.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 01/20] rt2x00: rt2800lib: add MAC register initialization for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:07 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-2-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:40AM +0200, Gabor Juhos wrote:
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> Reference:
> NICInitRT3593MacRegisters in chips/rt3593.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 02/20] rt2x00: rt2800lib: add BBP register initialization for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:07 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-3-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:41AM +0200, Gabor Juhos wrote:
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> References:
> NICInitRT3593BbpRegisters in chips/rt3593.c
> NICInitBBP in common/rtmp_init.c
> NICInitAsicFromEEPROM in common/rtmp_init.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox