brcmfmac signal/interference issues

brcmfmac signal/interference issues

[Daniel Drake]

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?

Thanks
Daniel

Re: brcmfmac signal/interference issues

[Arend van Spriel]

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.

Regards,
Arend

Re: brcmfmac signal/interference issues

[Daniel Drake]

Hi Arend,

On Wed, Feb 21, 2018 at 12:07 PM, Arend van Spriel
<arend.vanspriel@broadcom.com> 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

Re: brcmfmac signal/interference issues

[Arend van Spriel]

On 2/21/2018 10:39 AM, Daniel Drake wrote:
> Hi Arend,
>
> On Wed, Feb 21, 2018 at 12:07 PM, Arend van Spriel
> <arend.vanspriel@broadcom.com> 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.

Ok. There goes my hunch :-( Will see if my colleagues who are more into 
RF details come up with a good idea.

Regards,
Arend

Re: brcmfmac signal/interference issues

[Daniel Drake]

Hi,

On Wed, Feb 21, 2018 at 12:39 PM, Daniel Drake <drake@endlessm.com> wrote:
> 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.

I checked Windows again and it seems to be using a firmware file
4345r6rtecdc.bin alongside this nvram data.
This firmware is different from the one in linux-firmware. I've
uploaded it here:
https://drive.google.com/open?id=1MUsiaoozslJb8SCYOR-FNbJFuD-h4PY_

I was hoping to try this on Linux to see if it makes any difference to
the issue seen here.
However, with thisi firmware in place, I can't connect to the network
at all. It associates, wpa_supplicant never sees the first WPA2 key
message sent from the AP - even though wireshark on a separate monitor
shows that the key message was sent, and that the STA acked it.

I turned off WPA2 to make it an open network instead, and now I am
unable to complete the DHCP conversation. According to the monitor
station, the STA succesfully transmits DHCPDISCOVER and the AP
responds with DHCPOFFER. The offer is acked, but dhclient never sees
it, and eventually times out.

Any ideas why this firmware may not be working at all on linux?

Thanks,
Daniel

Re: brcmfmac signal/interference issues

[Arend van Spriel]

On 2/23/2018 9:26 AM, Daniel Drake wrote:
> Hi,
>
> On Wed, Feb 21, 2018 at 12:39 PM, Daniel Drake <drake@endlessm.com> wrote:
>> 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.
>
> I checked Windows again and it seems to be using a firmware file
> 4345r6rtecdc.bin alongside this nvram data.
> This firmware is different from the one in linux-firmware. I've
> uploaded it here:
> https://drive.google.com/open?id=1MUsiaoozslJb8SCYOR-FNbJFuD-h4PY_
>
> I was hoping to try this on Linux to see if it makes any difference to
> the issue seen here.
> However, with thisi firmware in place, I can't connect to the network
> at all. It associates, wpa_supplicant never sees the first WPA2 key
> message sent from the AP - even though wireshark on a separate monitor
> shows that the key message was sent, and that the STA acked it.
>
> I turned off WPA2 to make it an open network instead, and now I am
> unable to complete the DHCP conversation. According to the monitor
> station, the STA succesfully transmits DHCPDISCOVER and the AP
> responds with DHCPOFFER. The offer is acked, but dhclient never sees
> it, and eventually times out.
>
> Any ideas why this firmware may not be working at all on linux?

Yup. Windows firmware talks NDIS. If you run 'strings 4345r6rtecdc.bin | 
tail -1' you can see the firmware build target and it likely has 'ndis' 
in it.

Now are you using BT as well on this device? Another suggestion I got is 
to disable transmit beamforming which brcmfmac enables by default. Not 
sure if this device supports it, but could you try the patch below.

Regards,
Arend

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index 9be0b05..512ea57 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -363,9 +363,6 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
                 goto done;
         }

-       /* Enable tx beamforming, errors can be ignored (not supported) */
-       (void)brcmf_fil_iovar_int_set(ifp, "txbf", 1);
-
         /* do bus specific preinit here */
         err = brcmf_bus_preinit(ifp->drvr->bus_if);
  done:

Re: brcmfmac signal/interference issues

[Daniel Drake]

On Fri, Feb 23, 2018 at 12:54 PM, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> Yup. Windows firmware talks NDIS. If you run 'strings 4345r6rtecdc.bin |
> tail -1' you can see the firmware build target and it likely has 'ndis' in
> it.

43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf

Yes, ndis. So no easy way to run the same firmware on the 2 OSes.

> Now are you using BT as well on this device? Another suggestion I got is to
> disable transmit beamforming which brcmfmac enables by default. Not sure if
> this device supports it, but could you try the patch below.

Thanks for the ideas. I had already tried with the bluetooth disabled
- no change there.
Also reproduced the problem after applying your patch.

Daniel

Re: brcmfmac signal/interference issues

[Arend van Spriel]

