write(9, "A", 1) = -1 EAGAIN

[Jean-Christian de Rivaz]

Hi Dan, thanks for your response.

Le 23. 09. 15 23:41, Dan Williams a écrit :
> On Wed, 2015-09-23 at 22:51 +0200, Jean-Christian de Rivaz wrote:
>> Hello,
>>
>> I use ModemManager 1.4.0 from Debian Jessie armhf on an embedded system
>> with a u-blox SARA-U270 modem over USB and the generic MM driver.
>> Sometimes MM fail to make the modem connected to the Internet because it
>> always get this:
>>
>> write(9, "A", 1) = -1 EAGAIN (Resource temporarily unavailable)
>>
>> Searching more on the system, I found the observations below:
>>
>> 1) This happens always when the modem try to connect. The registration
>> is not affected so far.
>>
>> 2) If it pass the connected state, the modem is not affected so far.
>>
>> 3) A tshark using usbmon show that the kernel don't send the expected
>> "A" char to the modem CDC.
>>
>> 4) The same tshark show that the modem still report +CIEV messages on
>> the same CDC.
>>
>> 5) Others CDC of the modem are still working well.
>>
>> 6) A restart of the ModemManager is enough to recover from this situation.
>>
>> 7) MM code have a kind of protection against this EAGIN in the form of
>> eagain_count:
>> http://cgit.freedesktop.org/ModemManager/ModemManager/tree/src/mm-port-serial.c#n593
> MM allows about 3 seconds of EAGAIN:
>
> http://cgit.freedesktop.org/ModemManager/ModemManager/tree/src/mm-port-serial.c#n187
>
> does the modem return this status code for more than 3 seconds?

Yes.

>    Maybe
> we need to bump that value up.

I use strace to capture all MM calls for more than 1 hour. Analyzing the 
resulting file show that absolutely all the write to this CDC, without 
any exception, returns EAGAIN. So I am afraid that bump up the timeout 
value will change nothing at all in this case.

What's probably need is to close and open the port again.

>   We may also need a custom plugin for
> your ublox device if it has specific needs for the serial port for flow
> control and the like.  That's quite variable for actual serial modems
> (eg, ones that aren't necessarily USB connected), and MM has logic to
> allow plugins to handle port characteristics.

I don't know if the SARA-U270 need any special care regarding flow control.

How can I get the flow control status of the port ? I played with stty 
command while MM was still running but this don't make any difference so 
far. Maybe I have to call stty before MM but this will require some 
hacking of the init system or udev rules. Or does the generic driver 
have any way to configure flow control ?

I have still no definitive prof that the problem is related to the flow 
control, it's only a possibility.

Best Regards,
Jean-Christian