USB rt2x00 driver regression

USB rt2x00 driver regression

[Sergei Antonov]

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

Hello!
I use a USB Wi-Fi adapter identified as follows.

usb 2-4: new high-speed USB device number 5 using ehci-pci
usb 2-4: New USB device found, idVendor=148f, idProduct=5370
usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-4: Product: 802.11 n WLAN
usb 2-4: Manufacturer: Ralink
usb 2-4: SerialNumber: 1.0
usb 2-4: reset high-speed USB device number 5 using ehci-pci
ieee80211 phy3: rt2x00_set_rt: Info - RT chipset 5390, rev 0502 detected
ieee80211 phy3: rt2x00_set_rf: Info - RF chipset 5370 detected

It worked well with older kernels and does not with newer kernels.
Specifically it fails to find any AP when scanning.
The first bad commit is:

commit 76773f301f2210dcc20c466aebda7118062673eb
Author: Gabor Juhos <juhosg@openwrt.org>
Date:   Sat Aug 17 14:09:30 2013 +0200

    rt2x00: rt2800lib: use a MCU command for frequency adjustment on USB devices

    According to the Ralink driver, there is an MCU
    command which can be used to send the frequency
    offset value directly to the USB device without
    going through the RFCSR writing sequence.

    Based on the DPO_RT5572_LinuxSTA_2.6.0.1_20120629
    driver.

    Reference:
      RTMPAdjustFrequencyOffset function in common/rt_rf.c

    Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

After I removed this special USB handling (see the patch) the adapter
works again.

