All of lore.kernel.org
 help / color / mirror / Atom feed
* [ath9k-devel] [USB] AR7010+AR9280 missing tx_bitrate at 5GHz
@ 2015-10-20 15:22 ferran
  2015-10-21 12:52 ` Oleksij Rempel
  0 siblings, 1 reply; 3+ messages in thread
From: ferran @ 2015-10-20 15:22 UTC (permalink / raw)
  To: ath9k-devel

Hello everyone,

I have been working around a bad behaviour with Linux Penguin's
TPE-NUSBDB, that uses AR7010 and AR9280 chips.  I have found that
cfg80211 reports weird tx bitrates when the device is  operating at mesh
mode at 5GHz band. From inside mac80211, the reported rate is zero,
which makes it lethal to calculate a frame duration due to div by zero.
From iw part, the reported values is sometimes "518", sometimes  just
invalid characters. I have checked that it only happens at 5GHz.

###
$ iw --version
iw version 4.1

$ uname -a
Linux raspberrypi 3.10-3-rpi #1 Debian 3.10.11-1+rpi7 (2014-05-05)
armv6l  GNU/Linux

$ iw dev mesh0 station dump
Station e0:ca:94:5f:xx:xx (on mesh0)
[...]
tx bitrate:    518.0 MBit/s
rx bitrate:    6.0 MBit/s
###

By the moment I haven't been able to test it in a newer kernel. For mesh
mode to work, I need to disable "no-IR" flag configuring a new db.txt
for CRDA.

I have read "usb related issues" on ath9k_htc firmware github page
(https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-related-issues)
but I can't relate directly any of them to my problem. Is this already
covered?

Thank you in advance for your time and work!
Ferran

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [ath9k-devel] [USB] AR7010+AR9280 missing tx_bitrate at 5GHz
  2015-10-20 15:22 [ath9k-devel] [USB] AR7010+AR9280 missing tx_bitrate at 5GHz ferran
@ 2015-10-21 12:52 ` Oleksij Rempel
  2015-10-23 15:42   ` ferran
  0 siblings, 1 reply; 3+ messages in thread
From: Oleksij Rempel @ 2015-10-21 12:52 UTC (permalink / raw)
  To: ath9k-devel

Hi,

suddenly i can't provide any help here until you get latest wifi code +
latest firmware for this adapter.

Am 20.10.2015 um 17:22 schrieb ferran:
> Hello everyone,
> 
> I have been working around a bad behaviour with Linux Penguin's
> TPE-NUSBDB, that uses AR7010 and AR9280 chips.  I have found that
> cfg80211 reports weird tx bitrates when the device is  operating at mesh
> mode at 5GHz band. From inside mac80211, the reported rate is zero,
> which makes it lethal to calculate a frame duration due to div by zero.
> From iw part, the reported values is sometimes "518", sometimes  just
> invalid characters. I have checked that it only happens at 5GHz.
> 
> ###
> $ iw --version
> iw version 4.1
> 
> $ uname -a
> Linux raspberrypi 3.10-3-rpi #1 Debian 3.10.11-1+rpi7 (2014-05-05)
> armv6l  GNU/Linux
> 
> $ iw dev mesh0 station dump
> Station e0:ca:94:5f:xx:xx (on mesh0)
> [...]
> tx bitrate:    518.0 MBit/s
> rx bitrate:    6.0 MBit/s
> ###
> 
> By the moment I haven't been able to test it in a newer kernel. For mesh
> mode to work, I need to disable "no-IR" flag configuring a new db.txt
> for CRDA.
> 
> I have read "usb related issues" on ath9k_htc firmware github page
> (https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-related-issues)
> but I can't relate directly any of them to my problem. Is this already
> covered?
> 
> Thank you in advance for your time and work!
> Ferran
> 
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20151021/181bbf15/attachment.pgp 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [ath9k-devel] [USB] AR7010+AR9280 missing tx_bitrate at 5GHz
  2015-10-21 12:52 ` Oleksij Rempel
