Bug 110091 - rt2800pci: wifi doesn't work with untypical RAM sizes
Summary: rt2800pci: wifi doesn't work with untypical RAM sizes
Status: RESOLVED INVALID
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: Mips32 Linux
: P1 high
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-28 16:36 UTC by Stefan Koch
Modified: 2016-11-09 07:25 UTC (History)
4 users (show)

See Also:
Kernel Version: 4.1.13
Tree: Mainline
Regression: No


Attachments
loaded kernel modules (2.62 KB, text/plain)
2015-12-28 16:36 UTC, Stefan Koch
Details
rt2x00_show_rx_pointers.patch (604 bytes, text/plain)
2016-01-19 08:54 UTC, Stanislaw Gruszka
Details
Normal dmesg output (12.44 KB, text/plain)
2016-01-19 23:30 UTC, Stefan Koch
Details
62M dmesg output (12.44 KB, text/plain)
2016-01-19 23:31 UTC, Stefan Koch
Details
rt2x00_show_rx_pointers_new.patch (1.35 KB, text/plain)
2016-01-20 09:07 UTC, Stanislaw Gruszka
Details
dmesg1.txt (110.19 KB, text/plain)
2016-01-28 00:09 UTC, Stefan Koch
Details
dmesg2.txt (22.00 KB, text/plain)
2016-01-28 00:09 UTC, Stefan Koch
Details
lantiq-pci patch (1.04 KB, patch)
2016-11-03 23:59 UTC, Stefan Koch
Details | Diff
lantiq-pci_v2.patch (651 bytes, patch)
2016-11-08 22:26 UTC, Stefan Koch
Details | Diff

Description Stefan Koch 2015-12-28 16:36:08 UTC
Created attachment 198421 [details]
loaded kernel modules

Problem: Wifi does only work with normal RAM sizes (like 32M, 64M in assumption f(x)=2^x works)

Kernel version: 4.1.13 (mainline, with patches)
Kernel patches: https://dev.openwrt.org/browser/trunk/target/linux/lantiq/patches-4.1
Openwrt version: DESIGNATED DRIVER (Bleeding Edge, r48014)

This was tested with the Arcadyan VGV7510KW22 Router, DTS file is here:
https://dev.openwrt.org/browser/trunk/target/linux/lantiq/dts/VGV7510KW22.dtsi

The box should have an RT3062F wifi chipset.

If the command line is changed FROM
bootargs = "console=ttyLTQ0,115200 init=/etc/preinit"
TO
bootargs = "console=ttyLTQ0,115200 init=/etc/preinit phym=64M mem=62M"

-> The wifi SSID is sent out, but connecting is not possible. So only TX works.

But the command line

bootargs = "console=ttyLTQ0,115200 init=/etc/preinit phym=64M mem=32M"