[-- Attachment #2: rt2800.diff --]
[-- Type: text/plain, Size: 1106 bytes --]

diff --git a/drivers/net/wireless/rt2x00/rt2800.h b/drivers/net/wireless/rt2x00/rt2800.h
index aab6b5e..835e91d 100644
--- a/drivers/net/wireless/rt2x00/rt2800.h
+++ b/drivers/net/wireless/rt2x00/rt2800.h
@@ -2798,7 +2798,6 @@ enum rt2800_eeprom_word {
 #define MCU_RADAR			0x60
 #define MCU_BOOT_SIGNAL			0x72
 #define MCU_ANT_SELECT			0X73
-#define MCU_FREQ_OFFSET			0x74
 #define MCU_BBP_SIGNAL			0x80
 #define MCU_POWER_SAVE			0x83
 #define MCU_BAND_SELECT			0x91
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 776aff3..1f80cf3 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -1902,12 +1902,6 @@ static void rt2800_adjust_freq_offset(struct rt2x00_dev *rt2x00dev)
 	if (rfcsr == prev_rfcsr)
 		return;
 
-	if (rt2x00_is_usb(rt2x00dev)) {
-		rt2800_mcu_request(rt2x00dev, MCU_FREQ_OFFSET, 0xff,
-				   freq_offset, prev_rfcsr);
-		return;
-	}
-
 	prev_freq_offset = rt2x00_get_field8(prev_rfcsr, RFCSR17_CODE);
 	while (prev_freq_offset != freq_offset) {
 		if (prev_freq_offset < freq_offset)

Re: USB rt2x00 driver regression

[Stanislaw Gruszka]

On Tue, Jan 14, 2014 at 07:28:39PM +0100, Sergei Antonov wrote:
> Hello!
> I use a USB Wi-Fi adapter identified as follows.
> 
> usb 2-4: new high-speed USB device number 5 using ehci-pci
> usb 2-4: New USB device found, idVendor=148f, idProduct=5370
> usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 2-4: Product: 802.11 n WLAN
> usb 2-4: Manufacturer: Ralink
> usb 2-4: SerialNumber: 1.0
> usb 2-4: reset high-speed USB device number 5 using ehci-pci
> ieee80211 phy3: rt2x00_set_rt: Info - RT chipset 5390, rev 0502 detected
> ieee80211 phy3: rt2x00_set_rf: Info - RF chipset 5370 detected
> 
> It worked well with older kernels and does not with newer kernels.
> Specifically it fails to find any AP when scanning.
> The first bad commit is:
> 
> commit 76773f301f2210dcc20c466aebda7118062673eb
> Author: Gabor Juhos <juhosg@openwrt.org>
> Date:   Sat Aug 17 14:09:30 2013 +0200
> 
>     rt2x00: rt2800lib: use a MCU command for frequency adjustment on USB devices
> 
>     According to the Ralink driver, there is an MCU
>     command which can be used to send the frequency
>     offset value directly to the USB device without
>     going through the RFCSR writing sequence.
> 
>     Based on the DPO_RT5572_LinuxSTA_2.6.0.1_20120629
>     driver.
> 
>     Reference:
>       RTMPAdjustFrequencyOffset function in common/rt_rf.c
> 
>     Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
>     Signed-off-by: John W. Linville <linville@tuxdriver.com>
> 
> After I removed this special USB handling (see the patch) the adapter
> works again.

Thanks for bisecting! Could you check if following patch fixes the
issue?

Thanks
Stanislaw

diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 776aff3..5c06836 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -1902,13 +1902,13 @@ static void rt2800_adjust_freq_offset(struct rt2x00_dev *rt2x00dev)
 	if (rfcsr == prev_rfcsr)
 		return;
 
+	prev_freq_offset = rt2x00_get_field8(prev_rfcsr, RFCSR17_CODE);
 	if (rt2x00_is_usb(rt2x00dev)) {
 		rt2800_mcu_request(rt2x00dev, MCU_FREQ_OFFSET, 0xff,
-				   freq_offset, prev_rfcsr);
+				   freq_offset, prev_freq_offset);
 		return;
 	}
 
-	prev_freq_offset = rt2x00_get_field8(prev_rfcsr, RFCSR17_CODE);
 	while (prev_freq_offset != freq_offset) {
 		if (prev_freq_offset < freq_offset)
 			prev_freq_offset++;

Re: USB rt2x00 driver regression

[Sergei Antonov]

> Am 17.01.2014 um 11:06 schrieb Stanislaw Gruszka <sgruszka@redhat.com>:
> 
>> On Tue, Jan 14, 2014 at 07:28:39PM +0100, Sergei Antonov wrote:
>> Hello!
>> I use a USB Wi-Fi adapter identified as follows.
>> 
>> usb 2-4: new high-speed USB device number 5 using ehci-pci
>> usb 2-4: New USB device found, idVendor=148f, idProduct=5370
>> usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
>> usb 2-4: Product: 802.11 n WLAN
>> usb 2-4: Manufacturer: Ralink
>> usb 2-4: SerialNumber: 1.0
>> usb 2-4: reset high-speed USB device number 5 using ehci-pci
>> ieee80211 phy3: rt2x00_set_rt: Info - RT chipset 5390, rev 0502 detected
>> ieee80211 phy3: rt2x00_set_rf: Info - RF chipset 5370 detected
>> 
>> It worked well with older kernels and does not with newer kernels.
>> Specifically it fails to find any AP when scanning.
>> The first bad commit is:
>> 
>> commit 76773f301f2210dcc20c466aebda7118062673eb
>> Author: Gabor Juhos <juhosg@openwrt.org>
>> Date:   Sat Aug 17 14:09:30 2013 +0200
>> 
>>    rt2x00: rt2800lib: use a MCU command for frequency adjustment on USB devices
>> 
>>    According to the Ralink driver, there is an MCU
>>    command which can be used to send the frequency
>>    offset value directly to the USB device without
>>    going through the RFCSR writing sequence.
>> 
>>    Based on the DPO_RT5572_LinuxSTA_2.6.0.1_20120629
>>    driver.
>> 
>>    Reference:
>>      RTMPAdjustFrequencyOffset function in common/rt_rf.c
>> 
>>    Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
>>    Signed-off-by: John W. Linville <linville@tuxdriver.com>
>> 
>> After I removed this special USB handling (see the patch) the adapter
>> works again.
> 
> Thanks for bisecting! Could you check if following patch fixes the
> issue?

It does not fix the issue. The same broken behavior remains.

Re: USB rt2x00 driver regression

[Igor Gnatenko]

On Sun, 2014-01-19 at 11:57 +0100, Sergei Antonov wrote:
> > Am 17.01.2014 um 11:06 schrieb Stanislaw Gruszka <sgruszka@redhat.com>:
> > 
> >> On Tue, Jan 14, 2014 at 07:28:39PM +0100, Sergei Antonov wrote:
> >> Hello!
> >> I use a USB Wi-Fi adapter identified as follows.
> >> 
> >> usb 2-4: new high-speed USB device number 5 using ehci-pci
> >> usb 2-4: New USB device found, idVendor=148f, idProduct=5370
> >> usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> >> usb 2-4: Product: 802.11 n WLAN
> >> usb 2-4: Manufacturer: Ralink
> >> usb 2-4: SerialNumber: 1.0
> >> usb 2-4: reset high-speed USB device number 5 using ehci-pci
> >> ieee80211 phy3: rt2x00_set_rt: Info - RT chipset 5390, rev 0502 detected
> >> ieee80211 phy3: rt2x00_set_rf: Info - RF chipset 5370 detected
> >> 
> >> It worked well with older kernels and does not with newer kernels.
> >> Specifically it fails to find any AP when scanning.
> >> The first bad commit is:
> >> 
> >> commit 76773f301f2210dcc20c466aebda7118062673eb
> >> Author: Gabor Juhos <juhosg@openwrt.org>
> >> Date:   Sat Aug 17 14:09:30 2013 +0200
> >> 
> >>    rt2x00: rt2800lib: use a MCU command for frequency adjustment on USB devices
> >> 
> >>    According to the Ralink driver, there is an MCU
> >>    command which can be used to send the frequency
> >>    offset value directly to the USB device without
> >>    going through the RFCSR writing sequence.
> >> 
> >>    Based on the DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> >>    driver.
> >> 
> >>    Reference:
> >>      RTMPAdjustFrequencyOffset function in common/rt_rf.c
> >> 
> >>    Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
> >>    Signed-off-by: John W. Linville <linville@tuxdriver.com>
> >> 
> >> After I removed this special USB handling (see the patch) the adapter
> >> works again.
> > 
> > Thanks for bisecting! Could you check if following patch fixes the
> > issue?
> 
> It does not fix the issue. The same broken behavior remains.
I couldn't understand one string in original RTMPAdjustFrequencyOffset. Could you try follow patch ?

diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 776aff3..dbb33a5 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -1893,7 +1893,7 @@ static void rt2800_adjust_freq_offset(struct rt2x00_dev *rt2x00dev)
        u8 rfcsr, prev_rfcsr;
 
        freq_offset = rt2x00_get_field8(rt2x00dev->freq_offset, RFCSR17_CODE);
-       freq_offset = min_t(u8, freq_offset, FREQ_OFFSET_BOUND);
+       freq_offset = min_t(u8, (freq_offset & 0x7f), FREQ_OFFSET_BOUND);
 
        rt2800_rfcsr_read(rt2x00dev, 17, &rfcsr);
        prev_rfcsr = rfcsr;

-- 
-Igor Gnatenko

Re: USB rt2x00 driver regression

[Sergei Antonov]

> Am 19.01.2014 um 13:19 schrieb Igor Gnatenko <i.gnatenko.brain@gmail.com>:
> 
> On Sun, 2014-01-19 at 11:57 +0100, Sergei Antonov wrote:
>>> Am 17.01.2014 um 11:06 schrieb Stanislaw Gruszka <sgruszka@redhat.com>:
>>> 
>>>> On Tue, Jan 14, 2014 at 07:28:39PM +0100, Sergei Antonov wrote:
>>>> Hello!
>>>> I use a USB Wi-Fi adapter identified as follows.
>>>> 
>>>> usb 2-4: new high-speed USB device number 5 using ehci-pci
>>>> usb 2-4: New USB device found, idVendor=148f, idProduct=5370
>>>> usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
>>>> usb 2-4: Product: 802.11 n WLAN
>>>> usb 2-4: Manufacturer: Ralink
>>>> usb 2-4: SerialNumber: 1.0
>>>> usb 2-4: reset high-speed USB device number 5 using ehci-pci
>>>> ieee80211 phy3: rt2x00_set_rt: Info - RT chipset 5390, rev 0502 detected
>>>> ieee80211 phy3: rt2x00_set_rf: Info - RF chipset 5370 detected
>>>> 
>>>> It worked well with older kernels and does not with newer kernels.
>>>> Specifically it fails to find any AP when scanning.
>>>> The first bad commit is:
>>>> 
>>>> commit 76773f301f2210dcc20c466aebda7118062673eb
>>>> Author: Gabor Juhos <juhosg@openwrt.org>
>>>> Date:   Sat Aug 17 14:09:30 2013 +0200
>>>> 
>>>>   rt2x00: rt2800lib: use a MCU command for frequency adjustment on USB devices
>>>> 
>>>>   According to the Ralink driver, there is an MCU
>>>>   command which can be used to send the frequency
>>>>   offset value directly to the USB device without
>>>>   going through the RFCSR writing sequence.
>>>> 
>>>>   Based on the DPO_RT5572_LinuxSTA_2.6.0.1_20120629
>>>>   driver.
>>>> 
>>>>   Reference:
>>>>     RTMPAdjustFrequencyOffset function in common/rt_rf.c
>>>> 
>>>>   Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
>>>>   Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>>> 
>>>> After I removed this special USB handling (see the patch) the adapter
>>>> works again.
>>> 
>>> Thanks for bisecting! Could you check if following patch fixes the
>>> issue?
>> 
>> It does not fix the issue. The same broken behavior remains.
> I couldn't understand one string in original RTMPAdjustFrequencyOffset. Could you try follow patch ?
Tried your patch with and without Stanislaw's patch. No success.

Re: USB rt2x00 driver regression

[Gabor Juhos]

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

Hi Sergei,

<...>

>>>>> It worked well with older kernels and does not with newer kernels.
>>>>> Specifically it fails to find any AP when scanning.
>>>>> The first bad commit is:
>>>>>
>>>>> commit 76773f301f2210dcc20c466aebda7118062673eb
>>>>> Author: Gabor Juhos <juhosg@openwrt.org>
>>>>> Date:   Sat Aug 17 14:09:30 2013 +0200
>>>>>
>>>>>   rt2x00: rt2800lib: use a MCU command for frequency adjustment on USB devices
>>>>>
>>>>>   According to the Ralink driver, there is an MCU
>>>>>   command which can be used to send the frequency
>>>>>   offset value directly to the USB device without
>>>>>   going through the RFCSR writing sequence.
>>>>>
>>>>>   Based on the DPO_RT5572_LinuxSTA_2.6.0.1_20120629
>>>>>   driver.
>>>>>
>>>>>   Reference:
>>>>>     RTMPAdjustFrequencyOffset function in common/rt_rf.c
>>>>>
>>>>>   Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
>>>>>   Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>>>>
>>>>> After I removed this special USB handling (see the patch) the adapter
>>>>> works again.
>>>>
>>>> Thanks for bisecting! Could you check if following patch fixes the
>>>> issue?
>>>
>>> It does not fix the issue. The same broken behavior remains.
>> I couldn't understand one string in original RTMPAdjustFrequencyOffset. Could you try follow patch ?
> Tried your patch with and without Stanislaw's patch. No success.

I guess that this is a timing issue. Maybe the RT5390 device does not finish the
MCU command before the scan runs.

The Ralink reference driver calls the frequency adjustment code from the
NICInitRT5390RFRegisters function but the equivalent call is missing from the
rt2x00 driver. Additionaly, the Ralink driver uses 1 ms delay after calling the
frequency adjustment code which is also missing from rt2x00.

The attached patch set adds the missing code to rt2x00. Please test whether it
fixes the problem or not.

Thanks,
Gabor



[-- Attachment #2: 0001-rt2x00-rt2800lib-add-a-delay-after-frequency-adjustm.patch --]
[-- Type: text/x-patch, Size: 1005 bytes --]

>From ff8f124dcc6b256c63a006c9fde9e02785fa20b6 Mon Sep 17 00:00:00 2001
From: Gabor Juhos <juhosg@openwrt.org>
Date: Sun, 19 Jan 2014 12:54:49 +0100
Subject: [PATCH 1/2] rt2x00: rt2800lib: add a delay after frequency
 adjustment MCU command

The delay helps to ensure that the MCU command is processed
by the USB device before we are returning from the frequency
adjustment code.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
 drivers/net/wireless/rt2x00/rt2800lib.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index d152b16..c6bc231 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -1980,6 +1980,7 @@ static void rt2800_adjust_freq_offset(struct rt2x00_dev *rt2x00dev)
 	if (rt2x00_is_usb(rt2x00dev)) {
 		rt2800_mcu_request(rt2x00dev, MCU_FREQ_OFFSET, 0xff,
 				   freq_offset, prev_rfcsr);
+		usleep_range(1000, 1500);
 		return;
 	}
 
-- 
1.7.10


[-- Attachment #3: 0002-rt2x00-rt2800lib-adjust-frequency-offset-during-rfcs.patch --]
[-- Type: text/x-patch, Size: 1224 bytes --]

>From 3f4a100688acbe0c331fc490827bb21c2dc614ca Mon Sep 17 00:00:00 2001
From: Gabor Juhos <juhosg@openwrt.org>
Date: Fri, 17 Jan 2014 22:08:51 +0100
Subject: [PATCH 2/2] rt2x00: rt2800lib: adjust frequency offset during rfcsr
 init on RT5390/5392

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
 drivers/net/wireless/rt2x00/rt2800lib.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index c6bc231..ca92403 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -6550,6 +6550,8 @@ static void rt2800_init_rfcsr_5390(struct rt2x00_dev *rt2x00dev)
 {
 	rt2800_rf_init_calibration(rt2x00dev, 2);
 
+	rt2800_adjust_freq_offset(rt2x00dev);
+
 	rt2800_rfcsr_write(rt2x00dev, 1, 0x0f);
 	rt2800_rfcsr_write(rt2x00dev, 2, 0x80);
 	rt2800_rfcsr_write(rt2x00dev, 3, 0x88);
@@ -6648,6 +6650,8 @@ static void rt2800_init_rfcsr_5392(struct rt2x00_dev *rt2x00dev)
 {
 	rt2800_rf_init_calibration(rt2x00dev, 2);
 
+	rt2800_adjust_freq_offset(rt2x00dev);
+
 	rt2800_rfcsr_write(rt2x00dev, 1, 0x17);
 	rt2800_rfcsr_write(rt2x00dev, 3, 0x88);
 	rt2800_rfcsr_write(rt2x00dev, 5, 0x10);
-- 
1.7.10

Re: USB rt2x00 driver regression

[Sergei Antonov]

On 19 January 2014 19:20, Gabor Juhos <juhosg@openwrt.org> wrote:
> Hi Sergei,
>
> <...>
>
>>>>>> It worked well with older kernels and does not with newer kernels.
>>>>>> Specifically it fails to find any AP when scanning.
>>>>>> The first bad commit is:
>>>>>>
>>>>>> commit 76773f301f2210dcc20c466aebda7118062673eb
>>>>>> Author: Gabor Juhos <juhosg@openwrt.org>
>>>>>> Date:   Sat Aug 17 14:09:30 2013 +0200
>>>>>>
>>>>>>   rt2x00: rt2800lib: use a MCU command for frequency adjustment on USB devices
>>>>>>
>>>>>>   According to the Ralink driver, there is an MCU
>>>>>>   command which can be used to send the frequency
>>>>>>   offset value directly to the USB device without
>>>>>>   going through the RFCSR writing sequence.
>>>>>>
>>>>>>   Based on the DPO_RT5572_LinuxSTA_2.6.0.1_20120629
>>>>>>   driver.
>>>>>>
>>>>>>   Reference:
>>>>>>     RTMPAdjustFrequencyOffset function in common/rt_rf.c
>>>>>>
>>>>>>   Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
>>>>>>   Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>>>>>
>>>>>> After I removed this special USB handling (see the patch) the adapter
>>>>>> works again.
>>>>>
>>>>> Thanks for bisecting! Could you check if following patch fixes the
>>>>> issue?
>>>>
>>>> It does not fix the issue. The same broken behavior remains.
>>> I couldn't understand one string in original RTMPAdjustFrequencyOffset. Could you try follow patch ?
>> Tried your patch with and without Stanislaw's patch. No success.
>
> I guess that this is a timing issue. Maybe the RT5390 device does not finish the
> MCU command before the scan runs.
>
> The Ralink reference driver calls the frequency adjustment code from the
> NICInitRT5390RFRegisters function but the equivalent call is missing from the
> rt2x00 driver. Additionaly, the Ralink driver uses 1 ms delay after calling the
> frequency adjustment code which is also missing from rt2x00.
>
> The attached patch set adds the missing code to rt2x00. Please test whether it
> fixes the problem or not.

It does not work.

The minimal change that fixes the problem is removing 'return;' after
rt2800_mcu_request() allowing the standard freq. adjustment code to
execute.

Re: USB rt2x00 driver regression

[Stanislaw Gruszka]

On Mon, Jan 20, 2014 at 12:20:05PM +0100, Sergei Antonov wrote:
> On 19 January 2014 19:20, Gabor Juhos <juhosg@openwrt.org> wrote:
> > The attached patch set adds the missing code to rt2x00. Please test whether it
> > fixes the problem or not.
> 
> It does not work.
> 
> The minimal change that fixes the problem is removing 'return;' after
> rt2800_mcu_request() allowing the standard freq. adjustment code to
> execute.

Perhaps this MCU request is not supported by old firmware from
linux-firmware repository.

Please download binary file accessible from this link
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2013-January/005610.html
and replace rt2870.bin file in /lib/firmware directory.

Does it help ?

Stanislaw

Re: USB rt2x00 driver regression

[Sergei Antonov]

On 20 January 2014 19:50, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Mon, Jan 20, 2014 at 12:20:05PM +0100, Sergei Antonov wrote:
>> On 19 January 2014 19:20, Gabor Juhos <juhosg@openwrt.org> wrote:
>> > The attached patch set adds the missing code to rt2x00. Please test whether it
>> > fixes the problem or not.
>>
>> It does not work.
>>
>> The minimal change that fixes the problem is removing 'return;' after
>> rt2800_mcu_request() allowing the standard freq. adjustment code to
>> execute.
>
> Perhaps this MCU request is not supported by old firmware from
> linux-firmware repository.
>
> Please download binary file accessible from this link
> http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2013-January/005610.html
> and replace rt2870.bin file in /lib/firmware directory.
>
> Does it help ?

Great hint. Thanks!
Turned out I had firmware version 0.22
With firmware 0.29 or 0.33 the adapter works with unmodified kernel 3.13.

The only problem I have now is that when connected to a particular
access point I get a lot of warnings like this:
[  327.309858] ieee80211 phy0: rt2800usb_entry_txstatus_timeout:
Warning - TX status timeout for entry 13 in queue 2
and this:
[  327.332847] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX
status for an empty queue 2, dropping
I didn't have this problem before (with older kernels and old firmware).

Re: USB rt2x00 driver regression

[Stanislaw Gruszka]

On Wed, Jan 22, 2014 at 12:27:44PM +0100, Sergei Antonov wrote:
> On 20 January 2014 19:50, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> > On Mon, Jan 20, 2014 at 12:20:05PM +0100, Sergei Antonov wrote:
> >> On 19 January 2014 19:20, Gabor Juhos <juhosg@openwrt.org> wrote:
> >> > The attached patch set adds the missing code to rt2x00. Please test whether it
> >> > fixes the problem or not.
> >>
> >> It does not work.
> >>
> >> The minimal change that fixes the problem is removing 'return;' after
> >> rt2800_mcu_request() allowing the standard freq. adjustment code to
> >> execute.
> >
> > Perhaps this MCU request is not supported by old firmware from
> > linux-firmware repository.
> >
> > Please download binary file accessible from this link
> > http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2013-January/005610.html
> > and replace rt2870.bin file in /lib/firmware directory.
> >
> > Does it help ?
> 
> Great hint. Thanks!
> Turned out I had firmware version 0.22
> With firmware 0.29 or 0.33 the adapter works with unmodified kernel 3.13.
> 
> The only problem I have now is that when connected to a particular
> access point I get a lot of warnings like this:
> [  327.309858] ieee80211 phy0: rt2800usb_entry_txstatus_timeout:
> Warning - TX status timeout for entry 13 in queue 2
> and this:
> [  327.332847] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX
> status for an empty queue 2, dropping
> I didn't have this problem before (with older kernels and old firmware).

Does it mean that after you remove new rt2800_mcu_request() and use 0.22
firmware with 3.13 kernel you do not have those TX status timeout
warnings with this particular AP ?

On older kernels "TX status timeout" messages were only enabled if 
kernel was compiled with CONFIG_RT2X00_DEBUG option , so perhaps
that is the reason why you did not see them on older kernel with
older firmware. But if really TX status timeouts start to happen after
firmware update, we should fix our driver to better talk to the
firmware, though I do not have idea how. If not, we should probably
disable those messages in non-debug mode as it was on old kernels.

Stanislaw

Re: USB rt2x00 driver regression

[Sergei Antonov]

On 22 January 2014 17:25, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Wed, Jan 22, 2014 at 12:27:44PM +0100, Sergei Antonov wrote:
>> The only problem I have now is that when connected to a particular
>> access point I get a lot of warnings like this:
>> [  327.309858] ieee80211 phy0: rt2800usb_entry_txstatus_timeout:
>> Warning - TX status timeout for entry 13 in queue 2
>> and this:
>> [  327.332847] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX
>> status for an empty queue 2, dropping
>> I didn't have this problem before (with older kernels and old firmware).
>
> Does it mean that after you remove new rt2800_mcu_request() and use 0.22
> firmware with 3.13 kernel you do not have those TX status timeout
> warnings with this particular AP ?

I tried it and the warnings remained.

> On older kernels "TX status timeout" messages were only enabled if
> kernel was compiled with CONFIG_RT2X00_DEBUG option , so perhaps
> that is the reason why you did not see them on older kernel with
> older firmware. But if really TX status timeouts start to happen after
> firmware update, we should fix our driver to better talk to the
> firmware, though I do not have idea how. If not, we should probably
> disable those messages in non-debug mode as it was on old kernels.

Yes, it could have been due to CONFIG_RT2X00_DEBUG=n that I didn't
have warnings.
The warnings are printed at least since 3.9. Unfortunately, I could
not go back beyond 3.9 because of some compatibility issues between
the kernel and the rest of the system.

The AP with which I have the warnings is another Linux computer with
hostapd-2.0. Can it be the cause of this "TX status" thing?

Re: USB rt2x00 driver regression

[Stanislaw Gruszka]

On Wed, Jan 29, 2014 at 06:45:31PM +0100, Sergei Antonov wrote:
> > On older kernels "TX status timeout" messages were only enabled if
> > kernel was compiled with CONFIG_RT2X00_DEBUG option , so perhaps
> > that is the reason why you did not see them on older kernel with
> > older firmware. But if really TX status timeouts start to happen after
> > firmware update, we should fix our driver to better talk to the
> > firmware, though I do not have idea how. If not, we should probably
> > disable those messages in non-debug mode as it was on old kernels.
> 
> Yes, it could have been due to CONFIG_RT2X00_DEBUG=n that I didn't
> have warnings.

I will move those annoying messages back to debug level, they are
printed by default by mistake anyway.

> The AP with which I have the warnings is another Linux computer with
> hostapd-2.0. Can it be the cause of this "TX status" thing?

It can be that AP does not ACK some frames for some reason and we see
those warnings. Could you please provide me details about that AP (what
H/W and driver is used and hostapd config file), I will see if I could
reproduce those messages locally.

Stanislaw

Re: USB rt2x00 driver regression

[Sergei Antonov]

On 31 January 2014 13:16, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Wed, Jan 29, 2014 at 06:45:31PM +0100, Sergei Antonov wrote:
>> > On older kernels "TX status timeout" messages were only enabled if
>> > kernel was compiled with CONFIG_RT2X00_DEBUG option , so perhaps
>> > that is the reason why you did not see them on older kernel with
>> > older firmware. But if really TX status timeouts start to happen after
>> > firmware update, we should fix our driver to better talk to the
>> > firmware, though I do not have idea how. If not, we should probably
>> > disable those messages in non-debug mode as it was on old kernels.
>>
>> Yes, it could have been due to CONFIG_RT2X00_DEBUG=n that I didn't
>> have warnings.
>
> I will move those annoying messages back to debug level, they are
> printed by default by mistake anyway.
>
>> The AP with which I have the warnings is another Linux computer with
>> hostapd-2.0. Can it be the cause of this "TX status" thing?
>
> It can be that AP does not ACK some frames for some reason and we see
> those warnings. Could you please provide me details about that AP (what
> H/W and driver is used and hostapd config file), I will see if I could
> reproduce those messages locally.

OK. The details about HW follow.

It's a PCI Ralink card with firmware file taken recently from linux-firmware:
===============================
ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 2872, rev 0200 detected
ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 0003 detected
ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware
file 'rt2860.bin'
ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected -
version: 0.34
===============================

The hostapd.conf:
===============================
interface=wlan0
driver=nl80211
ssid=myname

country_code=DE
hw_mode=g

channel=11

auth_algs=1
logger_syslog=-1
logger_syslog_level=3
logger_stdout=-1
logger_stdout_level=2
ignore_broadcast_ssid=0

wpa=2
wpa_key_mgmt=WPA-PSK
wpa_passphrase=*******
rsn_pairwise=CCMP

macaddr_acl=1
accept_mac_file=/etc/hostapd.accept
===============================

The kernel I originally used was 3.4. But I just upgraded it to 3.13.1
and the problem remains. Config values are:
CONFIG_RT2X00=y
# CONFIG_RT2400PCI is not set
# CONFIG_RT2500PCI is not set
# CONFIG_RT61PCI is not set
CONFIG_RT2800PCI=y
# CONFIG_RT2800PCI_RT33XX is not set
# CONFIG_RT2800PCI_RT35XX is not set
# CONFIG_RT2800PCI_RT53XX is not set
CONFIG_RT2800PCI_RT3290=y
# CONFIG_RT2500USB is not set
# CONFIG_RT73USB is not set
# CONFIG_RT2800USB is not set
CONFIG_RT2800_LIB=y
CONFIG_RT2800_LIB_MMIO=y
CONFIG_RT2X00_LIB_MMIO=y
CONFIG_RT2X00_LIB_PCI=y
CONFIG_RT2X00_LIB=y
CONFIG_RT2X00_LIB_FIRMWARE=y
CONFIG_RT2X00_LIB_CRYPTO=y
CONFIG_RT2X00_LIB_LEDS=y
CONFIG_RT2X00_DEBUG=y
CONFIG_RTL_CARDS=y