beagle bone black shuts down after 18 minutes

Hello, all,

I have a Beagle Bone Black rev C, running the latest machinekit distribution.
I have been logging in with ssh as I don’t have a micro-HDMI adapter cable
yet. Everything works fine for 18 minutes, then it powers down. just before
powering down, I see this message :
$ [ 426.564569] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)

Then, about a minute later it says :
Broadcast message from root@beaglebone (Mon May 19 16:19:26 2014):

The system is going down for system halt NOW!

the shutdown looks pretty normal until the end, where I see :
[ 1152.630360] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
Disabling swaps.
Detaching loop devices.
Detaching DM devices.
[ 1152.706640] (NULL device *): gadget not registered.
[ 1152.713833] musb-hdrc musb-hdrc.0.auto: remove, state 4
[ 1152.719488] usb usb2: USB disconnect, device number 1
[ 1152.725486] musb-hdrc musb-hdrc.0.auto: USB bus 2 deregistered
[ 1152.732434] Power down.
[ 1152.735088] System will go to power_off state in approx. 2 secs
[ 1152.743313] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
[ 1152.743313]
[ 1152.753043] [] (unwind_backtrace+0x1/0x98) from [] (panic+0x6b/0x168)
[ 1152.761696] [] (panic+0x6b/0x168) from [] (do_exit+0x5cb/0x64c)
[ 1152.769808] [] (do_exit+0x5cb/0x64c) from [] (sys_reboot+0xef/0x144)
[ 1152.778377] [] (sys_reboot+0xef/0x144) from [] (ret_fast_syscall+0x1/0x46)
[ 1152.787479] drm_kms_helper: panic occurred, switching back to text console

I have run e2fsck by plugging the SD card into a USB card reader on my desktop system,
it finds no errors.

Anybody know what is going on? I’m pretty baffled. This 18 minutes to power down
seems to be pretty repeatable.

Thanks,

Jon

Well, I’ve not experienced this issue personally. But just did a bit of googling / reading and the only thing I could find mentioned a read only file system having the journaling = true option set in fstab.

You can read the post I read here: http://www.raspberrypi.org/forums/viewtopic.php?t=51742&p=398987

I think it is safe to say that the system is intentionally shutting down. But of course why, we do not know yet. But pasting that error message into google and searching did turn up several hits referring to data corruption. Is it possible the image you downloaded is somehow corrupted ? I remember back several years ago when we used to be satellite internet, downloading files of this nature would get corrupted all the time.

Are you sure this wasn't labeled as a "flasher" image, 18 minutes is
about how long it takes to flash the eMMC with 1.7Gb of data.

Regards,

HMMMM, VERY interesting comment! Yes, it may have been set
up that way, and may be flashing the eMMC every time is starts
up. That would explain the extensive flickering of the user LEDs
when I don’t expect much to be happening.

Is there an easy way to check if this is a flasher setup?
How about a way to turn off the flasher process? Is it just a service
that is run out of /etc/init.d ?

What does the flasher do when it is done? Call for a shutdown?

Thanks,

Jon

Are you sure this wasn't labeled as a "flasher" image, 18 minutes is
about how long it takes to flash the eMMC with 1.7Gb of data.

HMMMM, VERY interesting comment! Yes, it may have been set
up that way, and may be flashing the eMMC every time is starts
up. That would explain the extensive flickering of the user LEDs
when I don't expect much to be happening.

Is there an easy way to check if this is a flasher setup?

It would have had "eMMC flasher" in it's name..

How about a way to turn off the flasher process? Is it just a service
that is run out of /etc/init.d ?

remove the file: (if it exists, it triggers the flashing procedure)

/boot/uboot/flash-eMMC.txt

Then reboot..

What does the flasher do when it is done? Call for a shutdown?

Correct.

Regards,

With the stock flasher images from RCN, you get a customized background
that indicates it's a flasher uSD. Since the Machinekit images use a
custom background image with a different name, they don't get changed
when building a flasher image, so it can be hard to tell.

To fix this (and other problems) I fixed the flasher scripts to run from
init (so you don't even get a desktop) and added a "cylon" pattern to
the LEDs so you know for sure the flasher script is running.

Of course, these changes are not in the April Machinekit flasher image
(these problems are what prompted me tweak things), so the best way to
tell is to run top and see if a bunch of rsync processes are chewing up
CPU and disk bandwidth.

The next set of Machinekit images will use the new flasher scripts, but
I've been holding off to try and get images based on the newly available
packages rather than the "build-from-source" that's been used up until now.

YES, this is it! I DID see three rsync processes running, and was wondering what
the heck they were! I was doing an apt-get install at the time, and wasn’t sure
that they couldn’t be part of that process, but didn’t think they would be.

So, the SD card you set up for me at the machinekit meeting does have the
flasher process running on it. And, I suspect that maybe Brad had the same
thing happen to him. I will try to disable it tonight and see if it fixes the
problem.

So, is anyone who downloaded the machinekit script in the last couple weeks
going to get the same problem?

Jon

so the best way to tell is to run top and see if a bunch of rsync
processes are chewing up CPU and disk bandwidth.

YES, this is it! I DID see three rsync processes running, and was
wondering what the heck they were! I was doing an apt-get install at
the time, and wasn't sure that they couldn't be part of that process,
but didn't think they would be.

Glad to hear that's all it was!

So, the SD card you set up for me at the machinekit meeting does have
the flasher process running on it. And, I suspect that maybe Brad
had the same thing happen to him. I will try to disable it tonight
and see if it fixes the problem.

I reviewed my console logs on the netbook, and I did program both the
plain and the eMMC flasher version to uSD while in Madison. I suspect I
simply got the cards confused. <blush>

So, is anyone who downloaded the machinekit script in the last couple
weeks going to get the same problem?

I don't think so, unless I messed up the images instead of just getting
confused about which uSD card was which at the meetup. I haven't heard
of anyone else having issues other than Brad, and I still think that
might have been an errant short (but analysis of the uSD card he was
running would show whether he's running the regular or flasher image).

OK, well I will check with him to see if that is the case. I’ll let
you know.

Jon

Robert, your diagnostic skills are truly AWESOME! I was pretty sure when you
mentioned the rsync running that this was the problem, but I have now deleted the
flash-eMMC.txt file, and the Bone has continued running for an hour. Thanks
so much for figuring this out so quickly!

Jon

Are you sure this wasn’t labeled as a “flasher” image, 18 minutes is
about how long it takes to flash the eMMC with 1.7Gb of data.

Robert, your diagnostic skills are truly AWESOME! I was pretty sure when you
mentioned the rsync running that this was the problem, but I have now deleted the
flash-eMMC.txt file, and the Bone has continued running for an hour. Thanks
so much for figuring this out so quickly!

(Ah, it was Charles who mentioned the rsync processes.)

...but it was Robert who pointed out that it might be an eMMC flasher
image. I totally missed that one, thanks for the help Robert!

Of course, on the next release round, Charles's cylon led's will make
the flashing process much more obvious. :wink:

Regards,