@ 2015-10-23 15:42   ` ferran
  0 siblings, 0 replies; 3+ messages in thread
From: ferran @ 2015-10-23 15:42 UTC (permalink / raw)
  To: ath9k-devel

Hi,

Suddenly I've been able to reproduce the error on the newer LTS kernel,
3.18 and latest available on the Raspbian repos. I think it's recent
enough to at least have a look on this issue. Furthermore, it's still
supposed to be supported.

    $ uname -a
    Linux raspberrypi 3.18.0-trunk-rpi #1 PREEMPT Debian
3.18.5-1~exp1+rpi15 (2015-03-07) armv6l GNU/Linux

    $ ./iw --version
    iw version 4.1

    $ modinfo ath9k_htc
    filename:      
/lib/modules/3.18.0-trunk-rpi/updates/drivers/net/wireless/ath/ath9k/ath9k_htc.ko
    firmware:       htc_9271.fw
    firmware:       htc_7010.fw
    version:        backported from Linux (v3.18.1-0-g39ca484) using
backports v3.18.1-1-0-g5e9ec4c
    description:    Atheros driver 802.11n HTC based wireless devices
    license:        Dual BSD/GPL
    author:         Atheros Communications
    srcversion:     51527D2EEFA15CFD1255700
    ...
    depends:        ath9k_hw,ath9k_common,compat,mac80211,ath,cfg80211
    vermagic:       3.18.0-trunk-rpi preempt mod_unload modversions ARMv6
    ...

I had to remove the NO_IR flags from atheros regd.c to be able to set it
to mesh mode, and set a proper regulation domain from the CRDA side.
 
Some illustrative output:

    $ ./iw dev mesh0 station dump | grep Sta -A 11
    Station e0:ca:94:5f:xx:xx (on mesh0)
        inactive time:    492 ms
        rx bytes:    3519
        rx packets:    113
        tx bytes:    154
        tx packets:    3
        tx retries:    0
        tx failed:    0
        signal:      -76 [-80, -79] dBm
        signal avg:    -75 [-78, -78] dBm
        Toffset:    15378832514 us
        tx bitrate:    5906.0 MBit/s
    --
    Station e0:ca:94:5f:xx:xx (on mesh0)
        inactive time:    184 ms
        rx bytes:    3610
        rx packets:    180
        tx bytes:    154
        tx packets:    3
        tx retries:    0
        tx failed:    0
        signal:      -70 [-72, -74] dBm
        signal avg:    -69 [-71, -74] dBm
        tx bitrate:    5906.0 MBit/s
        rx bitrate:    54.0 MBit/s
    --
    Station e0:ca:94:5f:xx:xx (on mesh0)
        inactive time:    2364 ms
        rx bytes:    2922
        rx packets:    106
        tx bytes:    154
        tx packets:    3
        tx retries:    0
        tx failed:    0
        signal:      -83 [-85, -86] dBm
        signal avg:    -82 [-85, -85] dBm
        tx bitrate:    5906.0 MBit/s
        rx bitrate:    6.0 MBit/s

I also advanced on where this number comes from. It's accessing memory
out of the supported bitrates. Actually, the index that points to the
current tx bitrate points out of it.
Sintonizing the dongle to channel 48, I found these supported values,
that agrees with what "iw list" prints. The following correspond to
values stored to the wiphy's "struct ieee80211_supported_band *sband" .
rates:
0    60
1    90
2    120
3    180
4    240
5    360
6    480
7    540

freqs:
0    5180
1    5200
2    5220
3    5240
4    5260
5    5280
6    5300
7    5320

On the other side, another atheros USB device that uses obviously the
same driver, tuned into a channel of the 2.4 GHz band, reports the
expected supported bitrates, 12 in total. Namely:
0      10
1      20
2      55
3     110
4      60
5      90
6     120
7     180
8     240
9     360
10    480
11    540

Thus, this is anything new. The issue is that I found the index to be
usually 11 when in 5GHz, which tells me clearly that the index is
relative to a 12-element supported range array (2.4 GHz) rather than to
the 8 one (5 GHz). By the moment I have tested it only on mesh mode, but
I don't see any reason why it couldn't affect other operation modes.

Does this issue sound familiar to anyone around here? This looks
relevant to me and I can dive deeper into this, but please, shed some
light on this if you can.

Best regards,
Ferran

On 21/10/15 14:52, Oleksij Rempel wrote:
> Hi,
>
> suddenly i can't provide any help here until you get latest wifi code +
> latest firmware for this adapter.
>
> Am 20.10.2015 um 17:22 schrieb ferran:
>> Hello everyone,
>>
>> I have been working around a bad behaviour with Linux Penguin's
>> TPE-NUSBDB, that uses AR7010 and AR9280 chips.  I have found that
>> cfg80211 reports weird tx bitrates when the device is  operating at mesh
>> mode at 5GHz band. From inside mac80211, the reported rate is zero,
>> which makes it lethal to calculate a frame duration due to div by zero.
>> From iw part, the reported values is sometimes "518", sometimes  just
>> invalid characters. I have checked that it only happens at 5GHz.
>>
>> ###
>> $ iw --version
>> iw version 4.1
>>
>> $ uname -a
>> Linux raspberrypi 3.10-3-rpi #1 Debian 3.10.11-1+rpi7 (2014-05-05)
>> armv6l  GNU/Linux
>>
>> $ iw dev mesh0 station dump
>> Station e0:ca:94:5f:xx:xx (on mesh0)
>> [...]
>> tx bitrate:    518.0 MBit/s
>> rx bitrate:    6.0 MBit/s
>> ###
>>
>> By the moment I haven't been able to test it in a newer kernel. For mesh
>> mode to work, I need to disable "no-IR" flag configuring a new db.txt
>> for CRDA.
>>
>> I have read "usb related issues" on ath9k_htc firmware github page
>> (https://github.com/qca/open-ath9k-htc-firmware/wiki/usb-related-issues)
>> but I can't relate directly any of them to my problem. Is this already
>> covered?
>>
>> Thank you in advance for your time and work!
>> Ferran
>>
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20151023/4643415c/attachment.htm 

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-10-23 15:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-20 15:22 [ath9k-devel] [USB] AR7010+AR9280 missing tx_bitrate at 5GHz ferran
2015-10-21 12:52 ` Oleksij Rempel
2015-10-23 15:42   ` ferran

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.