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:
The box should have an RT3062F wifi chipset.
If the command line is changed FROM
bootargs = "console=ttyLTQ0,115200 init=/etc/preinit"
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:
reg = <0x0 0x4000000>;
0x4000000 (64M - works)
0x3E00000 (62M - works not - only TX)
0x2000000 (32M - works)
0x2800000 (40M, works only partially)
Created attachment 200451 [details]
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?
Created attachment 200511 [details]
Normal dmesg output
Created attachment 200521 [details]
62M dmesg output
your patch does not print more informations...
The two dmesg files are
* with normal RAM settings
* with 62M RAM setting (only TX working)
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).
Created attachment 200531 [details]
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.
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.
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.
The debug prints's now are working. The driver from the kernel is not used.
Instead a backported driver is used, see:
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
Created attachment 202151 [details]
Created attachment 202161 [details]
OpenWRT DESIGNATED DRIVER (Bleeding Edge, r48735)
I have deleted all openWRT related patchs from the mac80211 package except the following four:
And deleted from package/kernel/mac80211/Makefile:
- 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
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
I have added a printk in bool rt2x00mmio_rxdone()
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
One possible issue could be that RXD_W1_DMA_DONE stays at zero.
Where will it set to one?
Created attachment 243591 [details]
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:
Created attachment 244011 [details]
This patch solves the issue of this bugreport, too.
Added new patch with simplified calculation from Eddi De Pieri:
PCI driver creator knows about bug and would resolve it.