Hi Arend, On Wed, Feb 21, 2018 at 12:07 PM, Arend van Spriel <arend.vanspriel@xxxxxxxxxxxx> wrote: > > On 2/21/2018 9:14 AM, Daniel Drake wrote: >> >> Hi, >> >> We're working with the Weibu F3C MiniPC which includes BCM43455 SDIO >> wifi chip 0x004345(17221) rev 0x000006 (AP6255 module). >> >> We are seeing a strange issue where usually within an hour of usage, >> the wifi connection becomes so unstable and lossy that it is unusable. >> While investigating this my standard test is to send ICMP pings to the >> IP address of the local access point. Normally the latency is 5-10ms, >> but when this problem is seen it will go to 500ms and then increase up >> towards 20s before completely timing out. >> >> Sometimes it is possible to induce the problem on-demand by stressing >> some combination of CPU, disk and/or USB. At this point, ping reply >> latency increases from ~5ms to 500ms+ before increasing even further. >> Killing the stress test, the pings immediately return to normal. This >> is not concrete though - I also seem to have a lot of luck hitting the >> problem in the morning when booting up the computer from stone cold >> state, while it is idle. >> >> When the problem is being reproduced (ping times are high or get no >> response), touching the exposed metal on the antenna connector with my >> finger makes ping times return to normal. Touching it with a piece of >> plastic does not have the same effect - so it is some effect of body >> capacitance or similar. Also, disconnecting the antenna makes ping >> times return to normal, although outside of the simple pings, >> bandwidth is much reduced. >> >> Additionally, when the problem is being reproduced, if I move the >> antenna outside of the case, ping times return to normal. When I move >> the antenna back into the miniPC case vicinity, it goes slow and lossy >> again. >> >> I have used a separate monitoring station with wireshark to look at >> the 802.11 traffic while this is happening. When the problem is >> reproduced, the miniPC is mostly unable to TX anything, and the AP >> sends frames and retries them but with no ACK visible from the miniPC. >> Immediately when I touch the antenna connector with my finger, tx >> frames from the miniPC appear and the conversation comes back to life. >> >> Running Linux 4.15 but we believe all versions are affected. >> >> This very much sounds like a hardware issue, but here is where things >> get interesting: Windows 10 on the same unit has no such problem. >> >> I set up 2 units side by side - one running Windows 10 and the other >> running Linux, connected to the same AP. The top part of the MiniPC >> case has been removed so I can see the motherboard. I free up the >> antennas from the MiniPC casing and they are on a relatively long >> cable, so they can be freely moved around in this test, allowing me to >> dangle the antenna into the vicinity of the neighbouring unit miniPC >> case. >> >> If I place both antenna terminals inside the Linux MiniPC case, the >> Linux pings are bad but the Windows pings are fine. >> >> If I place both antenna terminals inside the Windows MiniPC case, it >> is the same: Linux pings are bad, but the Windows pings are fine. >> >> And when the Linux antenna is placed outside of both cases, the Linux >> pings are fine. I've repeated these tests a handful of times in quick >> succession to make sure that I'm not going crazy and that this is not >> a case of the problem intermittency causing misleading results. These >> findings appear very solid. >> >> This suggests that regardless of the running OS, the MiniPC produces >> some kind of interference that intermittently has an extremely >> detrimental effect on wifi signal when you are running Linux. However, >> Windows is somehow immune to this. >> >> Any ideas for how to continue debugging this? How can we make the >> Linux driver immune to this interference like the windows one is? > > > Hi Daniel, > > Thanks. I forwarded your detailed report. My first hunch would be the nvram file used. Are you using the same nvram file on Linux as the one on Windows? If not can you compare them or better just sent them. Thanks for looking into this. Here is the brcmfmac43455-sdio.txt file we are using: https://gist.github.com/dsd/d7ee3caa6dfd77f0bcd16cf272b20298 This is identical to the 4345r6nvram.txt file from windows. Daniel
