[Ovmsdev] Double updates - Normal?

Michael Balzer dexter at expeedo.de
Fri Jan 31 14:54:51 HKT 2020


Edge (3.2.008-275-g77e652af) on dexters-web now also has OVMS_HW_EVENT_QUEUE_SIZE 40.

Regards,
Michael


Am 31.01.20 um 01:15 schrieb Mark Webb-Johnson:
> I put some telemetry on this and see (for the first ten seconds of boot):
>
>     I (43) events: Initialising EVENTS (1200)
>     I (612) events: SignalEvent: event 'config.mounted' queued (0 waiting, 20 free)
>     I (682) ovms_main: Starting HOUSEKEEPING...
>     I (682) housekeeping: Initialising HOUSEKEEPING Framework...
>     I (842) events: SignalEvent: event 'housekeeping.init' queued (1 waiting, 19 free)
>     I (1022) housekeeping: Executing on CPU core 1
>     I (1022) housekeeping: reset_reason: cpu0=12, cpu1=12
>     I (1022) housekeeping: Initialising WATCHDOG...
>     I (1022) housekeeping: Starting PERIPHERALS...
>     I (1262) events: SignalEvent: event 'egpio.output.1.low' queued (1 waiting, 19 free)
>     I (1262) housekeeping: Auto init max7317 (free: 193092 bytes)
>     I (1272) housekeeping: Auto init ext12v (free: 193092 bytes)
>     I (1282) housekeeping: Auto init dbc (free: 193092 bytes)
>     I (1282) housekeeping: Auto init wifi (free: 193092 bytes)
>     I (1462) housekeeping: Auto init modem (free: 149952 bytes)
>     I (1472) housekeeping: Auto init vehicle (free: 149656 bytes)
>     I (1482) events: SignalEvent: event 'power.can1.on' queued (4 waiting, 16 free)
>     I (1492) events: SignalEvent: event 'egpio.output.2.low' queued (5 waiting, 15 free)
>     I (1502) housekeeping: Auto init obd2ecu (free: 141484 bytes)
>     I (1502) housekeeping: Auto init server v2 (free: 141484 bytes)
>     I (1512) housekeeping: Auto init server v3 (free: 141484 bytes)
>     I (1522) housekeeping: Auto init javascript (free: 141484 bytes)
>     I (1522) housekeeping: Auto init done (free: 141484 bytes)
>     I (1532) housekeeping: Starting USB console...
>     Firmware: 3.2.008-125-g1fca0362-dirty/factoents: 
>     SignalEvent: event 'system.start' queued (7 waiting, 13 free)
>     I (2022) events: SignalEvent: event 'ticker.1' queued (8 waiting, 12 free)
>     I (2202) simcom: State: Enter CheckPowerOff state
>     I (2202) events: SignalEvent: event 'egpio.output.3.low' queued (1 waiting, 19 free)
>     I (2202) events: SignalEvent: event 'egpio.output.0.low' queued (2 waiting, 18 free)
>     I (3022) events: SignalEvent: event 'ticker.1' queued (1 waiting, 19 free)
>     I (4022) events: SignalEvent: event 'ticker.1' queued (1 waiting, 19 free)
>     I (5022) events: SignalEvent: event 'ticker.1' queued (1 waiting, 19 free)
>     I (6022) events: SignalEvent: event 'ticker.1' queued (1 waiting, 19 free)
>     I (6022) sdcard: SD CARD has been inserted
>     I (6022) events: SignalEvent: event 'sd.insert' queued (1 waiting, 19 free)
>     I (7022) events: SignalEvent: event 'ticker.1' queued (1 waiting, 19 free)
>     I (8022) events: SignalEvent: event 'ticker.1' queued (1 waiting, 19 free)
>     I (8022) events: SignalEvent: event 'sd.mounted' queued (1 waiting, 19 free)
>     I (9022) events: SignalEvent: event 'ticker.1' queued (1 waiting, 19 free)
>     I (10022) events: SignalEvent: event 'ticker.1' queued (1 waiting, 19 free)
>     I (11022) events: SignalEvent: event 'ticker.1' queued (1 waiting, 19 free)
>     I (11022) events: SignalEvent: event 'ticker.10' queued (1 waiting, 19 free)
>
>
> (that doesn’t include scheduled events, only the ones from OvmsEvents::SignalEvent)
>
> I think the issue was most likely triggered by the egpio events introduced a while back. Agree with Thomas that this is most likely just a simple queue
> overflow. Perhaps EGPIO is flapping at startup, causing a flurry of these egpio events? I am guessing that this is aggravated in Greg’s case as he is doing
> some egpio and power work for HUD control.
>
> I’ve increased the OVMS_HW_EVENT_QUEUE_SIZE to 40 on my test build, and just released that to the production server (for edge). As this sdkconfig file is not
> included in github, I recommend all developers do the same for their local builds.
>
> @Michael can you set the same on your production build server?
>
> @Greg can you check your existing firmware boot (via usb) and check for 'queue overflow, event '%s’ dropped’ style messages on startup (probably around the
> time is says ’Starting USB console…’.
>
> @Greg please try the edge 3.2.008-126-g0291d03 firmware. Update to it, reboot, and see if ‘metric list version’ shows the version correctly. Hopefully this
> resolves (or works around) the issue.
>
> Regards, Mark.
>
>> On 30 Jan 2020, at 8:07 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>
>> Maybe OVMS_HW_EVENT_QUEUE_SIZE is just too small now, with the added events during boot and async event processing?
>>
>> Regards,
>> Michael
>>
>>
>> Am 30.01.20 um 13:00 schrieb Tamás Kovács:
>>> Some time the m.version not set on Mitsubishi i-Miev .
>>>
>>> 2020. január 30., csütörtök dátummal Thomas Heuer <egon at heuer-humfeld.de <mailto:egon at heuer-humfeld.de>> ezt írta:
>>>
>>>     The issue was on boot, the events: SignalEvent: queue overflow, event 'system.start' dropped in some case.
>>>
>>>      
>>>
>>>     the problem was the egpio settings in OvmsVehicleSmartED::ConfigChanged(OvmsConfigParam* param)
>>>
>>>      
>>>
>>>     https://github.com/Dimitrie78/Open-Vehicle-Monitoring-System-3/commit/21e1a0339c029adf5c746dfd6fecddbc9455a947#diff-9106f33dff1f6160884b2e78d145607fL155-L160
>>>     <https://github.com/Dimitrie78/Open-Vehicle-Monitoring-System-3/commit/21e1a0339c029adf5c746dfd6fecddbc9455a947#diff-9106f33dff1f6160884b2e78d145607fL155-L160>
>>>
>>>     line 155 – 160
>>>
>>>      
>>>
>>>     *Von:* OvmsDev <ovmsdev-bounces at lists.openvehicles.com <mailto:ovmsdev-bounces at lists.openvehicles.com>> *Im Auftrag von *Mark Webb-Johnson
>>>     *Gesendet:* Donnerstag, 30. Januar 2020 11:35
>>>     *An:* OVMS Developers <ovmsdev at lists.openvehicles.com <mailto:ovmsdev at lists.openvehicles.com>>
>>>     *Betreff:* Re: [Ovmsdev] Double updates - Normal?
>>>
>>>      
>>>
>>>     Just had a thought.
>>>
>>>      
>>>
>>>     Events used to be synchronous, but we switched to deliver in a different task. Maybe the startup sequence relies on that in some way.
>>>
>>>
>>>
>>>         On 30 Jan 2020, at 6:32 PM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>
>>>         
>>>
>>>         Seems identical. The changes don’t seem to affect the dispatch of the system.start event.
>>>
>>>          
>>>
>>>         I think it must be a race condition.
>>>
>>>          
>>>
>>>         Mark
>>>
>>>
>>>
>>>             On 30 Jan 2020, at 5:56 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>>
>>>             
>>>
>>>             Mark,
>>>
>>>             a similar issue was happening on some Smart ED and fixed by Dimitrie later on:
>>>
>>>             https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/293
>>>             <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/293>
>>>
>>>             I thought that was a Smart specific issue, maybe I was wrong.
>>>
>>>             Regards,
>>>             Michael
>>>
>>>
>>>             Am 30.01.20 um 06:17 schrieb Mark Webb-Johnson:
>>>
>>>                 Still stumped…
>>>
>>>                  
>>>
>>>                 The OTA code doesn’t call GetOVMSVersion(), but instead just looks at StandardMetrics.ms_m_version (which we know is blank). That is why
>>>                 this is happening.
>>>
>>>                  
>>>
>>>                 But why is StandardMetrics.ms_m_version empty (as is the hardware value as well).
>>>
>>>                  
>>>
>>>                 The ovms_version code hooks into ’system.start’ event, and sets the version and hardware metrics. So, obviously that is not being called.
>>>                 That event is raised just after ’Starting USB console…”. The event is also listened to be ovms_time, ovms_mdns, and swcan.
>>>
>>>                  
>>>
>>>                 MDNS outputs “Starting MDNS” when it sees that. The ovms_time sets the environment variable TZ. Your car is showing:
>>>
>>>                  
>>>
>>>                     ovms> time status
>>>
>>>                     ...
>>>
>>>                     Vehicle Response:
>>>
>>>                       Time Zone:  Not defined
>>>
>>>                       UTC Time:   2020-01-30 05:00:53 UTC
>>>
>>>                       Local Time: 2020-01-30 05:00:53 GMT
>>>
>>>                       Provider:   None
>>>
>>>                  
>>>
>>>                 So looks like TZ is not being set. Presumably that means the call is not happening. I had a look at the ovms_events code, but can’t find
>>>                 anything obvious.
>>>
>>>                  
>>>
>>>                 So, tried a hacky test:
>>>
>>>                  
>>>
>>>                     ovms> metric list version
>>>
>>>                     ...
>>>
>>>                     Vehicle Response:
>>>
>>>                       m.version
>>>
>>>                      
>>>
>>>                     ovms> event raise system.start
>>>
>>>                     ...
>>>
>>>                     Vehicle Response:
>>>
>>>                       Raising event: system.start
>>>
>>>                      
>>>
>>>                     ovms> metric list version
>>>
>>>                     ...
>>>
>>>                     Vehicle Response:
>>>
>>>                       m.version                                3.2.008-121-g4c6c9fe/ota_0/edge (build idf v3.3-beta3-775-gdc1ca69 Jan 29 2020 00:00:52)
>>>
>>>                      
>>>
>>>                     ovms> ota status
>>>
>>>                     ...
>>>
>>>                     Vehicle Response:
>>>
>>>                       Firmware:          3.2.008-121-g4c6c9fe/ota_0/edge (build idf v3.3-beta3-775-gdc1ca69 Jan 29 2020 00:00:52)
>>>
>>>                       Running partition: ota_0
>>>
>>>                       Boot partition:    ota_0
>>>
>>>                       Factory image:     3.1.001
>>>
>>>                       OTA_O image:       3.2.008-121-g4c6c9fe
>>>
>>>                       OTA_1 image:       3.2.008-121-g4c6c9fe
>>>
>>>                       Server Available:  3.2.008-121-g4c6c9fe (no update required)
>>>
>>>                  
>>>
>>>                 🤢
>>>
>>>                  
>>>
>>>                 Can you try to boot from USB (module reset) and provide the serial boot log? Particularly around the lines ’Starting USB console’.
>>>
>>>                  
>>>
>>>                 Maybe a race condition at startup, or some other issue delivering events early on?
>>>
>>>                  
>>>
>>>                 Only other thing I see are some scripts on /store/events regarding vehicle on/off - perhaps you can try disabling those to see if they
>>>                 trigger the issue? I tried recreating them on my box, but couldn’t repeat your problem.
>>>
>>>                  
>>>
>>>                 Regards, Mark.
>>>
>>>
>>>
>>>                     On 30 Jan 2020, at 11:55 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>>
>>>                      
>>>
>>>                     Greg,
>>>
>>>                      
>>>
>>>                     It seems your car can’t pickup currently running firmware version:
>>>
>>>                      
>>>
>>>                         ovms> open ROADSTER834B
>>>
>>>                         Connected and logged in to ROADSTER834B
>>>
>>>                         ovms> metric list version
>>>
>>>                         ...
>>>
>>>                         Vehicle Response:
>>>
>>>                           m.version
>>>
>>>                      
>>>
>>>                     By comparison, here’s mine:
>>>
>>>                      
>>>
>>>                         ovms> metric list version
>>>
>>>                         ...
>>>
>>>                         Vehicle Response:
>>>
>>>                           m.version                                3.2.008-121-g4c6c9fe/ota_1/edge (build idf v3.3-beta3-775-gdc1ca69 Jan 29 2020 00:00:52)
>>>
>>>                         ovms> ota status
>>>
>>>                         ...
>>>
>>>                         Vehicle Response:
>>>
>>>                           Firmware:          3.2.008-121-g4c6c9fe/ota_1/edge (build idf v3.3-beta3-775-gdc1ca69 Jan 29 2020 00:00:52)
>>>
>>>                           Running partition: ota_1
>>>
>>>                           Boot partition:    ota_1
>>>
>>>                           Factory image:     3.2.002
>>>
>>>                           OTA_O image:       3.2.008-120-gcfb7864
>>>
>>>                           OTA_1 image:       3.2.008-121-g4c6c9fe
>>>
>>>                      
>>>
>>>                     Your m.hardware metric is also blank.
>>>
>>>                      
>>>
>>>                     I’ll keep looking, but at the moment this seems bizarre.
>>>
>>>                      
>>>
>>>                     Regards, Mark.
>>>
>>>
>>>
>>>                         On 30 Jan 2020, at 11:21 AM, Greg D. <gregd2350 at gmail.com <mailto:gregd2350 at gmail.com>> wrote:
>>>
>>>                          
>>>
>>>                         Hi Mark, Michael,
>>>
>>>                         Seems like what is happening is that the module keeps thinking a new
>>>                         update is available.  Today was especially active for some reason.
>>>                         Screenshot of the Android application's log screen, attached.  All
>>>                         versions appear to be the same.  The car has simply been sitting in the
>>>                         garage on WiFi; no transitions of network access.
>>>
>>>                         Output of 'ota status' attached as well.
>>>
>>>                         Sorry, but I don't appear to have logging enabled. What specifically
>>>                         would you like logged?
>>>
>>>                         Greg
>>>
>>>
>>>                         Mark Webb-Johnson wrote:
>>>
>>>                             Not normal. Can you send us the logs. Also the output of ‘ota status’ would be helpful.
>>>
>>>                             Are you sure this isn't just a notification of the update, and is the update itself? Perhaps a screenshot of the double
>>>                             notifications you receive?
>>>
>>>                             Regards, Mark.
>>>
>>>
>>>                                 On 25 Jan 2020, at 11:35 AM, Greg D. <gregd2350 at gmail.com <mailto:gregd2350 at gmail.com>> wrote:
>>>
>>>                                 Hi folks,
>>>
>>>                                 I moved my car's OVMSv3 to the Edge firmware a bit ago, and notice that
>>>                                 every update seems to be doubled.  Besides being a bit annoying, it ends
>>>                                 up without a previous version to fall back to since both partitions end
>>>                                 up being the same.
>>>
>>>                                 Is this behavior normal?  Can it be prevented?
>>>
>>>                                 I'm only on Edge because of the bug in obd2ecu, and will probably move
>>>                                 to EAP after we get an EAP build with the fix in it.  Is the behavior
>>>                                 the same there?
>>>
>>>                                 I used to be on Main, and all seemed fine there.
>>>
>>>                                 Thanks,
>>>
>>>                                 Greg
>>>
>>>                                 _______________________________________________
>>>                                 OvmsDev mailing list
>>>                                 OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>                                 http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>>
>>>                             _______________________________________________
>>>                             OvmsDev mailing list
>>>                             OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>                             http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>>
>>>
>>>                         <Repeated updates.png><Repeated updates ota status output.txt>_______________________________________________
>>>                         OvmsDev mailing list
>>>                         OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>                         http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>>
>>>                      
>>>
>>>                  
>>>
>>>
>>>
>>>                 _______________________________________________
>>>
>>>                 OvmsDev mailing list
>>>
>>>                 OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>
>>>                 http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>>
>>>
>>>
>>>
>>>             -- 
>>>
>>>             Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
>>>
>>>             Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>
>>>             _______________________________________________
>>>             OvmsDev mailing list
>>>             OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>             http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>>
>>>         _______________________________________________
>>>         OvmsDev mailing list
>>>         OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>         http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>>
>>>
>>>
>>> -- 
>>> Üdvözlettel:
>>> Kovács Tamás
>>>
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200131/9c1e41e3/attachment.htm>


More information about the OvmsDev mailing list