On 10/26/2017 11:14 AM, Jonas Bonn wrote:
On 10/26/2017 11:04 AM, Jonas Bonn wrote:
> On 10/26/2017 10:55 AM, Jonas Bonn wrote:
>> On 10/26/2017 10:48 AM, Eswaran Vinothkumar (BEG/PJ-IOT-EL) wrote:
>>> May I know is there any config option to disable the signal handler
>>> in Ofono.
>> No, there's not... you need to hack it out of the code. Search for
>> the following line in src/main.c:
>> signal = setup_signalfd();
>> and comment it out. I think that's sufficient...
> Sorry, that was wrong. It's signal_setup() in src/log.c that needs
> to be adjusted. Just put a 'return' at the beginning of that
> function so that it becomes a no-op.
Here's a backtrace from the crasher that I'm seeing. I suspect it's
the same issue you have:
#0 0x00007ffa4c7a316e in g_queue_remove ()
#1 0x00005624b81441b9 in __qmi_device_discovery_complete
device=<optimized out>) at drivers/qmimodem/qmi.c:889
#2 0x00005624b8144d21 in handle_packet (buf=<optimized out>,
hdr=<optimized out>, device=0x5624b95bcc90) at
#3 received_data (user_data=0x5624b95bcc90, cond=<optimized out>,
channel=<optimized out>) at drivers/qmimodem/qmi.c:865
#4 0x00007ffa4c79168a in g_main_context_dispatch ()
#5 0x00007ffa4c791a40 in ?? () from
#6 0x00007ffa4c791d62 in g_main_loop_run ()
#7 0x00005624b8107e77 in main (argc=<optimized out>, argv=<optimized
Seems to be this:
i) When the modem is first powered on, service discovery takes some
time (more than 5 seconds)
ii) The service discovery timeout fires before the QMI request returns
so discover_reply gets called before discover_callback and things get
iii) Then the QMI request returns and discover_callback gets called
even though the request has timed out in ii)
...and this is where things go wrong because the userdata pointer to
discover_callback is probably no longer valid.
How do we handle the QMI request returning a _late_ response, i.e. after
it technically has timed out? I'll dig a bit more...
> ofono mailing list
ofono mailing list