Re: bad gsm connections

[Dan Williams <dcbw redhat com>]

On Thu, 2017-03-30 at 19:32 +0300, matti kaasinen wrote:
> I tried to analyze log files from one card having problematic
> connection.
> First my set-up briefly:
> 1) Embedded Linux card behind Huawei E3131 modem connection + NM &
> MM.
> 2) Drivers: Option and huawei_cdc_ncm.
> 3) Connection monitor with following functionality:
> - monitoring frequency 10 minutes
> - monitoring task, 1..18 ping operations with 10s timeout (max 3
> minutes
> for one task)
> - if all the 18 ping operations fail = task fails => USB power lines
> are
> sequenced.

How long is power to the card turned off?

> - any of 18 ping operations passes = task passes => wait to next task
> start.
> - if 12 successive tasks fail (2 hours) => boot card.
> 4) Occasionally bandwidth or field limited conditions that get modem
> firmware crash and boot frequently/at any time. It is not quite sure
> what
> crashes, but usb device gets re-numerated over and over.

If it keeps enumerating, that's the firmware crashing.

I forget if we've covered this or not, but are you sure there's
adequate power to the card?  If the modem gets into a situation where
it thinks it needs to transmit at a higher power and then draws too
much power, that could be the issue.  But I've seen enough firmware
changelogs to know that all kinds of firmware crash bugs get fixed all
the time too.

> From logs it seems that:
> - Usually connection recovers automatically.
> - If it does not, power sequencing usually helps.
> - However, some times it does not help. If the first sequencing fails
> helping, next 10 power breaks fail too and 12'th task boots the card.
> It
> shows from the logs that USB enumeration does not work anymore when
> power
> sequencing stops working, which suggests that either udev or most
> likely
> some kernel driver has crashed. However, no kernel crash logs are
> printed.

Yes, it could be a kernel driver issue here, but you'd need to enable
kernel driver debugging for the USB Host Controller to figure that out,
most likely.  Which could require a kernel recompile.

Dan

> Connection seems recovering soon after booting.
> This might come now to wrong forum, as kernel driver seems the most
> likely
> suspect. Please, feel free forwarding me to correct one (MM perhaps).
> Also
> feel free suggesting your choice of kernel driver I should reload to
> get
> this locked state released without booting.
>
> Thanks,
> Matti
>
> 2017-03-08 20:22 GMT+02:00 matti kaasinen <matti kaasinen gmail com>:
>
> > 2017-03-07 20:11 GMT+02:00 Dan Williams <dcbw redhat com>:
> >
> > > > > That's the modem firmware crashing and restarting.  It then
> > > > > reappears
> > > > > to the kernel and gets re-enumerated, and usb_modeswitch does
> > > > > its
> > > > > thing
> > > > > and then eventually it comes back as a modem.  Which could be
> > > > > due
> > > > > to
> > > > > any number of issues.
> > > >
> > > > But the first thing to check is whether the modem has enough
> > > > power.
> > > > > Laptops and embedded devices are sometimes unable to supply
> > > > > enough
> > > > > power to the USB ports while the modem is connected.
> >
> > I studied this today by breaking power lines from USB cable and
> > feeding
> > modem power lines directly from laboratory power. Huawei E3131
> > dongle was
> > enclosed in metal box to damp field. Good power supply did not
> > help. It
> > turned out that modem did not recover from this error mode with
> > power
> > sequencing and not necessarily by booting Linux card. It required
> > longer
> > break and opening the chassis lid. Which made me suspect warming
> > up.
> > However, heating did not trigger this error mode if field was
> > somewhat
> > better. So, perhaps either E3131 firmware or kernel driver does not
> > tolerate low fields. Perhaps switching between modes (e.g.
> > edge/gprs)
> > triggers the error. Anyhow, I could not figure out the reason.