<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    I've added a simple workaround for this issue to our esp-idf fork: <a
href="https://github.com/openvehicles/esp-idf/commit/9024cd38ecbc78a46ed16b79d63f57812e72b123">https://github.com/openvehicles/esp-idf/commit/9024cd38ecbc78a46ed16b79d63f57812e72b123</a><br>
    <br>
    The workaround checks if logging is done from the timer context, if
    so reduces the semaphore wait time to zero, thus avoiding blocking.<br>
    <br>
    That should eliminate any timer consistency issues arising from
    logging in timer callbacks. The disadvantage is a higher chance of
    such log messages getting dropped.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 05.11.19 um 21:45 schrieb Michael
      Balzer:<br>
    </div>
    <blockquote type="cite"
      cite="mid:6eac2ac1-4835-7a73-51f3-af003a43eae6@expeedo.de">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      Everyone,<br>
      <br>
      I've pushed the long due refactoring of the file logging into a
      dedicated task. This removes most of the delays involved in file
      logging, as the fsync() and log cycling now is done in the logging
      task and no longer blocks overall log message processing.<br>
      <br>
      I stumbled upon a bad thing (tm) though we need to resolve with
      logging: the esp-idf logging generally involves a semaphore wait
      of max 10 ms (!). I wasn't aware of this because I didn't look
      into the source before, there also is no warning about this in the
      esp-idf documentation (<a
href="https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/log.html"
        moz-do-not-send="true">https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/log.html</a>),
      so I guess I'm not the only one being taken by surprise here.<br>
      <br>
      <blockquote><tt>// Maximum time to wait for the mutex in a logging
          statement.</tt><br>
        <tt>#define <b>MAX_MUTEX_WAIT_MS 10</b></tt><br>
        <tt>#define MAX_MUTEX_WAIT_TICKS ((MAX_MUTEX_WAIT_MS +
          portTICK_PERIOD_MS - 1) / portTICK_PERIOD_MS)</tt><br>
        <tt>…</tt><br>
        <tt>void IRAM_ATTR <b>esp_log_write</b>(esp_log_level_t level,</tt><br>
        <tt>        const char* tag,</tt><br>
        <tt>        const char* format, ...)</tt><br>
        <tt>{</tt><br>
        <tt>    if (!s_log_mutex) {</tt><br>
        <tt>        s_log_mutex = xSemaphoreCreateMutex();</tt><br>
        <tt>    }</tt><br>
        <tt>    if (<b>xSemaphoreTake(s_log_mutex, MAX_MUTEX_WAIT_TICKS</b>)
          == pdFALSE) {</tt><br>
        <tt>        return;</tt><br>
        <tt>    }</tt><br>
        <tt>…</tt><br>
      </blockquote>
      <br>
      That semaphore is needed to secure the log level tag cache against
      parallel access, so it also affects log messages of currently
      disabled tags and/or levels.<br>
      <br>
      This means we <b>must not</b> use the standard logging from timer
      callbacks, at no verbosity level. But we do, partially caused by
      my own code serving as a bad example I assume -- sorry.<br>
      <br>
      But I've not only found direct log calls in most vehicle timer
      callbacks, there also are some hidden ones from calling the
      framework, for example marking a notification as read can produce
      a log output from Cleanup() if tracing is enabled.<br>
      <br>
      We need to change this short to mid term. This may be the cause of
      those strange timer overflow issues we've seen occasionally. It
      also means every debug or verbose log output currently in the code
      involves potentially multiple semaphore waits, that's for example
      the case for all hex dumps logged by the SIMCOM module.<br>
      <br>
      Our primary option is to remove all log calls from all low level
      framework functions and timer callbacks.<br>
      <br>
      A simple & quick workaround could be to extend the ESP_LOGx
      macros to check if they are executed in the timer task context, if
      so suppress the message or call the ESP_EARLY log function
      instead. That will hide these log messages from the logging
      framework though, if using the _EARLY_ variant they only will be
      sent to the USB port.<br>
      <br>
      For a better solution I thought about adding a dedicated queue
      & task for the initial log submission as well. That will need
      quite some rework to the esp-idf (no changes for this in the
      current master) but would allow to continue logging as we do now.
      Cons: queue submission involves some overhead & RAM, printf
      format expansion needs to be done before the tag/level check,
      messages may need to be dropped if the task starves or RAM gets
      tight, log output to consoles will depend on a task as well.<br>
      <br>
      Opinions / better ideas?<br>
      <br>
      Regards,<br>
      Michael<br>
      <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
  </body>
</html>