[Milhouse]

Top (and the improved version of it - htop) exist to get details on the CPU and its memory. Does something similar exist to detail the GPU's utilization along with the usage of its dedicated memory ?

You could try:

Code:

wget http://www.nmacleod.com/public/bcmstat.sh && chmod +x ./bcmstat.sh
./bcmstat.sh -x

It doesn't give you GPU utilisation as such (ie. 25% or what is using it), but you can see when it and the h264 block is being used (the latter should be off when not in use).

---

I have a 512MB board that does this. If I overclock core_freq by even 1 to 251, I can reproduce ext4 corruption first reboot every time. I have tried different SD cards and it still corrupts.

Just like me. I fixed it by changing the whole STORAGE partition to an USB pen instead and I didn't have a single problem after that.

Yes, but even when using USB it's quite likely you'll be left with an unbootable system if you experience these mmc0 errors when your Pi boots in order to apply a software update (updates to the SD-based kernel.img, bootcode.bin etc.). The only solution (other than avoiding/eliminating the mmc0 errors) is to move /storage to USB/NFS, and apply SD-card based updates manually using a PC (ie. disable auto-update, and never allow the Pi to write to the SD card, basically).

The annoying thing about the errors I am (and I'm sure many others are) experiencing is that the Pi is 100% stable in all other respects, it only experiences these partition and file corrupting mmc errors randomly once in 8 or 10 boots, which would suggest it's more a case of being a firmware issue than unstable hardware. Sadly once is enough to completely trash the installation.

That said, some Pi's are simply lemons when it comes to overclocking - I had one that also couldn't cope with a +1Mhz core overclock.

For those with stable Pis that experience occasional (but devastating) corruption when booting OpenELEC, I've put together an OpenELEC kernel that attempts to detect these boot-related mmc0 errors early in the boot sequence and force a reboot, if anyone wants to test it, it's here - just replace your normal kernel.img (take a backup first!)

To see more of what is going on you can add "nosplash debugging progress" to the end of your boot entry in cmdline.txt. If you want to access a debug shell (dmesg is included in this kernel, which can help determine the state of your SD card), append "break=all" and you will get a debug shell after each major step (in sequence: load_modules, check_disks, mount_flash, media_check, load_splash, mount_storage, check_update, prepare_sysroot). Type "exit" or hit ctrl-d to continue booting to the next break point (you can also break after a specific step, for example, "break=load_splash"). "media_check" is a new step in this kernel, which attempts to identify if the SD card is likely to encounter corruption and if so, it forces an unconditional reboot (it's a hack, but it seems to work for me and I can live with the occasional extra reboot rather than a system that requires rebuilding).