On 2/23/2018 2:49 PM, Daniel Drake wrote:
> On Fri, Feb 23, 2018 at 12:54 PM, Arend van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> Yup. Windows firmware talks NDIS. If you run 'strings 4345r6rtecdc.bin |
>> tail -1' you can see the firmware build target and it likely has 'ndis' in
>> it.

Hi Daniel,

Bit late response. Sorry.

> 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf
>
> Yes, ndis. So no easy way to run the same firmware on the 2 OSes.

Indeed. I could try building nearly same firmware target. Can you 
provide the firmware version as well.

Now reading over your orignal email again:

 > 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.

So it picks up something in the PC. Some sources of interference that I 
have seen before are USB3 and HDMI. Maybe try to shield those if present 
and see if that helps. The nvram contains sensitivity parameters, but as 
you stated you are using the same nvram for windows and linux for now we 
can rule it out for debugging the issue.

Regards,
Arend

Re: brcmfmac signal/interference issues

[Steve deRosier]

On Thu, Mar 8, 2018 at 2:47 AM, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 2/23/2018 2:49 PM, Daniel Drake wrote:
>>
>> On Fri, Feb 23, 2018 at 12:54 PM, Arend van Spriel
>> <arend.vanspriel@broadcom.com> wrote:
>>>
>>> Yup. Windows firmware talks NDIS. If you run 'strings 4345r6rtecdc.bin |
>>> tail -1' you can see the firmware build target and it likely has 'ndis'
>>> in
>>> it.
>
>
> Hi Daniel,
>
> Bit late response. Sorry.
>
>>
>> 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf
>>
>> Yes, ndis. So no easy way to run the same firmware on the 2 OSes.
>
>
> Indeed. I could try building nearly same firmware target. Can you provide
> the firmware version as well.
>
> Now reading over your orignal email again:
>
>> 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.
>
> So it picks up something in the PC. Some sources of interference that I have
> seen before are USB3 and HDMI. Maybe try to shield those if present and see
> if that helps. The nvram contains sensitivity parameters, but as you stated
> you are using the same nvram for windows and linux for now we can rule it
> out for debugging the issue.
>

Hi Daniel,

I'll jump in here too...

Did you check the Bluetooth?  I don't know if this chip has it or if
it's an independent chip on this board, but if Linux is leaving it
powered up but not properly configured you could have issues. And in
some designs, the BT and WiFi will share a single antenna. Note that
I'm not saying you've configured BT to run, I'm actually suggesting
that the pin that enables it is on, but you might not be loading the
BT drivers and firmware and so the thing is just in a wonky
uninitialized state. Or you do have it enabled and should try turning
it off.  Either way.

