<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Hey Girish,<br></div></div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I am on MM 1.14.2 running on a Cinterion PLS8x modem.[yocto<br>
distribution(thud) kernel 4.14]<br>
I use high level MM APIs in my code. On some SIMs the<br>
mm_modem_enable() (async version) times out because during the enable<br>
MM seems to be processing 160 odd SMS's .<br>
<br>
Two questions:<br>
1. mm_modem_enable() times out , I am guessing because of the flood of<br>
SMS coming in.<br>
But the modem state eventually moves to enabled. So the error is<br>
harmless in this case ?<br></blockquote><div><br></div><div><div style="font-family:monospace,monospace" class="gmail_default">Yes. The mm_modem_enable() timeout means *only* that you waited for 30s and you didn't get a reply. If you check the modem state after that time and eventually it moves to enabled, it means the enabling phase succeeded. But of course, the correct way to handle this would be to avoid having the timeout, which you can do by tweaking the default DBus timeout before calling mm_modem_enable(), e.g. as in this case to increase it to 120s:<br></div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">g_dbus_proxy_set_default_timeout (G_DBUS_PROXY (modem), 120000);</div><div style="font-family:monospace,monospace" class="gmail_default">mm_modem_enable (modem, ...);<br></div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">The default of 30s is just some sane value, but it's understandable that some operations may take longer. I believe it's the first time I see a timeout in the enabling phase though, usually this default proxy timeout is changed for very long async operations like the 3GPP network scan or the actual connection attempt.<br></div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. How can we suppress these SMS's ? I do see AT+CNMI , perhaps use<br>
these to suppress the URCs ?<br>
<br></blockquote><div><br></div><div><div style="font-family:monospace,monospace" class="gmail_default">My suggestion would be to read them all, and then, if they're not needed, remove them using the Messaging interface (each SMS is exposed as a DBus object). Also, the log shows that these are not URCs (modem indications), the long operation reading all SMS messages is actually the output of AT+CMGL=4.</div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">It is interesting, though, how long it takes to read and process each SMS message: 10s for reading and 40s for parsing and processing all 254 PDUs. That's a lot! I wonder if there's some part of the logic that is considerably slower than it should be.</div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">Anyway, if you don't want to keep all SMS messages around, it would be good to clean them up periodically.<br></div></div></div><br>-- <br><div dir="ltr" class="gmail_signature">Aleksander<br><a href="https://aleksander.es" target="_blank">https://aleksander.es</a></div></div>