I wrote: > I wrote: > > I wrote: > > > I wrote: > > > > Xose Vazquez Perez wrote: > > > > > Craig McQueen wrote: > > > > > > > > > > > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based > > > > > > (5392 chipset). I'm trying to use it on a BeagleBone Black > > > > > > based system with 3.14.x kernel built with Yocto. We're using > > > > > > ConnMan > > > > > > 1.30 at the > > > > moment. > > > > > > > > > > Try it with a _desktop x86_64 distribution_ , with a *recent > > > > > kernel* as > > > > > Fedora: (WORK is gnome) > > > > > https://alt.fedoraproject.org/pub/alt/live-respins/ > > > > > > > > Hmm, that is non-trivial but I may try it. > > > > > > > > For now, I'll also try a 4.4.6 kernel running on a BeagleBone > > > > Black (with a USB hub to work around another issue with the > > > > rt2800usb driver crashing as described in another e-mail). > > > > > > > > > > We've been finding some instabilities with it periodically > > > > > > disconnecting from some networks. So we tried upgrading the > > > > > > firmware file rt2870.bin from version 0.29 to 0.36. That seems > > > > > > to be more stable with the network. However, we're finding > > > > > > that it initially doesn't connect, until the Wi-Fi has been > > > > > > disabled and then re- > > > enabled. ' > > > > > scan wifi' > > > > > > and 'iwlist scan' don't return anything until Wi-Fi has been > > > > > > disabled and then re-enabled. > > > > > > > > > > Don't use any wrapper(NM, ConnMan, wicd, ...), usually are buggy. > > > > > You should use raw commands "iw" and "wpa_supplicant". Hints: > > > > > https://wireless.wiki.kernel.org/en/users/documentation/iw and > > > > > wpa_supplicant always running with "-Dnl80211" > > > > > > > > Okay, I've stripped down the system so ConnMan, udev rules aren't > > > running. > > > > > > > > On all systems, after plugging in the device, I have to issue: > > > > > > > > ip link set wlan0 up > > > > > > > > After this, I try to do a scan: > > > > > > > > iw dev wlan0 scan > > > > > > > > On kernel 4.4.6, with firmware 0.36, it works fine (lists APs it > > > > finds). On kernel 3.14.x, with firmware 0.29, it works fine. But > > > > on kernel 3.14.x, with firmware 0.36, it returns nothing. But then, if > > > > I do > this: > > > > > > > > ip link set wlan0 down > > > > ip link set wlan0 up > > > > iw dev wlan0 scan > > > > > > > > Then it works fine. > > > > > > > > So, the question is, why does firmware 0.36 with kernel 3.14.x not > > > > work until I've made the interface go up, then down, and then up > again? > > > > > > I've managed to build, using Yocto, kernel 4.4.12 for BeagleBone. > > > When I run it, it has the same problem. That's different from the > > > Ubuntu > > > 16.04 for BeagleBone using 4.4.6 kernel. > > > > > > With my Yocto build, it had a different version of the 'ip' and 'iw' > > commands. > > > So I tried copying the Ubuntu versions, but that didn't make a > > > difference. I tried using the Yocto built 4.4.12 kernel with the > > > Ubuntu root filesystem, but it halted during the boot process (don't > > > know why). My best guess is that there's some kernel config > > > difference that makes a difference, but there are many differences, > > > so I'm not sure > > which one it might be. > > > > > > I'm not sure at this point how to narrow it down to the root cause. > > > Any advice? > > > > > > I wonder if maybe there's a race condition in the rt2800usb driver > > > between loading the rt2870.bin firmware and doing the interface-up > > initialisation. > > > Normally the firmware loads at the point of doing the 'iw link set wlan0 > up' > > > command. Is there a way to force the firmware to load before that > > > command? > > > > I've got two rt2800 devices: > > > > * D-Link DWA-140 with RT chipset 5392, rev 0223, and RF chipset 5372 > > * Edup EP-N8537 with RT chipset 5390, rev 0502, and RF chipset 5370 > > > > I've also found that with the Yocto-built 4.4.12 kernel, this no-scan > > issue only happens to the Edup with the 5390 chipset. The D-Link is fine. > > Actually, I was wrong. With the 3.14.x Yocto-built kernel, this no-scan issue > only happens with the Edup with the 5390 chipset, and the D-Link is fine. > > But further testing with the 4.4.12 Yocto-built kernel shows that it randomly > sometimes happens and sometimes doesn't with either the Edup or D-Link > devices. That's especially interesting, because it suggests that there may be > a > race condition happening during the driver initialisation code (called from > rt2x00lib_start()). At first I thought it was a race condition between the > calls > to rt2x00lib_load_firmware() and rt2x00lib_initialize(), but adding a time > delay between those calls didn't help. > > I'm wondering what the difference is between the two chipsets, so that the > problem happens more on one chipset than the other. But not exclusively, as > I mentioned above, so again, this points to a marginal timing issue that > affects one more than the other. > > > With the Ubuntu 4.4.6 kernel, both devices work fine, without this > > no-scan problem. > > ...
Now I'm using a 4.9.65 kernel, and this problem is still present. When the USB Wi-Fi dongle is plugged in, it just doesn't do anything -- doesn't scan for Wi-Fi networks, doesn't connect to anything. My project is using ConnMan, so I've patched ConnMan so that it takes the device up, then down, then up again. Then it reliably works. But of course this is an ugly hack. Based on my initial investigation, my hypothesis was that there's a race condition during rt2x00lib_start() in rt2x00dev.c. At first I thought it was between firmware loading and initialisation. But adding a time delay between the calls to rt2x00lib_load_firmware() and rt2x00lib_initialize() didn't help. Adding time delays at many possible points in the initialisation didn't seem to help. I thought there must be a race condition in a very specific location in the initialisation sequence, but could not confirm that hypothesis. So now I've drawn a blank. Any advice on how to diagnose and remedy this issue? -- Craig McQueen
