Anyway my last comment was a bit of a stretch. Seeing as this only effects
some boards, and not all. However it does strike me as odd that both of you
are having issues with the same kernel I'm running _right_now_. When it is
running rock solid so far for me.

Which leads me to believe that *something* on the rootfs is perhaps somehow
to blame. Either that, on something on these failing boards is somehow
slightly out of tolerance. I'll let this run a while longer just to make
sure before moving on to a Jessie image.

Do also keep in mind that while we do not own 100's of BBB's we do own 5,
and none of these have ever shutdown without a reason . . . 2 A5A's and 3
element14 REVC's

On Mon, Jul 13, 2015 at 10:38 PM, William Hermans <[email protected]> wrote:

> Could this possibly be related to how "clean" provided AC mains is ? I'm
> just curious, as we've never had any of these problems, but we're also
> completely off grid. Also for the record our power here is very stable and
> clean. No blips, spikes, or any abnormalities one might see being connected
> to grid power.
>
>
>
> On Mon, Jul 13, 2015 at 10:19 PM, William Hermans <[email protected]>
> wrote:
>
>> Still trucking along here:
>>
>> debian@beaglebone:~$ uname -a
>> Linux beaglebone 4.1.0-rc8-bone9 #1 Tue Jun 16 23:45:22 UTC 2015 armv7l
>> GNU/Linux
>> debian@beaglebone:~$ uptime
>>  22:18:07 up 1 day,  9:41,  1 user,  load average: 0.08, 0.03, 0.05
>>
>> By the way, I'm using default "ondemand" cpufreq governor
>>
>> On Mon, Jul 13, 2015 at 10:04 PM, 'dl4mea' via BeagleBoard <
>> [email protected]> wrote:
>>
>>> Results after two days overnight test:
>>>
>>> (1) System bb1cf1 got installed with 3.19.3-bone4: *still no reboot*
>>> uptime
>>>  04:19:11 up 1 day, 13:51,  2 users,  load average: 0.00, 0.01, 0.05
>>>
>>> (2) System bb6c1f: installed with 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8
>>> 17:03:29 UTC 2015 armv7l GNU/Linux: *2 reboots to a total of 4*
>>> Jul 13 00:55:17 bb6c1f kernel: [    0.000000] Booting Linux on physical
>>> CPU 0x0
>>> Jul 13 01:51:02 bb6c1f kernel: [    0.000000] Booting Linux on physical
>>> CPU 0x0
>>> Jul 13 21:46:08 rc6c1f kernel: [    0.000000] Booting Linux on physical
>>> CPU 0x0
>>> Jul 14 04:02:45 rc6c1f kernel: [    0.000000] Booting Linux on physical
>>> CPU 0x0
>>>
>>> (3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC
>>> 2015 armv7l GNU/Linux: but cpufreq-set -g performance: *rebooted 15:50*
>>> after around 20h uptime, before it had 6 reboots within 24h
>>>
>>> (4) some other systems ran with cpufreq-set -g performance, feeling is
>>> that the number of reboots decreased
>>>
>>> My conclusion:
>>>
>>>    - cpufreq-set -g performane seems to improve the situation, but does
>>>    not solve it.
>>>    - 3.19.3-bone4 is stable
>>>
>>> --- Guenter (dl4mea)
>>>
>>> --
>>> 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.
>>>
>>
>>
>

-- 
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.

Reply via email to