I just managed to cause the issue again by running: sudo du -s * while in the main directory of the SD card. So this seems to be connected to intensive SD card use.
Again, nothing in the logs that I could identify. Since the shutdown didn't work as expected I had to cut power. On Sunday, October 12, 2014 12:08:01 PM UTC+2, Sebastian H wrote: > > Early this morning I had this <http://pastebin.com/ekrc6eYt> in my > netconsole log. The Beagle was still up and running fine. I unmounted the > SD card and ran e2fsck -cvf /dev/mmcblk0p2 which didn't turn up any issues > <http://pastebin.com/anBuD6yU>. > > Any ideas what this is about? > > On Saturday, October 11, 2014 10:02:45 PM UTC+2, Sebastian H wrote: >> >> Hi, >> >> After working around the random reboot issue with kernel 3.14.19-ti-r28 >> by compiling the kernel without watchdog support (details here >> <https://groups.google.com/forum/embed/?place=forum%2Fbeagleboard&showsearch=true&showpopout=true&showtabs=true&hideforumtitle=true&parenturl=http%3A%2F%2Fbeagleboard.org%2FCommunity%2FForums&afterlogin=#!category-topic/beagleboard/beaglebone-black/vgeh336p0P4>), >> >> I ran into a different issue on my BBB (rev. A5C) today. From what I can >> tell, during my overnight backup last night, the SD card somehow locked up >> (with user led1 permanently lit) and any process that had tried to access >> the SD card was locked up as well. >> Trying to kill any of the hung processes with "sudo kill pid" wouldn't >> work in most cases and only resulted in an unkillable process, because >> after I did that, "sudo kill -9 pid" would be useless as well. So I killed >> most of the processes with kill -9, but I still ended up with a bunch >> completely hosed. >> >> The SD access was completely busted so not even a simple ls command >> worked anymore. That would just hang as well and I'd have to kill -9 it. >> >> The rest of the BBB was working just fine, as long as I didn't access the >> SD. The CPU was pretty much idle, except for postgresql process that tried >> to access the database that is also on the SD, but obviously couldn't >> anymore. >> >> I also discovered that my eMMC (from which I boot my Debian 7 while the >> SD card is used for storage), was almost out of space. That was mostly due >> to me installing a number of kernel versions over the last couple of days, >> which contributed to a shortage in space. Note that my tmp and log folder >> are on a USB drive and thus the system eMMC wasn't completely filled up and >> was still working. >> While I initially thought the low available memory to be the cause of the >> problem, and I certainly wish for that to be the answer, I fear it might be >> happening again. >> >> I do have netconsole logging running and of course, nothing was in the >> log. >> >> The SD card I use is a SanDisk Ultra 32GB Micro SDHC. >> >> So I'm wondering if you have any suggestions on what I can do to gather >> more information on the issue, should it arise again? Would I be able to do >> some sort of process dump, e.g. of the process handling the SD card? If so, >> could anyone point me to information on how that is done and what process I >> would have to run it on? I kind of guess that it might be the mmcqd/0 >> process? That's one I've seen causing an issue on the 3.8.13 kernel where >> it randomly froze up and I do recall that on these occasions, the usr LED1 >> also was always lit. My report of that issue (and the kernel panic details) >> can be found here <https://github.com/beagleboard/linux/issues/12>. >> >> I appreciate any pointers and assistance you can offer. >> >> Sebastian >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
