Volunteering to try this idea -
Scannerall used LICKS to prepare the card, and something was not right about partitioning.. I could try to re-create how he had it, testing using a build without low space protection. Could compare that to a 'clean' partitioning using Linux Method #2b, but also code without low space protection. Do partitioning differences expose something..?.. Also, the 'current' build has more free memory than the first one I tried. Perhaps using *that* version with low space proection disabled?
Thanks for the offer.
If the cause was running out of space, I wouldn't expect partitioning differences to matter much, but it's not totally out of the question. Same goes for free RAM. In either case, there may be an essentially random component like where a particular data structure ends up in RAM or something like that.
The best would be to use the exact same build and settings as scannerall did, but AFAIK we don't know the settings and I don't know if anyone has that specific build saved.
I'm not particularly convinced that running out of SD space was the cause of the problem, it would seem to require multiple unlikely failures in the canon firmware. As I've mentioned earlier, memory corruption due shooting DNG in a mode without valid raw (Digital IS or Low Light) is at least as likely a cause, and AFAIK no one has tested.
I'll PM you a build with both the free space and raw mode protection disabled. For the raw mode test, make sure DNG is enabled, and shoot in one of the "bad" modes (Digital IS or Low Light).
I would also like to repeat my request form a few posts ago that someone test zebra. I suspect this port suffers the same problem as the sx510 did. Since this involves memory corruption, this could also theoretically cause bricking. To test this, just enabled zebra and half press and check free memory repeatedly.