works (TX and RX), half of the RAM is lost now :(

If you ask why to do so, this is needed to reserve RAM for VMMC when lantiq FXS support should be enabled.
This is to use the telephone ports, a. e. with asterisk telephony service.

The test above is made with the generic trunk version of openWRT, without vmmc patches.
Wifi works perfectly with normal RAM sizes like 32M or 64M.
With 62M it doesn't work, 40M work partially. Wifi is then slower as with 64M or 32M, and there are warnings like:
[   75.848060] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[   75.936032] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[   75.943276] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0001, signal=0x0175, type=4
[   75.955291] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 3958 max 3840
[   75.965162] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0072, type=4 

Sometimes there are these warnings (not with normal RAM sizes):
[  788.625255] ieee80211 phy0: rt2800mmio_txdone: Warning - Got TX status for an empty queue 0, dropping

The same issues are there without change of the commandline but modify the following entry in the DTS file:
memory@0 {
  reg = <0x0 0x4000000>;
};

0x4000000 (64M - works)
0x3E00000 (62M - works not - only TX)
0x2000000 (32M - works)
0x2800000 (40M, works only partially)
Comment 1 Stanislaw Gruszka 2016-01-19 08:54:16 UTC
Created attachment 200451 [details]
rt2x00_show_rx_pointers.patch

Perhaps with non standard memory size we have do not correctly aligned buffers. Could you pleas apply this patch, which print buffer addresses, and attach dmesg outputs from system running standard and non-standart memory sizes?
Comment 2 Stefan Koch 2016-01-19 23:30:49 UTC
Created attachment 200511 [details]
Normal dmesg output
Comment 3 Stefan Koch 2016-01-19 23:31:21 UTC
Created attachment 200521 [details]
62M dmesg output
Comment 4 Stefan Koch 2016-01-19 23:32:37 UTC
Hi,

your patch does not print more informations...

The two dmesg files are

* with normal RAM settings
* with 62M RAM setting (only TX working)

Thanks

Stefan
Comment 5 Stanislaw Gruszka 2016-01-20 09:04:28 UTC
Patch prints messages here on my rt2800pci device. So seems either patch was not correctly applied or there is some patch on openwrt that use different buffer allocation method (link https://dev.openwrt.org/browser/trunk/target/linux/lantiq/patches-4.1 is broken, so I can not see).
Comment 6 Stanislaw Gruszka 2016-01-20 09:07:59 UTC
Created attachment 200531 [details]
rt2x00_show_rx_pointers_new.patch

New upstream kernel, which seems openWrt use, move rt2x00 driver to different directory, perhaps that why previous patch did not apply correctly. Here is new patch, which apply on that different directory. Except printing buffer addresses, it also prints "AAAAAAAAAAAAA rt2x00 patched" to see if patch was applied at all.
Comment 7 Stefan Koch 2016-01-25 23:52:59 UTC
Hi,

this must be another problem that the printk's are not printed... :(

root@OpenWrt:/# cat /proc/sys/kernel/printk
7       4       1       7

I have enabled KERNEL_DYNAMIC_DEBUG, but it changed nothing. I can't see the "AAAA..." printing.

So I have to find out this. I have uses 4.1 again, because the board support have some problems with 4.4, at the moment.

Thanks

Stefan
Comment 8 Stanislaw Gruszka 2016-01-27 08:58:03 UTC
Maybe AAAA... message is not in code that is used, but I doubt that, you have rt2800pci module loaded - I can see that in the first attachment. Hence most likely patch is not applied. Perhaps you could add similar message to different subsystem or driver that is running and see if that works.
Comment 9 Stefan Koch 2016-01-28 00:08:42 UTC
The debug prints's now are working. The driver from the kernel is not used.
Instead a backported driver is used, see:
http://mirror2.openwrt.org/sources/compat-wireless-2015-12-03.tar.bz2

There also a lot of patches inside it.

I still used 4.1 kernel, with backported driver, so that your second patch applies for the directory structure.

In the error case the driver stops printing the messages (after few seconds), before a wifi connection could be started (what is not possible then).

dmesg1.txt: working version with 64M RAM
dmesg2.txt: not working version with 62M RAM
Comment 10 Stefan Koch 2016-01-28 00:09:13 UTC
Created attachment 202151 [details]
dmesg1.txt
Comment 11 Stefan Koch 2016-01-28 00:09:37 UTC
Created attachment 202161 [details]
dmesg2.txt
Comment 12 Stefan Koch 2016-02-17 22:17:21 UTC
VERSION INFO:
OpenWRT DESIGNATED DRIVER (Bleeding Edge, r48735)

Linux 4.4.0

Driver-Source: http://mirror2.openwrt.org/sources/compat-wireless-2016-01-10.tar.bz2

Driver-Patches: https://dev.openwrt.org/browser/trunk/package/kernel/mac80211/patches





DESCRIPTION:
I have deleted all openWRT related patchs from the mac80211 package except the following four:
000-fix_kconfig.patch
001-fix_build.patch
002-change_allconfig.patch
100-remove-cryptoapi-dependencies.patch
602-rt2x00-introduce-rt2x00_platform_h.patch
603-rt2x00-introduce-rt2x00eeprom.patch
604-rt2x00-of_load_eeprom_filename.patch
605-rt2x00-load-eeprom-on-SoC-from-a-mtd-device-defines-.patch
607-rt2x00-allow_disabling_bands_through_platform_data.patch
608-add_platform_data_mac_addr.patch

And deleted from package/kernel/mac80211/Makefile:
 define Build/Configure
-       cmp $(PKG_BUILD_DIR)/include/linux/ath9k_platform.h $(LINUX_DIR)/include/linux/ath9k_platform.h
-       cmp $(PKG_BUILD_DIR)/include/linux/ath5k_platform.h $(LINUX_DIR)/include/linux/ath5k_platform.h
-       cmp $(PKG_BUILD_DIR)/include/linux/rt2x00_platform.h $(LINUX_DIR)/include/linux/rt2x00_platform.h
 endef

Note: The 60*.patch files introduce reading MAC from eeprom.
Without these patches the SSID is send out, but connecting is not possible (with 64M RAM).
This have similaries with the RAM issue.

The wifi issue with 62M RAM is still there. Also with MAC/eeprom patches.
So the RAM issue should not related to the openWRT patches for the mac80211 package.

The following messages are at reboot
br-lan: port 2(wlan0) entered disabled state
ieee80211 phy0: rt2x00queue_flush_queue: Warning - Queue 0 failed to flush
Comment 13 Stefan Koch 2016-02-18 12:14:41 UTC
I have added a printk in bool rt2x00mmio_rxdone()

if (rt2x00dev->ops->lib->get_entry_state(entry))
    break;

The state is with 62M every time 1.

With 64M it has the values 1 and 0.


The state attribute of the following function has with 62M and 64M the same values

static int rt2800pci_set_device_state(struct rt2x00_dev *rt2x00dev, enum dev_state state)

[   26.860038] devstate 4
[   26.924846] devstate 6
[   26.939199] devstate 3
Comment 14 Stefan Koch 2016-02-18 18:44:17 UTC
One possible issue could be that RXD_W1_DMA_DONE stays at zero.

Where will it set to one?
Comment 15 Stefan Koch 2016-11-03 23:59:55 UTC
Created attachment 243591 [details]
lantiq-pci patch
Comment 16 Stefan Koch 2016-11-04 00:01:56 UTC
The rt2xx drivers are not the issue of the problem.
A wrong calculation of BAR11MASK within arch/mips/pci/pci-lantiq.c causes the bug.

See lantiq-pci patch from Eddi De Pieri:
https://github.com/openwrt-vgv7519/source/blob/b07bfba9849ec41bf1d56df646dd7acc00156e7a/target/linux/lantiq/patches-4.4/0154-lantiq-pci-bar11mask-fix.patch
Comment 17 Stefan Koch 2016-11-08 22:26:49 UTC
Created attachment 244011 [details]
lantiq-pci_v2.patch
Comment 18 Stefan Koch 2016-11-08 22:30:59 UTC
This patch solves the issue of this bugreport, too.

Added new patch with simplified calculation from Eddi De Pieri:
https://github.com/openwrt-vgv7519/source/blob/c5d24cb17fa5d50332ed1903b4c1ba03ed2272cb/target/linux/lantiq/patches-4.4/0154-lantiq-pci-bar11mask-fix.patch
Comment 19 Stefan Koch 2016-11-09 07:25:43 UTC
PCI driver creator knows about bug and would resolve it.

Note You need to log in before you can comment on or make changes to this bug.