Re: Stockholm syndrome with Linux wireless?

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Mon, Sep 26, 2022 at 11:20:18AM +0300, Kalle Valo wrote:
> (changing the subject as this has nothing to do with brcmfmac)
> 
> Linus Walleij <linus.walleij@linaro.org> writes:
> 
> > On Thu, Sep 22, 2022 at 3:31 PM Alvin Šipraga <ALSI@bang-olufsen.dk> wrote:
> >
> >> I would also point out that the BCM4359 is equivalent to the
> >> CYW88359/CYW89359 chipset, which we are using in some of our
> >> products. Note that this is a Cypress chipset (identifiable by the
> >> Version: ... (... CY) tag in the version string). But the FW Konrad is
> >> linking appears to be for a Broadcom chipset.
> >
> > This just makes me think about Peter Robinsons seminar at
> > LPC last week...
> > "All types of wireless in Linux are terrible and why the vendors
> > should feel bad"
> > https://lpc.events/event/16/contributions/1278/attachments/1120/2153/wireless-issues.pdf
> 
> Thanks, this was a good read! I'm always interested about user and
> downstream feedback, both good and bad :) But I didn't get the Stockholm
> syndrome comment in the end, what does he mean with that?
> 
> BTW we have a wireless workshop in netdevconf 0x16, it would be great to
> have there a this kind of session discussing user pain points:
> 
> https://netdevconf.info/0x16/session.html?Wireless-Workshop

You asked. :)

It's probably outside of your control as it's probably firmware issues
is when using Broadcom or TI WiFi in AP mode, and the resulting
instability.

Over the years, SolidRun have used Broadcom 4329 and 4330 chipsets on
their iMX6 products, and then switched to using a TI WL18xx chipset.
I forget what the issues were with the Broadcom chipsets, as I'm
currently using the TI variants.

In order to keep the WiFi network stable, I implemented a userspace
program that polls the WL18xx statistics in debugfs every 100ms, and
when it seems the adapter has got stuck, it takes the interface down
and brings it back up again to reset stuff. This seems to improve the
overall stability, but it's still far from perfect as one regularly
sees latency go through the roof.

I recently noticed (earlier this month) a bigger problem with it -
I had one laptop running zoom, another laptop running interactive
stuff, and while zoom was running, the other laptop basically lost
network access - which came back when zoom was stopped. I'm not
sure what was going on there, because if you don't have the ability
to do interactive stuff it's pretty hard to debug what's going on
at the machine with the AP.

I've just looked at that machine, which has been mostly idle (as in
no clients connected) and I see:

[271559.346460] wlcore: ERROR Tx stuck (in FW) for 5000 ms. Starting recovery
[271559.353395] WARNING: CPU: 1 PID: 6395 at drivers/net/wireless/ti/wlcore/main.c:803 wl12xx_queue_recovery_work.part.0+0x50/0x54 [wlcore]

with the resutling entirely useless backtrace - that's 3 days, 3 hours
and 25 minutes ago, which would make it Friday 6:25am when nothing
was connected to the wifi network.

I've turned off all the runtime PM for the hardware path for wifi
conenctivity (every single power/control file is forced to "on") so
it isn't being triggered by some runtime PM behaviour.

Like I think many, I've come to the conclusion that WiFi is just a
completely unstable medium, and wired networking is just far superior,
even though it comes with the nusience of needing wires.

I don't think this is the fault of the Linux WiFi core code, I think
this is down to vendors, and vendors just do not want to know about
problems.

That said, running this stuff in AP mode isn't vendors primary goal,
since that isn't what most users want to do, so it's probably
understandable that AP mode tends to be flakey.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!