[Milhouse]

Another test with #0524 - I played Sintel 720 for a few seconds, then Sintel 1080 three times for a few seconds each, and the GPU mem free (vcgencmd get_mem reloc) became an impossible 4091MB - bcmstat output. Unfortunately the system totally froze (network connection lost) and it required power cycling.

I now think that running bcmstat.sh is a crucial step required to trigger abnormal behaviour - it seems harder to cause abnormal behaviour when bcmstat is *not* running, although corruption still seems to be occurring as when not running bcmstat.sh, after playing Sintel 720/1080 a few times without any obvious error, trying to run "/usr/bin/vcgencmd get_mem reloc_total" produces the following error:

Code:

/usr/bin/vcgencmd: error while loading shared libraries: librt.so.1: failed to map segment from shared object

In fact, it's no longer possible to load any shared library on a system that is in this state:

Code:

rpi22:~ # journalctl --no-pager
journalctl: error while loading shared libraries: librt.so.1: failed to map segment from shared object
rpi22:~ # reboot
reboot: error while loading shared libraries: librt.so.1: failed to map segment from shared object
rpi22:~ # poweroff
poweroff: error while loading shared libraries: librt.so.1: failed to map segment from shared object

dmesg is clean.

As a minimal test, the following should be sufficient to see when memory corruption has occurred without running the whole bcmstat.sh:

Code:

while [ : ]; do echo "$(date): $(/usr/bin/vcgencmd get_mem reloc)"; sleep 1; done

While running the above code, play Sintel 720p and Sintel 1080 in sequence, for 10-20 seconds each, until the reported reloc amount becomes abnormal.