Hello Ralink experts,
I recognized spurious problems with Ralink RT5572 USB-dongles when using this dongles as access point in 5G band.
The problems may appear as short usb disconnect-connect events or failed vendor request messages at different offsets with different error codes or will not appear for days ;)
During error research I noticed that, most likely during the beacon send time (100ms interval), there are very high peak currents in the supply of the USB-dongle.
I tried it with two different dongles, the base current for all three is in the range of ~200mA:
Buffalo WI-U2-300D: Peak ~1A
TP-Link TL-WDN3200: Peak ~1.2mA
We could reproduce this issue on two different machines (x86 and arm), did test with kernel versions 3.10.19, 3.13.0 and 3.14.4 tried hostapd-2.0 and hostapd-2.1 and loaded chip firmware version V0.29, V0.33 and V0.35.
As a comparison I also created an 5G access point setup with a windows7 machine - all with the latest drivers from the manufacturer webpage.
Buffalo WI-U2-300D: Peak 330mA
TP-Link TL-WDN3200: Peak 330mA
Which seems more legit than the values from the linux setups.
The access point functionality itself worked with every tested combination, but there is definitively something wrong.
I also started to grab the usb communication of the windows driver to see if there is an obvious difference in some of the written registers.
But this kind of reverse engineering is not as easy since the windows driver does not write the same registers as the linux drivers but write some others - and of course I have no datasheet/register description.
Until now the only interesting thing I found out is that the linux driver writes 0x00000082 to the TXOP_HLDR_ET (0x1608) register whereas the windows driver uses a value of 0x0000000a. Changing this register during runtime in a linux system reduces the current peaks to 50 percent of their previous value.
But there is still something else wrong.
So, in my despair I try to get help in any form (hints, datasheets/manuals, ideas, experience, ...).
Thanks,
~Matthias
Matthias Fend wrote:
[...]
> I found out that the discovered high current peaks are somehow related to invalidated beacons.
> Usually I can see 1 block with a normal tx-condition current followed by 7 additional blocks with high current peaks.
> For a test I copied the beacon data from HW_BEACON_BASE0 to HW_BEACON_BASE2 and then the first and the third beacon block have normal current values while the others still generate high current peaks
>
> It seems that setting all five words of the TXWI at the beacon base does not complete disable the generation of this beacon.
> If I modify the TXIW_W0 of the disabled beacons to 0x40000000 (set TXWI_W0_PHYMODE as in the really used beacon) then the current consumption does not exceed the usual value. But it seems that there is still a short activity for this beacon which, in my opinion, should not be the case.
>
> So, currently I'm wondering about two things:
> -)How do I completely turn off unused beacons (from the measurements with the windows setup I know that this should be somehow possible)?
> -)Where is the real address of HW_BEACON_BASE6 and HW_BEACON_BASE7? Modifying registers at the address of the appropriate defines (0x5dc0, 0x5bc0) does not change anything at all.
Container 13_UExxF68xx.zip on
http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=T&menu_item=tv_n_video&classification1=tv
seems to contain a complete Ralink vendor AP driver. I would take a look
there.
Andreas
Hello,
Here are some updates concerning my current issues.
> -----Urspr?ngliche Nachricht-----
> Von: [email protected] [mailto:linux-wireless-
> [email protected]] Im Auftrag von Matthias Fend
> Gesendet: Freitag, 23. Mai 2014 14:25
> An: [email protected]
> Betreff: rt2x00: Ralink RT5572 very high peak current consumption
>
> Hello Ralink experts,
>
> I recognized spurious problems with Ralink RT5572 USB-dongles when using
> this dongles as access point in 5G band.
> The problems may appear as short usb disconnect-connect events or failed
> vendor request messages at different offsets with different error codes or
> will not appear for days ;) During error research I noticed that, most likely
> during the beacon send time (100ms interval), there are very high peak
> currents in the supply of the USB-dongle.
>
> I tried it with two different dongles, the base current for all three is in the
> range of ~200mA:
> Buffalo WI-U2-300D: Peak ~1A
> TP-Link TL-WDN3200: Peak ~1.2mA
>
> We could reproduce this issue on two different machines (x86 and arm), did
> test with kernel versions 3.10.19, 3.13.0 and 3.14.4 tried hostapd-2.0 and
> hostapd-2.1 and loaded chip firmware version V0.29, V0.33 and V0.35.
>
> As a comparison I also created an 5G access point setup with a windows7
> machine - all with the latest drivers from the manufacturer webpage.
> Buffalo WI-U2-300D: Peak 330mA
> TP-Link TL-WDN3200: Peak 330mA
> Which seems more legit than the values from the linux setups.
>
> The access point functionality itself worked with every tested combination,
> but there is definitively something wrong.
> I also started to grab the usb communication of the windows driver to see if
> there is an obvious difference in some of the written registers.
> But this kind of reverse engineering is not as easy since the windows driver
> does not write the same registers as the linux drivers but write some others -
> and of course I have no datasheet/register description.
>
> Until now the only interesting thing I found out is that the linux driver writes
> 0x00000082 to the TXOP_HLDR_ET (0x1608) register whereas the windows
> driver uses a value of 0x0000000a. Changing this register during runtime in a
> linux system reduces the current peaks to 50 percent of their previous value.
> But there is still something else wrong.
>
> So, in my despair I try to get help in any form (hints, datasheets/manuals,
> ideas, experience, ...).
I found out that the discovered high current peaks are somehow related to invalidated beacons.
Usually I can see 1 block with a normal tx-condition current followed by 7 additional blocks with high current peaks.
For a test I copied the beacon data from HW_BEACON_BASE0 to HW_BEACON_BASE2 and then the first and the third beacon block have normal current values while the others still generate high current peaks
It seems that setting all five words of the TXWI at the beacon base does not complete disable the generation of this beacon.
If I modify the TXIW_W0 of the disabled beacons to 0x40000000 (set TXWI_W0_PHYMODE as in the really used beacon) then the current consumption does not exceed the usual value. But it seems that there is still a short activity for this beacon which, in my opinion, should not be the case.
So, currently I'm wondering about two things:
-)How do I completely turn off unused beacons (from the measurements with the windows setup I know that this should be somehow possible)?
-)Where is the real address of HW_BEACON_BASE6 and HW_BEACON_BASE7? Modifying registers at the address of the appropriate defines (0x5dc0, 0x5bc0) does not change anything at all.
Thanks,
~Matthias
On Mon, May 26, 2014 at 03:37:36PM +0000, Matthias Fend wrote:
> Hello,
>
> Here are some updates concerning my current issues.
>
> > -----Urspr?ngliche Nachricht-----
> > Von: [email protected] [mailto:linux-wireless-
> > [email protected]] Im Auftrag von Matthias Fend
> > Gesendet: Freitag, 23. Mai 2014 14:25
> > An: [email protected]
> > Betreff: rt2x00: Ralink RT5572 very high peak current consumption
> >
> > Hello Ralink experts,
> >
> > I recognized spurious problems with Ralink RT5572 USB-dongles when using
> > this dongles as access point in 5G band.
> > The problems may appear as short usb disconnect-connect events or failed
> > vendor request messages at different offsets with different error codes or
> > will not appear for days ;) During error research I noticed that, most likely
> > during the beacon send time (100ms interval), there are very high peak
> > currents in the supply of the USB-dongle.
> >
> > I tried it with two different dongles, the base current for all three is in the
> > range of ~200mA:
> > Buffalo WI-U2-300D: Peak ~1A
> > TP-Link TL-WDN3200: Peak ~1.2mA
> >
> > We could reproduce this issue on two different machines (x86 and arm), did
> > test with kernel versions 3.10.19, 3.13.0 and 3.14.4 tried hostapd-2.0 and
> > hostapd-2.1 and loaded chip firmware version V0.29, V0.33 and V0.35.
> >
> > As a comparison I also created an 5G access point setup with a windows7
> > machine - all with the latest drivers from the manufacturer webpage.
> > Buffalo WI-U2-300D: Peak 330mA
> > TP-Link TL-WDN3200: Peak 330mA
> > Which seems more legit than the values from the linux setups.
> >
> > The access point functionality itself worked with every tested combination,
> > but there is definitively something wrong.
> > I also started to grab the usb communication of the windows driver to see if
> > there is an obvious difference in some of the written registers.
> > But this kind of reverse engineering is not as easy since the windows driver
> > does not write the same registers as the linux drivers but write some others -
> > and of course I have no datasheet/register description.
> >
> > Until now the only interesting thing I found out is that the linux driver writes
> > 0x00000082 to the TXOP_HLDR_ET (0x1608) register whereas the windows
> > driver uses a value of 0x0000000a. Changing this register during runtime in a
> > linux system reduces the current peaks to 50 percent of their previous value.
> > But there is still something else wrong.
> >
> > So, in my despair I try to get help in any form (hints, datasheets/manuals,
> > ideas, experience, ...).
>
> I found out that the discovered high current peaks are somehow related to invalidated beacons.
> Usually I can see 1 block with a normal tx-condition current followed by 7 additional blocks with high current peaks.
> For a test I copied the beacon data from HW_BEACON_BASE0 to HW_BEACON_BASE2 and then the first and the third beacon block have normal current values while the others still generate high current peaks
>
> It seems that setting all five words of the TXWI at the beacon base does not complete disable the generation of this beacon.
> If I modify the TXIW_W0 of the disabled beacons to 0x40000000 (set TXWI_W0_PHYMODE as in the really used beacon) then the current consumption does not exceed the usual value. But it seems that there is still a short activity for this beacon which, in my opinion, should not be the case.
>
> So, currently I'm wondering about two things:
> -)How do I completely turn off unused beacons (from the measurements with the windows setup I know that this should be somehow possible)?
Perhaps this could be MULTI_BCN_NUM value in MAC_BSSID_DW1 register.
Try below patch. If it would help we will need to change way we
clear/setup beacons on multiple BSSes, because seems that HW
send MULTI_BCN_NUM beacons from first registers.
Stanislaw
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index c17fcf2..2e799d5 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -1556,7 +1556,7 @@ void rt2800_config_intf(struct rt2x00_dev *rt2x00dev, struct rt2x00_intf *intf,
if (!is_zero_ether_addr((const u8 *)conf->bssid)) {
reg = le32_to_cpu(conf->bssid[1]);
rt2x00_set_field32(®, MAC_BSSID_DW1_BSS_ID_MASK, 3);
- rt2x00_set_field32(®, MAC_BSSID_DW1_BSS_BCN_NUM, 7);
+ rt2x00_set_field32(®, MAC_BSSID_DW1_BSS_BCN_NUM, 0);
conf->bssid[1] = cpu_to_le32(reg);
}
Hi Stanislaw,
> -----Urspr?ngliche Nachricht-----
> Von: Stanislaw Gruszka [mailto:[email protected]]
> Gesendet: Dienstag, 27. Mai 2014 17:12
> An: Matthias Fend
> Cc: [email protected]
> Betreff: Re: rt2x00: Ralink RT5572 very high peak current consumption
>
> On Mon, May 26, 2014 at 03:37:36PM +0000, Matthias Fend wrote:
> > Hello,
> >
> > Here are some updates concerning my current issues.
> >
> > > -----Urspr?ngliche Nachricht-----
> > > Von: [email protected] [mailto:linux-wireless-
> > > [email protected]] Im Auftrag von Matthias Fend
> > > Gesendet: Freitag, 23. Mai 2014 14:25
> > > An: [email protected]
> > > Betreff: rt2x00: Ralink RT5572 very high peak current consumption
> > >
> > > Hello Ralink experts,
> > >
> > > I recognized spurious problems with Ralink RT5572 USB-dongles when
> > > using this dongles as access point in 5G band.
> > > The problems may appear as short usb disconnect-connect events or
> > > failed vendor request messages at different offsets with different
> > > error codes or will not appear for days ;) During error research I
> > > noticed that, most likely during the beacon send time (100ms
> > > interval), there are very high peak currents in the supply of the USB-
> dongle.
> > >
> > > I tried it with two different dongles, the base current for all
> > > three is in the range of ~200mA:
> > > Buffalo WI-U2-300D: Peak ~1A
> > > TP-Link TL-WDN3200: Peak ~1.2mA
> > >
> > > We could reproduce this issue on two different machines (x86 and
> > > arm), did test with kernel versions 3.10.19, 3.13.0 and 3.14.4 tried
> > > hostapd-2.0 and
> > > hostapd-2.1 and loaded chip firmware version V0.29, V0.33 and V0.35.
> > >
> > > As a comparison I also created an 5G access point setup with a
> > > windows7 machine - all with the latest drivers from the manufacturer
> webpage.
> > > Buffalo WI-U2-300D: Peak 330mA
> > > TP-Link TL-WDN3200: Peak 330mA
> > > Which seems more legit than the values from the linux setups.
> > >
> > > The access point functionality itself worked with every tested
> > > combination, but there is definitively something wrong.
> > > I also started to grab the usb communication of the windows driver
> > > to see if there is an obvious difference in some of the written registers.
> > > But this kind of reverse engineering is not as easy since the
> > > windows driver does not write the same registers as the linux
> > > drivers but write some others - and of course I have no
> datasheet/register description.
> > >
> > > Until now the only interesting thing I found out is that the linux
> > > driver writes
> > > 0x00000082 to the TXOP_HLDR_ET (0x1608) register whereas the
> windows
> > > driver uses a value of 0x0000000a. Changing this register during
> > > runtime in a linux system reduces the current peaks to 50 percent of their
> previous value.
> > > But there is still something else wrong.
> > >
> > > So, in my despair I try to get help in any form (hints,
> > > datasheets/manuals, ideas, experience, ...).
> >
> > I found out that the discovered high current peaks are somehow related to
> invalidated beacons.
> > Usually I can see 1 block with a normal tx-condition current followed by 7
> additional blocks with high current peaks.
> > For a test I copied the beacon data from HW_BEACON_BASE0 to
> > HW_BEACON_BASE2 and then the first and the third beacon block have
> > normal current values while the others still generate high current
> > peaks
> >
> > It seems that setting all five words of the TXWI at the beacon base does not
> complete disable the generation of this beacon.
> > If I modify the TXIW_W0 of the disabled beacons to 0x40000000 (set
> TXWI_W0_PHYMODE as in the really used beacon) then the current
> consumption does not exceed the usual value. But it seems that there is still
> a short activity for this beacon which, in my opinion, should not be the case.
> >
> > So, currently I'm wondering about two things:
> > -)How do I completely turn off unused beacons (from the measurements
> with the windows setup I know that this should be somehow possible)?
>
> Perhaps this could be MULTI_BCN_NUM value in MAC_BSSID_DW1 register.
> Try below patch. If it would help we will need to change way we clear/setup
> beacons on multiple BSSes, because seems that HW send MULTI_BCN_NUM
> beacons from first registers.
You just made my day! This was exactly the setting I was looking for.
And yes, it seems that clearing the TXWI at the beacon location is not enough to completely disable beacon sending.
Together with the already mentioned change in TXOP_HLDR_ET (use 0x0A instead of 0x82) it's looking identical to the windows setup.
Thanks a lot,
~Matthias
>
> Stanislaw
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c
> b/drivers/net/wireless/rt2x00/rt2800lib.c
> index c17fcf2..2e799d5 100644
> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> @@ -1556,7 +1556,7 @@ void rt2800_config_intf(struct rt2x00_dev
> *rt2x00dev, struct rt2x00_intf *intf,
> if (!is_zero_ether_addr((const u8 *)conf->bssid)) {
> reg = le32_to_cpu(conf->bssid[1]);
> rt2x00_set_field32(®,
> MAC_BSSID_DW1_BSS_ID_MASK, 3);
> - rt2x00_set_field32(®,
> MAC_BSSID_DW1_BSS_BCN_NUM, 7);
> + rt2x00_set_field32(®,
> MAC_BSSID_DW1_BSS_BCN_NUM, 0);
> conf->bssid[1] = cpu_to_le32(reg);
> }
>
Hi
On Tue, May 27, 2014 at 03:44:01PM +0000, Matthias Fend wrote:
> You just made my day! This was exactly the setting I was looking for.
> And yes, it seems that clearing the TXWI at the beacon location is not enough to completely disable beacon sending.
> Together with the already mentioned change in TXOP_HLDR_ET (use 0x0A instead of 0x82) it's looking identical to the windows setup.
I don't know why TXOP_HLDR_ET registr does matter, it seems to be
setting that is used for HCCA (Hybrid coordintanion function), which we
do not support (we do not set TXOP_HLDR_ADDR). But perhaps this setting
is also used on EDCA. Did you also tested this setting on STA mode ?
Regarding MAC_BSSID_DW1_BSS_BCN_NUM, I'll post RFC patches, please
test them (whould be good to test them on multi-vif AP setup, to
see if many beacons works).
Stanislaw