qmi-proxy crashing?

Paul Gildea gildeap at tcd.ie
Wed Feb 26 10:58:16 UTC 2020


Hey Aleksander,

I never checked had it actually crashed, I thought the message had meant it
was trying to start it. If/when this happens again I have a good range of
tests I can run now, thanks!
If I can figure out a way to make this issue happen at will (or if
relaunching the proxy does not fix the issue) I can test the verbose proxy
debug also.

I am resetting the modem with the below commands and they generally work
perfectly. I am setting up a test to do it hundreds of times.

qmicli -p -d /dev/cdc-wdmX --dms-set-operating-mode=offline
qmicli -p -d /dev/cdc-wdmX --dms-set-operating-mode=reset


For that issue (where a modem gets issued a reset and doesn't actually do
it) I will run it with the verbose flag next time I see it.

Cheers,

--
Paul

On Tue, 25 Feb 2020 at 13:11, Aleksander Morgado <aleksander at aleksander.es>
wrote:

> Hey Paul,
>
> > Have seen this issue a few times now, the qmi-proxy appears to be
> crashing. Every qmi command for every modem on the system then gets this
> error:
> >
> > qmicli --device-open-qmi -p -d /dev/cdc-wdm9 --nas-get-signal-strength
> > error: couldn't open the QmiDevice: Couldn't spawn the qmi-proxy
> >
> >
> > Have you seen this before, or can think of a good way to debug it? Can
> that daemon be restarted?
> > So far only rebooting the whole system will bring the modems/qmicli back
> to operation.
> >
>
> If the qmi-proxy crashes, clients get notified via a HUP in the
> communication socket, and so e.g. MM would reprobe the modem from
> scratch. When using qmicli, if the qmi-proxy has crashed, it should be
> able to relaunch it.
>
> The "Couldn't spawn the qmi-proxy" error is really weird; to me it
> doesn't look like a proxy crash. Did you check whether the proxy
> process still exists or not after this situation? The fact that the
> proxy doesn't reply and that further qmicli commands don't reply could
> actually mean the proxy is "stuck".
>
> > Here are the logs of it happening in one instance, below. Modem0
> reboots, CID allocation fails, I query the modem a few times with
> ['--wda-get-data-format'] and it times out (which is normal after it has
> rebooted - takes a while for it to be able to respond to this)
> > and suddenly all qmi commands start to fail. I notice around this time,
> just beforehand, modem commands start to time out in general. Previously to
> this I noticed that, for another modem, I had told it to reset via libqmi
> and it returns "successful", but the modem actually never resets. No matter
> how many times I run the command to do so.
>
> How are you running the reset command via QMI? Are you putting it
> first in "offline" before "reset"? Won't work otherwise.
>
> > Not the first time that has happened also.
> >
> > modem0: qmi_cmd: resp="error: couldn't create client for the 'wda'
> service: CID allocation failed in the CTL client: Transaction timed out\n"
> > modem0: qmi_cmd: ['--wda-get-data-format']
> > modem0: qmi_cmd: resp="error: couldn't open the QmiDevice: Transaction
> timed out\n"
> > modem0: qmi_cmd: ['--wda-get-data-format']
> > modem0: qmi_cmd: resp="error: couldn't open the QmiDevice: Transaction
> timed out\n"
> > modem0: qmi_cmd: ['--wda-get-data-format']
> > modem3: nas_get_serving_system: get_packet_service_status failed "error:
> couldn't open the QmiDevice: Transaction timed out\n"
> > modem2: nas_get_serving_system: get_packet_service_status failed "error:
> couldn't open the QmiDevice: Transaction timed out\n"
> > modem0: qmi_cmd: resp="error: couldn't open the QmiDevice: Transaction
> timed out\n"
> > modem0: qmi_cmd: ['--wda-get-data-format']
> > modem0: qmi_cmd: resp="error: couldn't open the QmiDevice: Couldn't
> spawn the qmi-proxy\n"
> >
>
> If you can somehow reproduce this issue easily, it may be a good idea
> to launch the qmi-proxy manually before any qmicli call happens, e..g:
> $ sudo /usr/libexec/qmi-proxy --verbose
>
> Or even under gdb, if that's something you can do.
>
> --
> Aleksander
> https://aleksander.es
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20200226/b7d5592f/attachment-0001.htm>


More information about the libqmi-devel mailing list