* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: José Miguel Gonçalves @ 2013-07-10 14:12 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <1373446089.8385.7.camel@cumari.coelho.fi>
On 10-07-2013 09:48, Luciano Coelho wrote:
> On Tue, 2013-07-09 at 14:22 +0100, José Miguel Gonçalves wrote:
>> On 09-07-2013 13:42, Arik Nemtsov wrote:
>>> On Tue, Jul 9, 2013 at 2:27 PM, José Miguel Gonçalves
>>> <jose.goncalves@inov.pt> wrote:
>>>
>>>> Any more ideas on how to debug this? Is there any specific debug_level mask
>>>> that can apply to the driver to help it?
>>> You can try the mask 0x63c20 (it's pretty verbose, so I would put it
>>> in pastebin).
>>>
>>> Perhaps this is a genuine problem with the antenna of the card?
>> Nope. The AP is 1 meter away form my board (even without antenna in the
>> card it should associate).
> Too strong a signal can also cause problems, because of distortion.
>
>
>>> Can
>>> you verify the RSSI of the AP is ok using iw?
>> The iw output:
>>
>> http://pastebin.com/XmEzqjHs
> This looks okay, but the RSSI value cannot be trusted blindly. There
> are other factors that can influence the signal quality, such as the
> SNR.
>
>
>> The dmesg output with debug mask set to 0x63c20:
>>
>> http://pastebin.com/zGE0Gfp8
>>
>> Note that with debug activated I did not see the driver's "Beacon loss
>> detected" messages.
> There could be some timing issue here. Is it always like that? Do you
> *always* see the "Beacon loss" messages without debugging and *never*
> with debugging?
>
Yep, is always like that!
José Gonçalves
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: José Miguel Gonçalves @ 2013-07-10 16:30 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <51DD54D4.6090502@inov.pt>
On 10-07-2013 13:34, José Miguel Gonçalves wrote:
>
> I will try a new AP to see how it behaves...
>
I've tested with my Android smartphone acting as an AP, without authentication,
and I'm also unable to associate!
I get from iw the following error message:
wlan0 (phy #0): failed to connect to b4:07:f9:49:cc:65, status: 1: Unspecified failure
Complete log is here:
http://pastebin.com/DzPmMw8i
So, something is definitely wrong with my setup... but what?
Hope that log has some useful info for you...
Best regards,
José Gonçalves
^ permalink raw reply
* Baseband watchdog timer tripping on AR9342
From: Harshal Chhaya @ 2013-07-10 16:43 UTC (permalink / raw)
To: linux-wireless
On an AR9342-based AP, we see non-zero counts for
RESET_TYPE_BB_WATCHDOG and RESET_TYPE_BEACON_STUCK when trying to do
large uplink transfers from ~60 clients with some of them 30-40 ft
away.
All the other reset types have a count of zero.
These resets cause all the clients to disconnect.
Any ideas on how to avoid these resets and the subsequent disconnections?
Thanks,
- Harshal
^ permalink raw reply
* Re: ath10k: mac80211 driver for Qualcomm Atheros 802.11ac CQA98xx devices
From: Geert Uytterhoeven @ 2013-07-10 17:12 UTC (permalink / raw)
To: Kalle Valo, John W. Linville
Cc: linux-wireless, netdev, Linux Kernel Development
In-Reply-To: <20130710022602.1F6F16609DE@gitolite.kernel.org>
On Wed, 10 Jul 2013, Linux Kernel Mailing List wrote:
> --- /dev/null
> +++ b/drivers/net/wireless/ath/ath10k/hw.h
> +#define SUPPORTED_FW_MAJOR 1
> +#define SUPPORTED_FW_MINOR 0
> +#define SUPPORTED_FW_RELEASE 0
> +#define SUPPORTED_FW_BUILD 629
> +static int ath10k_check_fw_version(struct ath10k *ar)
> +{
> + char version[32];
> +
> + if (ar->fw_version_major >= SUPPORTED_FW_MAJOR &&
> + ar->fw_version_minor >= SUPPORTED_FW_MINOR &&
> + ar->fw_version_release >= SUPPORTED_FW_RELEASE &&
> + ar->fw_version_build >= SUPPORTED_FW_BUILD)
> + return 0;
My attention got triggered by:
drivers/net/wireless/ath/ath10k/core.c: In function ‘ath10k_check_fw_version’:
drivers/net/wireless/ath/ath10k/core.c:79: warning: comparison is always true due to limited range of data type
as an u16 is always larger or equal than zero. Not much you can do to
silence that warning, though.
However, I don't think the version check is correct.
Shouldn't it stop checking later fields if an exact match is found in an
earlier field?
I.e.
if (ar->fw_version_major > SUPPORTED_FW_MAJOR ||
(ar->fw_version_major == SUPPORTED_FW_MAJOR &&
ar->fw_version_minor > SUPPORTED_FW_MINOR) ||
...) { ... }
Currently e.g. (major, minor) = (3, 0) is considered older than (2, 1).
Or perhaps minor is never reset to zero when major is increased? In that
case, the check is correct, but IMHO it's a bit silly to split the version
number in seperate fields.
> + snprintf(version, sizeof(version), "%u.%u.%u.%u",
> + SUPPORTED_FW_MAJOR, SUPPORTED_FW_MINOR,
> + SUPPORTED_FW_RELEASE, SUPPORTED_FW_BUILD);
> +
> + ath10k_warn("WARNING: Firmware version %s is not officially supported.\n",
> + ar->hw->wiphy->fw_version);
> + ath10k_warn("Please upgrade to version %s (or newer)\n", version);
> +
> + return 0;
> +}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: Luciano Coelho @ 2013-07-10 17:17 UTC (permalink / raw)
To: José Miguel Gonçalves; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <51DD8C20.7010900@inov.pt>
On Wed, 2013-07-10 at 17:30 +0100, José Miguel Gonçalves wrote:
> On 10-07-2013 13:34, José Miguel Gonçalves wrote:
> >
> > I will try a new AP to see how it behaves...
> >
>
> I've tested with my Android smartphone acting as an AP, without authentication,
> and I'm also unable to associate!
>
> I get from iw the following error message:
>
> wlan0 (phy #0): failed to connect to b4:07:f9:49:cc:65, status: 1: Unspecified failure
>
> Complete log is here:
>
> http://pastebin.com/DzPmMw8i
>
> So, something is definitely wrong with my setup... but what?
> Hope that log has some useful info for you...
This definitely looks like RF problems. Especially this:
[ 177.575000] wlan0: send auth to b4:07:f9:49:cc:65 (try 1/3)
[ 177.595000] wlan0: send auth to b4:07:f9:49:cc:65 (try 2/3)
[ 177.605000] wlcore: EVENT on mbox 1
[ 177.605000] wlcore: MBOX vector: 0x100000
[ 177.610000] wlcore: MAX_TX_FAILURE_EVENT_ID
[ 177.615000] wlan0: send auth to b4:07:f9:49:cc:65 (try 3/3)
[ 177.640000] wlan0: authentication with b4:07:f9:49:cc:65 timed out
You are send auth requests out, but not getting anything back.
Apparently you're not even getting ACKs (as pointed out by the
MAX_TX_FAILURE_EVENT_ID).
Do you have a sniffer? You could try to use your TP-Link dongle with
wireshark to see if it works fine as a sniffer.
My bet is that you'll see lots of retransmissions there. :\
--
Luca.
^ permalink raw reply
* Re: Baseband watchdog timer tripping on AR9342
From: Harshal Chhaya @ 2013-07-10 17:30 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CAJ8GFOg9c78f3ivnSiX1o2TCTPa2B3D_01Tiki-cK1=tgghuhQ@mail.gmail.com>
On Wed, Jul 10, 2013 at 11:43 AM, Harshal Chhaya <harshal@gmail.com> wrote:
> On an AR9342-based AP, we see non-zero counts for
> RESET_TYPE_BB_WATCHDOG and RESET_TYPE_BEACON_STUCK when trying to do
> large uplink transfers from ~60 clients with some of them 30-40 ft
> away.
>
> All the other reset types have a count of zero.
>
> These resets cause all the clients to disconnect.
>
> Any ideas on how to avoid these resets and the subsequent disconnections?
I forgot to mention that there were three "Failed to stop TX DMA"
messages on the debug port which seem to map to the
RESET_TYPE_BB_WATCHDOG events.
Regards,
- Harshal
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: José Miguel Gonçalves @ 2013-07-10 17:48 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <1373476663.8385.28.camel@cumari.coelho.fi>
On 10-07-2013 18:17, Luciano Coelho wrote:
> On Wed, 2013-07-10 at 17:30 +0100, José Miguel Gonçalves wrote:
>> On 10-07-2013 13:34, José Miguel Gonçalves wrote:
>>> I will try a new AP to see how it behaves...
>>>
>> I've tested with my Android smartphone acting as an AP, without authentication,
>> and I'm also unable to associate!
>>
>> I get from iw the following error message:
>>
>> wlan0 (phy #0): failed to connect to b4:07:f9:49:cc:65, status: 1: Unspecified failure
>>
>> Complete log is here:
>>
>> http://pastebin.com/DzPmMw8i
>>
>> So, something is definitely wrong with my setup... but what?
>> Hope that log has some useful info for you...
> This definitely looks like RF problems. Especially this:
>
> [ 177.575000] wlan0: send auth to b4:07:f9:49:cc:65 (try 1/3)
> [ 177.595000] wlan0: send auth to b4:07:f9:49:cc:65 (try 2/3)
> [ 177.605000] wlcore: EVENT on mbox 1
> [ 177.605000] wlcore: MBOX vector: 0x100000
> [ 177.610000] wlcore: MAX_TX_FAILURE_EVENT_ID
> [ 177.615000] wlan0: send auth to b4:07:f9:49:cc:65 (try 3/3)
> [ 177.640000] wlan0: authentication with b4:07:f9:49:cc:65 timed out
>
> You are send auth requests out, but not getting anything back.
> Apparently you're not even getting ACKs (as pointed out by the
> MAX_TX_FAILURE_EVENT_ID).
Hum. I never considered RF problems because I'm testing this module with a
Jorjin's development kit, so I was considering that Jorjin knows how to make PCBs
for RF. Also seeing that when I remove the antenna the AP signal strength changes
from -51 dBm to -73 dBm was a signal to me that the RF was OK.
>
> Do you have a sniffer? You could try to use your TP-Link dongle with
> wireshark to see if it works fine as a sniffer.
I have a text console only system. I could put tcpdump on my system, but I think I
can not monitor wireless traffic with it, or can I?
José Gonçalves
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: Larry Finger @ 2013-07-10 18:16 UTC (permalink / raw)
To: José Miguel Gonçalves
Cc: Luciano Coelho, Arik Nemtsov, linux-wireless
In-Reply-To: <51DD9E6C.5060008@inov.pt>
On 07/10/2013 12:48 PM, José Miguel Gonçalves wrote:
> On 10-07-2013 18:17, Luciano Coelho wrote:
>> On Wed, 2013-07-10 at 17:30 +0100, José Miguel Gonçalves wrote:
>>> On 10-07-2013 13:34, José Miguel Gonçalves wrote:
>>>> I will try a new AP to see how it behaves...
>>>>
>>> I've tested with my Android smartphone acting as an AP, without authentication,
>>> and I'm also unable to associate!
>>>
>>> I get from iw the following error message:
>>>
>>> wlan0 (phy #0): failed to connect to b4:07:f9:49:cc:65, status: 1:
>>> Unspecified failure
>>>
>>> Complete log is here:
>>>
>>> http://pastebin.com/DzPmMw8i
>>>
>>> So, something is definitely wrong with my setup... but what?
>>> Hope that log has some useful info for you...
>> This definitely looks like RF problems. Especially this:
>>
>> [ 177.575000] wlan0: send auth to b4:07:f9:49:cc:65 (try 1/3)
>> [ 177.595000] wlan0: send auth to b4:07:f9:49:cc:65 (try 2/3)
>> [ 177.605000] wlcore: EVENT on mbox 1
>> [ 177.605000] wlcore: MBOX vector: 0x100000
>> [ 177.610000] wlcore: MAX_TX_FAILURE_EVENT_ID
>> [ 177.615000] wlan0: send auth to b4:07:f9:49:cc:65 (try 3/3)
>> [ 177.640000] wlan0: authentication with b4:07:f9:49:cc:65 timed out
>>
>> You are send auth requests out, but not getting anything back.
>> Apparently you're not even getting ACKs (as pointed out by the
>> MAX_TX_FAILURE_EVENT_ID).
>
> Hum. I never considered RF problems because I'm testing this module with a
> Jorjin's development kit, so I was considering that Jorjin knows how to make
> PCBs for RF. Also seeing that when I remove the antenna the AP signal strength
> changes from -51 dBm to -73 dBm was a signal to me that the RF was OK.
>
>>
>> Do you have a sniffer? You could try to use your TP-Link dongle with
>> wireshark to see if it works fine as a sniffer.
>
> I have a text console only system. I could put tcpdump on my system, but I think
> I can not monitor wireless traffic with it, or can I?
I use Kismet to monitor the air on a text-only system.
Larry
^ permalink raw reply
* Re: [PATCH 2/2] ath9k_htc: reboot firmware if it was loaded
From: Adrian Chadd @ 2013-07-10 19:27 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <1373438404-5871-2-git-send-email-linux@rempel-privat.de>
Great catch!
-adrian
On 9 July 2013 23:40, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Currently ath9k_htc will reboot firmware only if interface was
> ever started. Which lead to the problem in case where interface
> was never started but module need to be reloaded.
>
> This patch will partially fix bug "ath9k_htc: Target is unresponsive"
> https://github.com/qca/open-ath9k-htc-firmware/issues/1
>
> Reproduction case:
> - plug adapter
> - make sure nothing will touch it. Stop Networkmanager or blacklist mac address of this adapter.
> - rmmod ath9k_htc; sleep 1; modprobe ath9k_htc
>
> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
> ---
> drivers/net/wireless/ath/ath9k/hif_usb.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
> index 2469db5..5205a36 100644
> --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
> @@ -1295,7 +1295,9 @@ static void ath9k_hif_usb_disconnect(struct usb_interface *interface)
>
> usb_set_intfdata(interface, NULL);
>
> - if (!unplugged && (hif_dev->flags & HIF_USB_START))
> + /* If firmware was loaded we should drop it
> + * go back to first stage bootloader. */
> + if (!unplugged && (hif_dev->flags & HIF_USB_READY))
> ath9k_hif_usb_reboot(udev);
>
> kfree(hif_dev);
> --
> 1.8.1.2
>
> --
> 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: wl127x: Unable to associate with a WPA2-PSK AP
From: Luciano Coelho @ 2013-07-10 20:27 UTC (permalink / raw)
To: José Miguel Gonçalves; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <51DD9E6C.5060008@inov.pt>
On Wed, 2013-07-10 at 18:48 +0100, José Miguel Gonçalves wrote:
> On 10-07-2013 18:17, Luciano Coelho wrote:
> > On Wed, 2013-07-10 at 17:30 +0100, José Miguel Gonçalves wrote:
> >> On 10-07-2013 13:34, José Miguel Gonçalves wrote:
> >>> I will try a new AP to see how it behaves...
> >>>
> >> I've tested with my Android smartphone acting as an AP, without authentication,
> >> and I'm also unable to associate!
> >>
> >> I get from iw the following error message:
> >>
> >> wlan0 (phy #0): failed to connect to b4:07:f9:49:cc:65, status: 1: Unspecified failure
> >>
> >> Complete log is here:
> >>
> >> http://pastebin.com/DzPmMw8i
> >>
> >> So, something is definitely wrong with my setup... but what?
> >> Hope that log has some useful info for you...
> > This definitely looks like RF problems. Especially this:
> >
> > [ 177.575000] wlan0: send auth to b4:07:f9:49:cc:65 (try 1/3)
> > [ 177.595000] wlan0: send auth to b4:07:f9:49:cc:65 (try 2/3)
> > [ 177.605000] wlcore: EVENT on mbox 1
> > [ 177.605000] wlcore: MBOX vector: 0x100000
> > [ 177.610000] wlcore: MAX_TX_FAILURE_EVENT_ID
> > [ 177.615000] wlan0: send auth to b4:07:f9:49:cc:65 (try 3/3)
> > [ 177.640000] wlan0: authentication with b4:07:f9:49:cc:65 timed out
> >
> > You are send auth requests out, but not getting anything back.
> > Apparently you're not even getting ACKs (as pointed out by the
> > MAX_TX_FAILURE_EVENT_ID).
>
> Hum. I never considered RF problems because I'm testing this module with a
> Jorjin's development kit, so I was considering that Jorjin knows how to make PCBs
> for RF. Also seeing that when I remove the antenna the AP signal strength changes
> from -51 dBm to -73 dBm was a signal to me that the RF was OK.
>
> >
> > Do you have a sniffer? You could try to use your TP-Link dongle with
> > wireshark to see if it works fine as a sniffer.
>
> I have a text console only system. I could put tcpdump on my system, but I think I
> can not monitor wireless traffic with it, or can I?
tcpdump will probably not be enough. But since this stuff is *wireless*
you can sniff from a different PC. If you have Linux PC, just plug in
your TP-Link dongle in it, launch wireshark and you should be able to
sniff (unencrypted) connections between other devices easily.
You can also sniff encrypted connections, but it's slightly more
difficult. Also, I've had problems when sniffing 802.11n (more
specifically BA sessions), but you're not getting that far, so it should
be possible to see some good results with simple sniffers.
--
Luca.
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: Luciano Coelho @ 2013-07-10 20:29 UTC (permalink / raw)
To: Larry Finger
Cc: José Miguel Gonçalves, Arik Nemtsov, linux-wireless
In-Reply-To: <51DDA50F.9050909@lwfinger.net>
On Wed, 2013-07-10 at 13:16 -0500, Larry Finger wrote:
> On 07/10/2013 12:48 PM, José Miguel Gonçalves wrote:
> > On 10-07-2013 18:17, Luciano Coelho wrote:
> >> On Wed, 2013-07-10 at 17:30 +0100, José Miguel Gonçalves wrote:
> >>> On 10-07-2013 13:34, José Miguel Gonçalves wrote:
> >>>> I will try a new AP to see how it behaves...
> >>>>
> >>> I've tested with my Android smartphone acting as an AP, without authentication,
> >>> and I'm also unable to associate!
> >>>
> >>> I get from iw the following error message:
> >>>
> >>> wlan0 (phy #0): failed to connect to b4:07:f9:49:cc:65, status: 1:
> >>> Unspecified failure
> >>>
> >>> Complete log is here:
> >>>
> >>> http://pastebin.com/DzPmMw8i
> >>>
> >>> So, something is definitely wrong with my setup... but what?
> >>> Hope that log has some useful info for you...
> >> This definitely looks like RF problems. Especially this:
> >>
> >> [ 177.575000] wlan0: send auth to b4:07:f9:49:cc:65 (try 1/3)
> >> [ 177.595000] wlan0: send auth to b4:07:f9:49:cc:65 (try 2/3)
> >> [ 177.605000] wlcore: EVENT on mbox 1
> >> [ 177.605000] wlcore: MBOX vector: 0x100000
> >> [ 177.610000] wlcore: MAX_TX_FAILURE_EVENT_ID
> >> [ 177.615000] wlan0: send auth to b4:07:f9:49:cc:65 (try 3/3)
> >> [ 177.640000] wlan0: authentication with b4:07:f9:49:cc:65 timed out
> >>
> >> You are send auth requests out, but not getting anything back.
> >> Apparently you're not even getting ACKs (as pointed out by the
> >> MAX_TX_FAILURE_EVENT_ID).
> >
> > Hum. I never considered RF problems because I'm testing this module with a
> > Jorjin's development kit, so I was considering that Jorjin knows how to make
> > PCBs for RF. Also seeing that when I remove the antenna the AP signal strength
> > changes from -51 dBm to -73 dBm was a signal to me that the RF was OK.
> >
> >>
> >> Do you have a sniffer? You could try to use your TP-Link dongle with
> >> wireshark to see if it works fine as a sniffer.
> >
> > I have a text console only system. I could put tcpdump on my system, but I think
> > I can not monitor wireless traffic with it, or can I?
>
> I use Kismet to monitor the air on a text-only system.
This looks pretty cool, I hadn't seen it before. Thanks for sharing! :)
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH 2/3] rt2x00: RT2X00 should depend on HAS_DMA
From: Geert Uytterhoeven @ 2013-07-10 21:03 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Geert Uytterhoeven, linux-wireless
In-Reply-To: <1373490216-12437-1-git-send-email-geert@linux-m68k.org>
If NO_DMA=y:
drivers/built-in.o: In function `rt2x00queue_unmap_skb':
drivers/net/wireless/rt2x00/rt2x00queue.c:129: undefined reference to `dma_unmap_single'
drivers/net/wireless/rt2x00/rt2x00queue.c:133: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `rt2x00queue_map_txskb':
drivers/net/wireless/rt2x00/rt2x00queue.c:112: undefined reference to `dma_map_single'
drivers/net/wireless/rt2x00/rt2x00queue.c:115: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `rt2x00queue_alloc_rxskb':
drivers/net/wireless/rt2x00/rt2x00queue.c:93: undefined reference to `dma_map_single'
drivers/net/wireless/rt2x00/rt2x00queue.c:95: undefined reference to `dma_mapping_error'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-wireless@vger.kernel.org
---
drivers/net/wireless/rt2x00/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
index 9b915d3..3e60a31 100644
--- a/drivers/net/wireless/rt2x00/Kconfig
+++ b/drivers/net/wireless/rt2x00/Kconfig
@@ -1,6 +1,6 @@
menuconfig RT2X00
tristate "Ralink driver support"
- depends on MAC80211
+ depends on MAC80211 && HAS_DMA
---help---
This will enable the support for the Ralink drivers,
developed in the rt2x00 project <http://rt2x00.serialmonkey.com>.
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/3] ath10k: ATH10K should depend on HAS_DMA
From: Geert Uytterhoeven @ 2013-07-10 21:03 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Geert Uytterhoeven, linux-wireless
In-Reply-To: <1373490216-12437-1-git-send-email-geert@linux-m68k.org>
If NO_DMA=y:
drivers/built-in.o: In function `ath10k_skb_unmap':
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath10k_skb_map':
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_htt_rx_ring_free':
drivers/net/wireless/ath/ath10k/htt_rx.c:113: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath10k_htt_rx_amsdu_pop':
drivers/net/wireless/ath/ath10k/htt_rx.c:296: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/htt_rx.c:389: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `__ath10k_htt_rx_ring_fill_n':
drivers/net/wireless/ath/ath10k/htt_rx.c:146: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/htt_rx.c:150: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_htt_rx_attach':
drivers/net/wireless/ath/ath10k/htt_rx.c:474: undefined reference to `dma_alloc_coherent'
drivers/net/wireless/ath/ath10k/htt_rx.c:509: undefined reference to `dma_free_coherent'
drivers/net/wireless/ath/ath10k/htt_rx.c:514: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `ath10k_htt_rx_detach':
drivers/net/wireless/ath/ath10k/htt_rx.c:220: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/htt_rx.c:228: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `ath10k_skb_map':
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_skb_unmap':
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath10k_skb_map':
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_skb_unmap':
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-wireless@vger.kernel.org
---
drivers/net/wireless/ath/ath10k/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/Kconfig b/drivers/net/wireless/ath/ath10k/Kconfig
index cde58fe..82e8088 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -1,6 +1,6 @@
config ATH10K
tristate "Atheros 802.11ac wireless cards support"
- depends on MAC80211
+ depends on MAC80211 && HAS_DMA
select ATH_COMMON
---help---
This module adds support for wireless adapters based on
--
1.7.9.5
^ permalink raw reply related
* Re: ralink 3290: still lots of misc errors reported by Iwconfig with 3.10 + HD streaming on WiFi fails
From: Eric Valette @ 2013-07-11 6:31 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless
In-Reply-To: <20130710113158.GA3887@redhat.com>
On 10/07/2013 13:31, Stanislaw Gruszka wrote:
> On Tue, Jul 09, 2013 at 05:00:45PM +0200, Eric Valette wrote:
>> On 07/09/2013 04:35 PM, Eric Valette wrote:
>>
>>>> Do you mean that 3.10 perform better than 3.9.9 ? I do not see any
>>>> rt2x00 fixes between 3.9 and 3.10 that are not yet applied on 3.9.9.
>>>> I can see only some cleanups and new hardware support patches.
>>>
>>> From memory I think I had a lot of reported TX error with 3.9.9 and
>>> they are now gone with 3.10 but the number of misc error reported by
>>> iwconfig is still high with 3.10. But you are right the fix for TX is
>>> still in wireless git and does not seem to be in 3.10. As I checked
>>> several git trees I mist have been confused...
>>
>> Unless I'm really tired, this patch is in 3.10 and not in 3.9.9 :
>>
>> http://git.kernel.org/cgit/linux/kernel/git/linville/wireless-testing.git/patch/drivers/net/wireless/rt2x00?id=8857d6dc77e4e3afeee2f33c49597010130ed858
>
> You have right, I missed that one. It's on 3.10 but not on 3.9. We could
> post it to 3.9 -stable, but since 3.10 is now realised, 3.9 will become
> end of life probably.
Usually there is a small overlap at least until .1 or .2. For me it
fixes reported TX errors but cannot test if it also fixes link
quality/throughput due to lack of AMD/ati drivers.
Thanks again for your time.
--eric
^ permalink raw reply
* [PATCH 0/3] wil6210 updates
From: Vladimir Kondratiev @ 2013-07-11 7:12 UTC (permalink / raw)
To: John W . Linville
Cc: Vladimir Kondratiev, Johannes Berg, linux-wireless,
Luis R . Rodriguez
Sync with latest firmware updates;
couple of simple bug fixes
Vladimir Kondratiev (3):
wil6210: Align WMI header with latest FW
wil6210: fix wrong index in wil_vring_free
wil6210: write modified HW descriptor back
drivers/net/wireless/ath/wil6210/trace.h | 22 +++++++++++++---------
drivers/net/wireless/ath/wil6210/txrx.c | 3 ++-
drivers/net/wireless/ath/wil6210/wil6210.h | 17 ++++++++++++++---
drivers/net/wireless/ath/wil6210/wmi.c | 14 +++++++++-----
4 files changed, 38 insertions(+), 18 deletions(-)
--
1.8.1.2
^ permalink raw reply
* [PATCH 1/3] wil6210: Align WMI header with latest FW
From: Vladimir Kondratiev @ 2013-07-11 7:12 UTC (permalink / raw)
To: John W . Linville
Cc: Vladimir Kondratiev, Johannes Berg, linux-wireless,
Luis R . Rodriguez
In-Reply-To: <1373526729-10908-1-git-send-email-qca_vkondrat@qca.qualcomm.com>
FW guys changed header structure; align driver code
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
---
drivers/net/wireless/ath/wil6210/trace.h | 22 +++++++++++++---------
drivers/net/wireless/ath/wil6210/wil6210.h | 17 ++++++++++++++---
drivers/net/wireless/ath/wil6210/wmi.c | 14 +++++++++-----
3 files changed, 36 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/trace.h b/drivers/net/wireless/ath/wil6210/trace.h
index eff1239..e59239d 100644
--- a/drivers/net/wireless/ath/wil6210/trace.h
+++ b/drivers/net/wireless/ath/wil6210/trace.h
@@ -37,36 +37,40 @@ static inline void trace_ ## name(proto) {}
#endif /* !CONFIG_WIL6210_TRACING || defined(__CHECKER__) */
DECLARE_EVENT_CLASS(wil6210_wmi,
- TP_PROTO(u16 id, void *buf, u16 buf_len),
+ TP_PROTO(struct wil6210_mbox_hdr_wmi *wmi, void *buf, u16 buf_len),
- TP_ARGS(id, buf, buf_len),
+ TP_ARGS(wmi, buf, buf_len),
TP_STRUCT__entry(
+ __field(u8, mid)
__field(u16, id)
+ __field(u32, timestamp)
__field(u16, buf_len)
__dynamic_array(u8, buf, buf_len)
),
TP_fast_assign(
- __entry->id = id;
+ __entry->mid = wmi->mid;
+ __entry->id = le16_to_cpu(wmi->id);
+ __entry->timestamp = le32_to_cpu(wmi->timestamp);
__entry->buf_len = buf_len;
memcpy(__get_dynamic_array(buf), buf, buf_len);
),
TP_printk(
- "id 0x%04x len %d",
- __entry->id, __entry->buf_len
+ "MID %d id 0x%04x len %d timestamp %d",
+ __entry->mid, __entry->id, __entry->buf_len, __entry->timestamp
)
);
DEFINE_EVENT(wil6210_wmi, wil6210_wmi_cmd,
- TP_PROTO(u16 id, void *buf, u16 buf_len),
- TP_ARGS(id, buf, buf_len)
+ TP_PROTO(struct wil6210_mbox_hdr_wmi *wmi, void *buf, u16 buf_len),
+ TP_ARGS(wmi, buf, buf_len)
);
DEFINE_EVENT(wil6210_wmi, wil6210_wmi_event,
- TP_PROTO(u16 id, void *buf, u16 buf_len),
- TP_ARGS(id, buf, buf_len)
+ TP_PROTO(struct wil6210_mbox_hdr_wmi *wmi, void *buf, u16 buf_len),
+ TP_ARGS(wmi, buf, buf_len)
);
#define WIL6210_MSG_MAX (200)
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h b/drivers/net/wireless/ath/wil6210/wil6210.h
index 44fdab5..129c480 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -156,11 +156,22 @@ struct wil6210_mbox_hdr {
/* max. value for wil6210_mbox_hdr.len */
#define MAX_MBOXITEM_SIZE (240)
+/**
+ * struct wil6210_mbox_hdr_wmi - WMI header
+ *
+ * @mid: MAC ID
+ * 00 - default, created by FW
+ * 01..0f - WiFi ports, driver to create
+ * 10..fe - debug
+ * ff - broadcast
+ * @id: command/event ID
+ * @timestamp: FW fills for events, free-running msec timer
+ */
struct wil6210_mbox_hdr_wmi {
- u8 reserved0[2];
+ u8 mid;
+ u8 reserved;
__le16 id;
- __le16 info1; /* bits [0..3] - device_id, rest - unused */
- u8 reserved1[2];
+ __le32 timestamp;
} __packed;
struct pending_wmi_event {
diff --git a/drivers/net/wireless/ath/wil6210/wmi.c b/drivers/net/wireless/ath/wil6210/wmi.c
index dc8059a..a62511a 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -172,8 +172,8 @@ static int __wmi_send(struct wil6210_priv *wil, u16 cmdid, void *buf, u16 len)
.len = cpu_to_le16(sizeof(cmd.wmi) + len),
},
.wmi = {
+ .mid = 0,
.id = cpu_to_le16(cmdid),
- .info1 = 0,
},
};
struct wil6210_mbox_ring *r = &wil->mbox_ctl.tx;
@@ -248,7 +248,7 @@ static int __wmi_send(struct wil6210_priv *wil, u16 cmdid, void *buf, u16 len)
iowrite32(r->head = next_head, wil->csr + HOST_MBOX +
offsetof(struct wil6210_mbox_ctl, tx.head));
- trace_wil6210_wmi_cmd(cmdid, buf, len);
+ trace_wil6210_wmi_cmd(&cmd.wmi, buf, len);
/* interrupt to FW */
iowrite32(SW_INT_MBOX, wil->csr + HOST_SW_INT);
@@ -640,9 +640,13 @@ void wmi_recv_cmd(struct wil6210_priv *wil)
hdr.flags);
if ((hdr.type == WIL_MBOX_HDR_TYPE_WMI) &&
(len >= sizeof(struct wil6210_mbox_hdr_wmi))) {
- u16 id = le16_to_cpu(evt->event.wmi.id);
- wil_dbg_wmi(wil, "WMI event 0x%04x\n", id);
- trace_wil6210_wmi_event(id, &evt->event.wmi, len);
+ struct wil6210_mbox_hdr_wmi *wmi = &evt->event.wmi;
+ u16 id = le16_to_cpu(wmi->id);
+ u32 tstamp = le32_to_cpu(wmi->timestamp);
+ wil_dbg_wmi(wil, "WMI event 0x%04x MID %d @%d msec\n",
+ id, wmi->mid, tstamp);
+ trace_wil6210_wmi_event(wmi, &wmi[1],
+ len - sizeof(*wmi));
}
wil_hex_dump_wmi("evt ", DUMP_PREFIX_OFFSET, 16, 1,
&evt->event.hdr, sizeof(hdr) + len, true);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 2/3] wil6210: fix wrong index in wil_vring_free
From: Vladimir Kondratiev @ 2013-07-11 7:12 UTC (permalink / raw)
To: John W . Linville
Cc: Vladimir Kondratiev, Johannes Berg, linux-wireless,
Luis R . Rodriguez
In-Reply-To: <1373526729-10908-1-git-send-email-qca_vkondrat@qca.qualcomm.com>
When destroying Rx vring, branch for Rx used wrong Tx descriptor:
while SW context was taken for "head", HW descriptor was, by mistake,
taken from "tail"
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
---
drivers/net/wireless/ath/wil6210/txrx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wil6210/txrx.c b/drivers/net/wireless/ath/wil6210/txrx.c
index d240b24..8fde73a 100644
--- a/drivers/net/wireless/ath/wil6210/txrx.c
+++ b/drivers/net/wireless/ath/wil6210/txrx.c
@@ -133,7 +133,7 @@ static void wil_vring_free(struct wil6210_priv *wil, struct vring *vring,
} else { /* rx */
struct vring_rx_desc dd, *d = ⅆ
volatile struct vring_rx_desc *_d =
- &vring->va[vring->swtail].rx;
+ &vring->va[vring->swhead].rx;
*d = *_d;
pa = wil_desc_addr(&d->dma.addr);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 3/3] wil6210: write modified HW descriptor back
From: Vladimir Kondratiev @ 2013-07-11 7:12 UTC (permalink / raw)
To: John W . Linville
Cc: Vladimir Kondratiev, Johannes Berg, linux-wireless,
Luis R . Rodriguez
In-Reply-To: <1373526729-10908-1-git-send-email-qca_vkondrat@qca.qualcomm.com>
HW descriptor copied from vring in un-cached memory to normal memory;
in tx completion it was not written back after modification. Fix it.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
---
drivers/net/wireless/ath/wil6210/txrx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/wil6210/txrx.c b/drivers/net/wireless/ath/wil6210/txrx.c
index 8fde73a..7cf5c94 100644
--- a/drivers/net/wireless/ath/wil6210/txrx.c
+++ b/drivers/net/wireless/ath/wil6210/txrx.c
@@ -859,6 +859,7 @@ int wil_tx_complete(struct wil6210_priv *wil, int ringid)
d->dma.addr.addr_high = 0;
d->dma.length = 0;
d->dma.status = TX_DMA_STATUS_DU;
+ *_d = *d;
vring->swtail = wil_vring_next_tail(vring);
done++;
}
--
1.8.1.2
^ permalink raw reply related
* Re: backports based on next-20130618
From: Luis R. Rodriguez @ 2013-07-11 7:34 UTC (permalink / raw)
To: backports@vger.kernel.org; +Cc: netdev@vger.kernel.org, linux-wireless
In-Reply-To: <CAB=NE6Vf0BO_d=qPrpU=mYAv6DeRPanQqV6BshkVjJ0Tf4ponw@mail.gmail.com>
On Mon, Jul 1, 2013 at 2:39 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> On Mon, Jul 1, 2013 at 2:25 PM, Luis R. Rodriguez
> <mcgrof@do-not-panic.com> wrote:
>> A new backports release has been made based on next-20130618, this has
>> the new upstream alx driver, and the ath10k driver.
>>
>> https://www.kernel.org/pub/linux/kernel/projects/backports/2013/06/18/backports-20130618.tar.bz2
>
> Sorry it just has alx, ath10k requires a small patch that I think
> someone has sitting somewhere, next release.
Nevermind, it was in already and in fact compiled fine as part of this release.
CC [M] /home/mcgrof/tmp/poo/backports-20130618/drivers/net/wireless/ath/ath10k/mac.o
CC [M] /home/mcgrof/tmp/poo/backports-20130618/drivers/net/wireless/ath/ath10k/debug.o
CC [M] /home/mcgrof/tmp/poo/backports-20130618/drivers/net/wireless/ath/ath10k/core.o
CC [M] /home/mcgrof/tmp/poo/backports-20130618/drivers/net/wireless/ath/ath10k/htc.o
CC [M] /home/mcgrof/tmp/poo/backports-20130618/drivers/net/wireless/ath/ath10k/htt.o
CC [M] /home/mcgrof/tmp/poo/backports-20130618/drivers/net/wireless/ath/ath10k/htt_rx.o
CC [M] /home/mcgrof/tmp/poo/backports-20130618/drivers/net/wireless/ath/ath10k/htt_tx.o
CC [M] /home/mcgrof/tmp/poo/backports-20130618/drivers/net/wireless/ath/ath10k/txrx.o
CC [M] /home/mcgrof/tmp/poo/backports-20130618/drivers/net/wireless/ath/ath10k/wmi.o
CC [M] /home/mcgrof/tmp/poo/backports-20130618/drivers/net/wireless/ath/ath10k/bmi.o
LD [M] /home/mcgrof/tmp/poo/backports-20130618/drivers/net/wireless/ath/ath10k/ath10k_core.o
Luis
^ permalink raw reply
* Re: ath10k: mac80211 driver for Qualcomm Atheros 802.11ac CQA98xx devices
From: Kalle Valo @ 2013-07-11 8:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: John W. Linville, linux-wireless, netdev,
Linux Kernel Development, ath10k
In-Reply-To: <alpine.DEB.2.02.1307101859360.29717@ayla.of.borg>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> On Wed, 10 Jul 2013, Linux Kernel Mailing List wrote:
>> --- /dev/null
>> +++ b/drivers/net/wireless/ath/ath10k/hw.h
>
>> +#define SUPPORTED_FW_MAJOR 1
>> +#define SUPPORTED_FW_MINOR 0
>> +#define SUPPORTED_FW_RELEASE 0
>> +#define SUPPORTED_FW_BUILD 629
>
>> +static int ath10k_check_fw_version(struct ath10k *ar)
>> +{
>> + char version[32];
>> +
>> + if (ar->fw_version_major >= SUPPORTED_FW_MAJOR &&
>> + ar->fw_version_minor >= SUPPORTED_FW_MINOR &&
>> + ar->fw_version_release >= SUPPORTED_FW_RELEASE &&
>> + ar->fw_version_build >= SUPPORTED_FW_BUILD)
>> + return 0;
>
> My attention got triggered by:
>
> drivers/net/wireless/ath/ath10k/core.c: In function ‘ath10k_check_fw_version’:
> drivers/net/wireless/ath/ath10k/core.c:79: warning: comparison is always true due to limited range of data type
I haven't seen this warning, I guess my compiler is too old.
> as an u16 is always larger or equal than zero. Not much you can do to
> silence that warning, though.
Too bad, I really would like to keep ath10k warning free. Easier to
maintain that way.
Does anyone have any nice trick in their sleeves to make this warning go
away? I guess one ugly option is to change u16 to int.
>
> However, I don't think the version check is correct.
> Shouldn't it stop checking later fields if an exact match is found in an
> earlier field?
>
> I.e.
>
> if (ar->fw_version_major > SUPPORTED_FW_MAJOR ||
> (ar->fw_version_major == SUPPORTED_FW_MAJOR &&
> ar->fw_version_minor > SUPPORTED_FW_MINOR) ||
> ...) { ... }
>
> Currently e.g. (major, minor) = (3, 0) is considered older than (2, 1).
Doh, that is indeed wrong. I'll fix that, thanks for spotting this.
> Or perhaps minor is never reset to zero when major is increased? In that
> case, the check is correct, but IMHO it's a bit silly to split the version
> number in seperate fields.
No, the firmware engineers are supposed to reset minor version whenever
major changes.
--
Kalle Valo
^ permalink raw reply
* [RFC]: vlan priority handling in WMM
From: Cedric Debarge @ 2013-07-11 7:45 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless
Dear mailing list,
I would like to manage the VLAN priority in Wireless QOS (WMM).
I get the VLAN tag from skb->vlan_tci and I extract the VLAN priority.
How I should handle the priority value 0.
- Handle this value as no priority request, In this case the frame will
sent with the DSCP priority or default (Best effort)
- Handle this value as a lowest priority, in this case I Map it to the WMM.
For your information, you can found below a discussion on this point
with Johannes Berg.
Regards.
Cedric Voncken.
-----Message d'origine-----
De : Johannes Berg [mailto:johannes@sipsolutions.net]
Envoyé : lundi 8 juillet 2013 14:16
À : voncken
Cc : linux-wireless@vger.kernel.org
Objet : Re: [PATCH V2] vlan priority handling in WMM
On Mon, 2013-07-08 at 12:39 +0200, voncken wrote:
> > > 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.
>
> > Yes but don't we know that the vlan_tci field is valid?
>
> > I don't think you're correct in that 0 means "no priority present",
> it actually means "best effort" as far as I can tell. Ignoring the
> VLAN tag when the field is 0 would mean we could use a higher priority
> from the contents of the frame, which would not be desired?
>
> I can add a test with the macro vlan_tx_tag_present() to verify if the
> vlan_tci field is valid.
> I test the value 0 to skip the VLAN priority and use the dscp priority
> in this case. The priority 0 in VLAN tag is often use to turn off the
> QOS, because not bit is allowed for it.
What do you mean by "is often used"? I don't see how that would be the case? Are you saying routers commonly ignore the VLAN priority value if it's 0? That would seem odd?
> For me is it correct. Nevertheless, if you prefer, I can test only the
> vlan_tci validity and in this case always use the VLAN priority.
I don't know! Since you don't seem to really know either, we should ask somebody who knows, I think. Maybe you should Cc netdev with this question on the patch or so?
> Sorry I made a mistake 0xE000 >>13 = 0x0007 and not 0x0003, and 7 is
> a 3 bits value.
Ah yes, I made the same mistake, sorry.
johannes
^ permalink raw reply
* Re: [WT PATCH 1/6] mac80211: Add debugfs file to show station-hash counts.
From: Johannes Berg @ 2013-07-11 8:51 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1372546738-25827-1-git-send-email-greearb@candelatech.com>
On Sat, 2013-06-29 at 15:58 -0700, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> Helps debug bad hash spreads, like when you have lots of
> station interfaces all connected to the same AP.
I'm willing to take this patch, but
> + res += sprintf(buf + res, "%i: %i\n", q, cnt);
> + if (res >= (STA_HASH_SIZE * 10)) {
> + res = STA_HASH_SIZE * 10;
> + break;
tihs needs to use "maxln" (what does that variable mean anyway? it's
more like "bufsize"?) and snprintf().
johannes
^ permalink raw reply
* Re: [WT PATCH 2/6] mac80211: Make un-found-rate splat a warn-once.
From: Johannes Berg @ 2013-07-11 8:52 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1372546738-25827-2-git-send-email-greearb@candelatech.com>
On Sat, 2013-06-29 at 15:58 -0700, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> After that, print it out with net_ratelimit. We saw a system
> continually hit this warning, for reasons unknown, and it
> seems it bogged the system down enough to make it go OOM.
I've hardly seen this in practice, let's just make it ratelimited
always.
I think maybe sdata_info_ratelimited() or so would be worthwhile.
Might also stick in an unlikely().
johannes
^ permalink raw reply
* Re: [WT PATCH 3/6] wireless: Add memory usage debugging.
From: Johannes Berg @ 2013-07-11 8:53 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1372546738-25827-3-git-send-email-greearb@candelatech.com>
On Sat, 2013-06-29 at 15:58 -0700, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> The bss objects are reference counted, and the ies
> are also tricky to keep track of. Add module option to
> track allocation and freeing of the ies and bss objects,
> and add debugfs files to show the current objects.
I still think this is too intrusive, not in terms of runtime but code
maintenance penalty, so I'm not taking this.
johannes
^ permalink raw reply
* Re: [WT PATCH 4/6] mac80211: Add per-sdata station hash, and sdata hash.
From: Johannes Berg @ 2013-07-11 8:55 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1372546738-25827-4-git-send-email-greearb@candelatech.com>
On Sat, 2013-06-29 at 15:58 -0700, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> Add sdata hash (based on sdata->vif.addr) to local
> structure.
>
> Add sta_vhash (based on sta->sta.addr) to sdata struct.
>
> Make STA_HASH give a better hash spread more often.
>
> Use new hashes where we can. Might be able to completely
> get rid of the local->sta_hash, but didn't want to try that
> quite yet.
>
> This significantly improves performance when using lots
> of station VIFs connected to the same AP. It will likely
> help other cases where the old hash logic failed to create
> a decent spread.
I think this is too much code for a corner case unlikely to happen
outside of your specific scenario, so I'm not taking this either.
I also don't like maintaining two separate hash tables and all that.
I'd reconsider if you actually remove the hash entirely, but that'll be
tricky to walk the station list and will quite possibly make the RX path
there more expensive?
johannes
^ 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