11 Sep
2017
11 Sep
'17
2:24 p.m.
On Mon, Sep 11, 2017 at 11:01:23AM +0200, Pau Espin Pedrol wrote:
today I found the same issue again in prod (/sierra_2
-> /sierra_4).
Interestingly, both /sierra_2 and /sierra_3 seem to be using the same
firmware. dmesg shows again a disconnect from the usb port.
We have this idea of giving the same modem a persistent name on ofono, which
would solve the symptoms, but it's curious why this happens.
I had the watchdog script in place that power cycles the quad modem board and
restarts ofono as soon as the modem names mismatch what we expect. But lynxis
disabled it. The reasoning is that we won't catch ofono errors. That may be
true; my idea was to be able automatically recover ofono without manual
intervention. I guess it all depends on how closely you (lynxis) watch the gsm
testers for failures? Because my focus is not particularly on ofono, and when I
hit a broken situation and need to test things, I will restart ofono and rather
not in-depth investigate the failure; in a dismissive way "come on ofono, do
what I want now." What do you guys think about this?
I guess only /sierra_2 crashes because it's the
first modem in the
resources.conf list and thus it is usually used in all tests (for instance,
tests which require only 1 modem), and probably some of the steps done in
one of those tests is crashing the modem.
Something I thought about before: we could implement a kind of random or round
robin to not always pick the first matching resources in the list. Advantage is
that we would cycle through the hardware and force us to precisely formulate
e.g. modem requirements. The disadvantage is that not every test is run exactly
the same, adding complexity that may obscure analysis. i.e. to reproduce a run
on a particular modem, we would have to somehow clamp that randomness, e.g.
log a random seed at the start and allow passing in a random seed on the
cmdline.
~N