| Message ID | 52DC1761.9080608@openwrt.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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. -- 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
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 -- 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
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). -- 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
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 -- 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
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? -- 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
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 -- 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
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 -- 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
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