[Ovmsdev] LoadProhibited exception on core 0
Soko
ovms at soko.cc
Wed Jul 5 14:57:16 HKT 2023
Hi,
That's exactly what I've figured out pulling an all-nighter. If I set
the IPv4-ACL "Deny UDP src=192.168.254.228:5353 dst=any" (.228 is the
OVMS) on the switch for the port my AP hits the network everything works
stable.
My Vehicle-ID on the Vehicle configuration page is "OVMS". So nothing
weird at all...
Is there a way to disable mDNS via the shell (I dont need it anyhow)?
With you suggesting doing a new build though I guess no?
Thanks, Soko
@Michael: thx for the tip
On 05.07.2023 01:39, Mark Webb-Johnson wrote:
> Not sure how reliable that short backtrack is, but here is what it shows:
>
> $ ../a2l ovms3.elf 0x4028128f 0x402823bf
> Using elf file: ovms3.elf
> 0x4028128f is in mdns_parse_packet
> (C:/Users/soko/Source/OVMS/home/soko/esp-idf/components/mdns/mdns.c:2839).
> 0x402823bf is in _mdns_service_task
> (C:/Users/soko/Source/OVMS/home/soko/esp-idf/components/mdns/mdns.c:3545).
> 3540in
> C:/Users/soko/Source/OVMS/home/soko/esp-idf/components/mdns/mdns.c
>
>
> So that implies a crash parsing a MDNS packet.
>
> If that is repeatable, it would be a bug in the ESP IDF for mdns. You
> could try disabling CONFIG_OVMS_COMP_MDNS in your build and see if
> that works around the issue. There is also CONFIG_MDNS_TASK_STACK_SIZE
> and CONFIG_MDNS_MAX_SERVICES which may be related. But that is based
> on the single backtrace, which may be wrong.
>
> The only other thing I can think of is the MDNS service packets we
> transmit. What is your vehicle ID? Anything unusual (non-ascii
> characters, long length, etc)?
>
> Regards, Mark
>
>> On 4 Jul 2023, at 6:10 PM, Soko <ovms at soko.cc> wrote:
>>
>> Hi Mark,
>>
>> I have the exact bin & elf I'm using (I've compiled it myself back in
>> the day...). I've also found the script you are mentioning, but it
>> seems to be a linux script, I'm on windows.
>> Looking at the script though - educated guessing - it just looks at
>> the address in the ELF file.
>> Opening the ELF file with an hex-editor in windows reveals it ends at
>> 0x0240D5DB.
>>
>> <vwPxeAnwFzenPgJR.png>
>>
>> Do I have to translate the address somehow? Or is the a2l script
>> doing more than just looking.
>>
>> I've also uploaded the bin & elf (http://soko.yourweb.de/ovms3.zip)
>> if you wonna have a quick look.
>>
>> The backtrace (0x4028128f 0x402823bf) is more or less the only
>> constant numbers I get with each crash. So if they are too short can
>> I add/activate some trace which leads to more info without connecting
>> to a laptop (my old devenv doesn't seem to work anymore, and it was
>> Windows anyhow...)
>>
>> thx
>> Soko
>>
>>
>> On 04.07.2023 03:01, Mark Webb-Johnson wrote:
>>> To understand what is going on, you’ll need to get the ELF file for
>>> the *exact* build of firmware you are using, and then use the
>>> support/a2l script to decode the backtrace addresses to something
>>> human readable. If you can’t do this, you could try by letting us
>>> know the firmware version you are running, where you got it from
>>> (API or Dexters), and provide the backtrace addresses. If you are
>>> using standard firmware builds, you can normally find the .elf file
>>> by simply change ovms3.bin to ovms3.elf in the download URL.
>>>
>>> Alternatively, connect the module over USB to a laptop/workstation
>>> running the development build environment and GDB stub running to
>>> capture the panic.
>>>
>>> The backtrace you show below (0x4028128f 0x402823bf) does not seem
>>> to be valid (too short), and probably won’t help much.
>>>
>>> Regards, Mark.
>>>
>>>> On 4 Jul 2023, at 5:41 AM, Soko <ovms at soko.cc> wrote:
>>>>
>>>> Hi guys,
>>>>
>>>> Running happily my OVMS on my VW e-Up since 2020 it drives my crazy
>>>> since today :(
>>>>
>>>> It restarts roughly every minute with this status afterwards:
>>>> ------------
>>>> Last boot was 28 second(s) ago
>>>> Time at boot: 2023-07-03 21:25:07 CEST
>>>> This is reset #1 since last power cycle
>>>> Detected boot reason: Crash (12/12)
>>>> Reset reason: Exception/panic (4)
>>>> Crash counters: 1 total, 0 early
>>>>
>>>> Last crash: LoadProhibited exception on core 0
>>>> Registers:
>>>> PC : 0x4028128f PS : 0x00060d30 A0 : 0x802823c2 A1 : 0x3ffe71d0
>>>> A2 : 0x3ffe9f9c A3 : 0x00000000 A4 : 0x00000000 A5 : 0x00000001
>>>> A6 : 0x3ffe9fe8 A7 : 0x3ffe71d0 A8 : 0x0000005b A9 : 0xffffffff
>>>> A10 : 0x00000e10 A11 : 0x0000000e A12 : 0x00000010 A13 : 0x3ffbd3ac
>>>> A14 : 0x3f84e83c A15 : 0x3ffbd46b SAR : 0x00000010 EXCCAUSE: 0x0000001c
>>>> EXCVADDR: 0x00000004 LBEG : 0x4008b0e9 LEND : 0x4008b11d LCOUNT :
>>>> 0x00000000
>>>> Backtrace:
>>>> 0x4028128f 0x402823bf
>>>> ------------
>>>>
>>>> And now the crazy part: It only happens when I'm connected to a
>>>> specific WiFi/network?!?!
>>>>
>>>> What I've tried so far:
>>>>
>>>> 1. Factory Reset (multiple times)
>>>> 2. Set a static IP address
>>>> 3. Reconnect all cables and make sure all are snug and tight
>>>> 4. Brought OVMS closer to the AP (only one, no mesh)
>>>> 5. Restarted AP
>>>> 6. Restarted DNS & DHCP Server
>>>> 7. It even happens when I have no vehicle selected after a factory
>>>> reset
>>>>
>>>> It gets more crazy: My WiFi is via Unifi/Ubiquity. So I can have
>>>> multiple SSIDs with the same AP. So all hardware involved is the
>>>> same...
>>>>
>>>> When I connect to SSID "E3200", which is network 192.168.254.0/24,
>>>> the exception happens every minute or so.
>>>> When I connect to SSID "SurfHere" which is network
>>>> 192.168.179.0/24, everything works fine!
>>>>
>>>> Do you guys have any idea why this is happening?
>>>>
>>>> I've tried to look at logs via Shell and "log level verbose" but
>>>> nothing shows up. Is there more I can activate to log this issue?
>>>>
>>>> Maybe my hardware is faulty... Where do I get a new OVMS here in
>>>> Europe/EU/Austria? Do I have to import in from the UK
>>>> (https://shop.openenergymonitor.com/ovms/)?
>>>>
>>>> thanks heaps in advance,
>>>> Soko
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> 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
>>
>> _______________________________________________
>> OvmsDev mailing list
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230705/b1a79925/attachment-0001.htm>
More information about the OvmsDev
mailing list