<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
OK, our esp-idf repository is now rolled back to the previous
commit.<br>
<br>
After pulling you may need to explicitly "git checkout master" --
verify you're on commit 812f959cec635cb7a849085bcc46711bd57ff0c9.<br>
<br>
You also will need to do a "git submodule update" afterwards.<br>
<br>
I've checked the esp-idf issues for a vfs_fat corruption thread, it
seems we're first. As it's not clear how to reproduce the bug (and
is it possibly our fault?), I hesitate opening an issue without
further details. I only have the mount failure code 13.<br>
<br>
The problem has now been reported by more users in the german forum,
but also without detail. One user booted into the old 3.1.009 main
release but also had the configuration erased on that boot, so it
seems the corruption happens already before reboot.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 22.08.2018 um 09:21 schrieb Michael
Balzer:<br>
</div>
<blockquote type="cite"
cite="mid:541599d8-be9b-6f50-d883-a49e79dc79ac@expeedo.de">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="moz-cite-prefix">I just wanted to report the same,
except on my unit it hasn't happened during flashing but on (I
assume) a reboot after a crash somewhere yesterday evening.<br>
<br>
I'll do the rollback on our esp-idf repository this evening.<br>
<br>
<br>
Am 22.08.2018 um 05:06 schrieb Mark Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:17EF7C98-FC18-40AB-935D-4657C510A997@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
I just updated my test box, and the same thing happened. It had
been rock-solid for months.
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class="">
<div class=""><font class="" face="Andale Mono"><span
style="font-size: 18px;" class="">I (562) ovms_main:
Mounting CONFIG...</span></font></div>
<div class=""><font class="" face="Andale Mono"><span
style="font-size: 18px;" class="">Initialising OVMS
CONFIG within STORE</span></font></div>
<div class=""><font class="" face="Andale Mono"><span
style="font-size: 18px;" class="">E (822) config:
Error: Cannot open config store directory</span></font></div>
</div>
</blockquote>
<div class="">
<div class=""><br class="">
</div>
<div class="">Downgraded to 3.1.009, but still can’t mount
store.</div>
<div class=""><br class="">
</div>
<div class="">I’m pretty sure there is something in the new
IDF that is corrupting FAT filesystems on flash.</div>
<div class=""><br class="">
</div>
<div class="">We need to roll-back. I’ve disabled nightly
builds until we can resolve this.</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">I wonder if
there could be a better strategy than immediately
formatting the config filesystem on a mount error. Is
there any chance the mount fails due to some race
condition, i.e. would it make sense to first retry
mounting after a short delay?</div>
</blockquote>
<br class="">
</div>
<div class="">I’m not seeing a reformat of the flash, just a
failure to mount. The reformat option is part of the fat
mount option. We can certainly turn it off, or delay/retry
it, but it is required for initial boot of a new device.</div>
</div>
</blockquote>
<br>
<blockquote type="cite"
cite="mid:17EF7C98-FC18-40AB-935D-4657C510A997@webb-johnson.net">
<div class="">
<div class="">Regards, Mark.<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 19 Aug 2018, at 7:23 PM, Michael Balzer
<<a href="mailto:dexter@expeedo.de" class=""
moz-do-not-send="true">dexter@expeedo.de</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="content-type" content="text/html;
charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> I've
pulled the latest esp-idf updates, merges, builds
and runs without issues. Btw, the idf now includes a
CAN driver, may be worth a look.<br class="">
<br class="">
On the second app-flashing, this happened:<br
class="">
<blockquote class=""><tt class="">…<br class="">
Wrote 2399584 bytes (1382879 compressed) at
0x00010000 in 26.1 seconds (effective 736.0
kbit/s)...</tt><br class="">
<tt class="">Hash of data verified.</tt><br
class="">
<br class="">
<tt class="">Leaving...</tt><br class="">
<tt class="">Hard resetting via RTS pin...</tt><br
class="">
<tt class="">…</tt><br class="">
<tt class="">I (452) ovms_main: Mounting CONFIG...</tt><br
class="">
<tt class="">W (722) vfs_fat_spiflash: f_mount
failed (13)</tt><br class="">
<tt class="">I (722) vfs_fat_spiflash: Formatting
FATFS partition, allocation unit size=4096</tt><br
class="">
<tt class="">I (1152) vfs_fat_spiflash: Mounting
again</tt><br class="">
<tt class="">Initialising OVMS CONFIG within STORE</tt><br
class="">
</blockquote>
:-(<br class="">
<br class="">
The first flash was perfectly OK and I haven't been
able to reproduce this afterwards.<br class="">
<br class="">
I don't think this is related to idf changes, as we
had some reports on lost configs before. Issue #145
also seems to be solved by the new idf, I had no
more crashes during reboots.<br class="">
<br class="">
I wonder if there could be a better strategy than
immediately formatting the config filesystem on a
mount error. Is there any chance the mount fails due
to some race condition, i.e. would it make sense to
first retry mounting after a short delay?<br
class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br
class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com"
class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="144">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<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>