And WiFi/BT coex has always been a bit of a problem (speaking
generally, I don't know the status with this particular chip) in
Linux. I see WiFi and BT interfering with each other frequently in my
testing setups with my dev boards. Often I can magically make problems
go away by simply pulling the enable line high (which is "off").

- Steve

--
Steve deRosier
Cal-Sierra Consulting LLC
https://www.cal-sierra.com/

Re: brcmfmac signal/interference issues

[Arend van Spriel]

On 3/8/2018 4:54 PM, Steve deRosier wrote:
> On Thu, Mar 8, 2018 at 2:47 AM, Arend van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 2/23/2018 2:49 PM, Daniel Drake wrote:
>>>
>>> On Fri, Feb 23, 2018 at 12:54 PM, Arend van Spriel
>>> <arend.vanspriel@broadcom.com> wrote:
>>>>
>>>> Yup. Windows firmware talks NDIS. If you run 'strings 4345r6rtecdc.bin |
>>>> tail -1' you can see the firmware build target and it likely has 'ndis'
>>>> in
>>>> it.
>>
>>
>> Hi Daniel,
>>
>> Bit late response. Sorry.
>>
>>>
>>> 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf
>>>
>>> Yes, ndis. So no easy way to run the same firmware on the 2 OSes.
>>
>>
>> Indeed. I could try building nearly same firmware target. Can you provide
>> the firmware version as well.
>>
>> Now reading over your orignal email again:
>>
>>> 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.
>>
>> So it picks up something in the PC. Some sources of interference that I have
>> seen before are USB3 and HDMI. Maybe try to shield those if present and see
>> if that helps. The nvram contains sensitivity parameters, but as you stated
>> you are using the same nvram for windows and linux for now we can rule it
>> out for debugging the issue.
>>
>
> Hi Daniel,
>
> I'll jump in here too...
>
> Did you check the Bluetooth?  I don't know if this chip has it or if
> it's an independent chip on this board, but if Linux is leaving it
> powered up but not properly configured you could have issues. And in
> some designs, the BT and WiFi will share a single antenna. Note that
> I'm not saying you've configured BT to run, I'm actually suggesting
> that the pin that enables it is on, but you might not be loading the
> BT drivers and firmware and so the thing is just in a wonky
> uninitialized state. Or you do have it enabled and should try turning
> it off.  Either way.
>
> And WiFi/BT coex has always been a bit of a problem (speaking
> generally, I don't know the status with this particular chip) in
> Linux. I see WiFi and BT interfering with each other frequently in my
> testing setups with my dev boards. Often I can magically make problems
> go away by simply pulling the enable line high (which is "off").

Thanks, Steve

Disabling BT was indeed suggested, but indeed pulling BT_REG_ON high 
will ensure there is nothing active on BT side. In BT the firmware is 
generally speaking on-chip with possibility to download firmware patch 
to the device. However, if no driver does hci initialization I would 
expect BT to be passive/silent, but I guess your magic proves otherwise ;-)

Regards,
Arend

Re: brcmfmac signal/interference issues

[Daniel Drake]

On Thu, Mar 8, 2018 at 9:54 AM, Steve deRosier <derosier@gmail.com> wrote:
> Did you check the Bluetooth?  I don't know if this chip has it or if
> it's an independent chip on this board, but if Linux is leaving it
> powered up but not properly configured you could have issues.

I had already disabled it via hciconfig, without any effect on the problem.

Based on your suggestion I also checked BT_REG_ON, which was not being
affected by hciconfig. On AP6255 I believe it is active high, so I
brought it low to disable bluetooth, confirmed with a scope, and the
problem is still there.

Thanks for the suggestion anyway!
Daniel

Re: brcmfmac signal/interference issues

[Daniel Drake]

On Thu, Mar 8, 2018 at 4:47 AM, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
>> 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf
>>
>> Yes, ndis. So no easy way to run the same firmware on the 2 OSes.
>
> Indeed. I could try building nearly same firmware target. Can you provide
> the firmware version as well.

Full string is:
43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf
Version: 7.45.87.0 CRC: 7cb2470e Date: Thu 2016-04-21 22:31:44 PDT
Ucode Ver: 1043.2070 FWID: 01-f68ec182

If you could build that config but for Linux instead of ndis I would
love to try it.

Also, here is the string for the current one in linux-firmware:
43455c0-roml/sdio-ag-p2p-pno-aoe-pktfilter-keepalive-mchan-pktctx-proptxstatus-ampduhostreorder-lpc-pwropt-txbf-wnm-okc-ccx-ltecx-wfds-wl11u-mfp-tdls-ve
Version: 7.45.18.0 CRC: d7226371 Date: Sun 2015-03-01 07:31:57 PST
Ucode Ver: 1026.2 FWID: 01-6a2c8ad4

I note that the Version and UcodeVer in the linux-firmware version are
lower than the windows one. If it's possible to also rebuild the
linux-firmware config but with those newer versions (or even the
latest, if there is something newer), I will test that too.

> So it picks up something in the PC. Some sources of interference that I have
> seen before are USB3 and HDMI. Maybe try to shield those if present and see
> if that helps. The nvram contains sensitivity parameters, but as you stated
> you are using the same nvram for windows and linux for now we can rule it
> out for debugging the issue.

Yeah, there are some options here which we can try to explore. What's
still unknown though is why windows appears immune to this exact same
interference. A software fix would be much more convenient... :)

Daniel

Re: brcmfmac signal/interference issues

[Arend van Spriel]

On 3/28/2018 8:43 PM, Daniel Drake wrote:
> On Thu, Mar 8, 2018 at 4:47 AM, Arend van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>>> 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf
>>>
>>> Yes, ndis. So no easy way to run the same firmware on the 2 OSes.
>>
>> Indeed. I could try building nearly same firmware target. Can you provide
>> the firmware version as well.
>
> Full string is:
> 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf
> Version: 7.45.87.0 CRC: 7cb2470e Date: Thu 2016-04-21 22:31:44 PDT
> Ucode Ver: 1043.2070 FWID: 01-f68ec182
>
> If you could build that config but for Linux instead of ndis I would
> love to try it.
>
> Also, here is the string for the current one in linux-firmware:
> 43455c0-roml/sdio-ag-p2p-pno-aoe-pktfilter-keepalive-mchan-pktctx-proptxstatus-ampduhostreorder-lpc-pwropt-txbf-wnm-okc-ccx-ltecx-wfds-wl11u-mfp-tdls-ve
> Version: 7.45.18.0 CRC: d7226371 Date: Sun 2015-03-01 07:31:57 PST
> Ucode Ver: 1026.2 FWID: 01-6a2c8ad4
>
> I note that the Version and UcodeVer in the linux-firmware version are
> lower than the windows one. If it's possible to also rebuild the
> linux-firmware config but with those newer versions (or even the
> latest, if there is something newer), I will test that too.

Thanks for the version info. I will look if we could use similar version 
as window version, but typically they spin from different branches.

>> So it picks up something in the PC. Some sources of interference that I have
>> seen before are USB3 and HDMI. Maybe try to shield those if present and see
>> if that helps. The nvram contains sensitivity parameters, but as you stated
>> you are using the same nvram for windows and linux for now we can rule it
>> out for debugging the issue.
>
> Yeah, there are some options here which we can try to explore. What's
> still unknown though is why windows appears immune to this exact same
> interference. A software fix would be much more convenient... :)

Obviously ;-) And the immunity seems to justify that path.

Regards,
Arend