EIO errors on SWI9200 modules

[Bjørn Mork]

Aleksander Morgado <aleksander at aleksander.es> writes:

> Hey Bjørn and everyone,
>
> I'm running Linux kernel 4.9.11, and getting a bunch of weird EIO
> errors randomly doing QMI operations with modems of the MC73xx family
> (SWI9200); I've tested MC7304, MC7330 and MC7354 with new and old
> firmwares. I cannot reproduce this issue with MC71xx (SWI9x15) or
> MC74xx (SWI9x30) modules.

Thanks! That cleared up quite a bit. Looks like I've been using MC74xx
modules too much lately.

Still a bit confused though: The MC73xx series use MDM9x15 chips.  The
MDM9x00 chips were used by the older MC77xx series.  I did test a modem
with MDM9200 lately (the Huawei E392), but could not reproduce the
problem there.  But if you really meant to say that the problem only
affects the MDM9x15 generation, then my results are consistent with
that.  Haven't tested any of those modems in a long time

> Reproducible easily with e.g.:
>
> $ while [ 1 ]; do sudo qmicli -d /dev/cdc-wdm2 --dms-get-operating-mode; done
> [21 mar 2017, 14:53:18] -Warning ** Error reading from istream: Error
> reading from file descriptor: Input/output error
> error: couldn't create client for the 'dms' service: CID allocation
> failed in the CTL client: Transaction timed out
> [/dev/cdc-wdm2] Operating mode retrieved:
> Mode: 'online'
> HW restricted: 'no'
> [/dev/cdc-wdm2] Operating mode retrieved:
> Mode: 'online'
> HW restricted: 'no'
> [/dev/cdc-wdm2] Operating mode retrieved:
> Mode: 'online'
> HW restricted: 'no'
> [21 mar 2017, 14:53:29] -Warning ** Error reading from istream: Error
> reading from file descriptor: Input/output error
> ...
>
> I was going to ask if this has ever been seen before, as it was new to
> me in my memory, and then I googled for it and found this old thread:
>
> https://lists.freedesktop.org/archives/libqmi-devel/2014-March/000734.html
>
> Quoting Bjørn:
>
> "What we know is:
>
>  - At some point wdm_in_callback() is called with urb->status == -EPIPE.
>  - the pending wdm_read() sees desc->rerr being non-zero (-EPIPE) and
>    returns -EIO to userspace"
>
> It's a bit unfortunate, because on -EIO we force the QmiDevice to get
> closed. Is there a better way to handle this? If there's nothing to
> fix in the kernel-side, should we maybe ignore -EIO errors and just
> warn about them, nothing else?

I think the problem you see is newer than that, and caused either by my
commit 833415a3e781 ("cdc-wdm: fix "out-of-sync" due to missing
notifications"), or by a combination of that with commit  c1da59dad0eb
("cdc-wdm: Clear read pipeline in case of error")



Bjørn