Bug 110091
| Summary: | rt2800pci: wifi doesn't work with untypical RAM sizes | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Stefan Koch (stefan.koch10) |
| Component: | network-wireless | Assignee: | drivers_network-wireless (drivers_network-wireless) |
| Status: | RESOLVED INVALID | ||
| Severity: | high | CC: | Larry.Finger, linville, stf_xl, szg00000 |
| Priority: | P1 | ||
| Hardware: | Mips32 | ||
| OS: | Linux | ||
| Kernel Version: | 4.1.13 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
loaded kernel modules
rt2x00_show_rx_pointers.patch Normal dmesg output 62M dmesg output rt2x00_show_rx_pointers_new.patch dmesg1.txt dmesg2.txt lantiq-pci patch lantiq-pci_v2.patch |
||
|
Description
Stefan Koch
2015-12-28 16:36:08 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?
Created attachment 200511 [details]
Normal dmesg output
Created attachment 200521 [details]
62M dmesg output
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 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]
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.
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 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: 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 Created attachment 202151 [details]
dmesg1.txt
Created attachment 202161 [details]
dmesg2.txt
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 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
One possible issue could be that RXD_W1_DMA_DONE stays at zero. Where will it set to one? Created attachment 243591 [details]
lantiq-pci patch
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 Created attachment 244011 [details]
lantiq-pci_v2.patch
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 PCI driver creator knows about bug and would resolve it. |