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 <[email protected]>
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 <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
After I removed this special USB handling (see the patch) the adapter
works again.
On Mon, Jan 20, 2014 at 12:20:05PM +0100, Sergei Antonov wrote:
> On 19 January 2014 19:20, Gabor Juhos <[email protected]> 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
On 20 January 2014 19:50, Stanislaw Gruszka <[email protected]> wrote:
> On Mon, Jan 20, 2014 at 12:20:05PM +0100, Sergei Antonov wrote:
>> On 19 January 2014 19:20, Gabor Juhos <[email protected]> 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).
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 <[email protected]>
>>>>> 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 <[email protected]>
>>>>> Signed-off-by: John W. Linville <[email protected]>
>>>>>
>>>>> 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
On 22 January 2014 17:25, Stanislaw Gruszka <[email protected]> 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?
On Wed, Jan 22, 2014 at 12:27:44PM +0100, Sergei Antonov wrote:
> On 20 January 2014 19:50, Stanislaw Gruszka <[email protected]> wrote:
> > On Mon, Jan 20, 2014 at 12:20:05PM +0100, Sergei Antonov wrote:
> >> On 19 January 2014 19:20, Gabor Juhos <[email protected]> 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
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 <[email protected]>
> 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 <[email protected]>
> Signed-off-by: John W. Linville <[email protected]>
>
> 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++;
On Sun, 2014-01-19 at 11:57 +0100, Sergei Antonov wrote:
> > Am 17.01.2014 um 11:06 schrieb Stanislaw Gruszka <[email protected]>:
> >
> >> 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 <[email protected]>
> >> 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 <[email protected]>
> >> Signed-off-by: John W. Linville <[email protected]>
> >>
> >> 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
> Am 17.01.2014 um 11:06 schrieb Stanislaw Gruszka <[email protected]>:
>
>> 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 <[email protected]>
>> 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 <[email protected]>
>> Signed-off-by: John W. Linville <[email protected]>
>>
>> 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.
> Am 19.01.2014 um 13:19 schrieb Igor Gnatenko <[email protected]>:
>
> On Sun, 2014-01-19 at 11:57 +0100, Sergei Antonov wrote:
>>> Am 17.01.2014 um 11:06 schrieb Stanislaw Gruszka <[email protected]>:
>>>
>>>> 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 <[email protected]>
>>>> 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 <[email protected]>
>>>> Signed-off-by: John W. Linville <[email protected]>
>>>>
>>>> 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.
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
On 19 January 2014 19:20, Gabor Juhos <[email protected]> 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 <[email protected]>
>>>>>> 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 <[email protected]>
>>>>>> Signed-off-by: John W. Linville <[email protected]>
>>>>>>
>>>>>> 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.
On 31 January 2014 13:16, Stanislaw Gruszka <[email protected]> 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