This board is also loading it’s rootfs via NFS, so it is constantly using the local network. SO, this has been an ongoing problem for you, and going on longer than a month ? Well All i can say is that you better get busy and finding your problem. I suggest you start from a scratch build, and incrementally install what you need one bit of software at a time until something starts misbehaving. This is very obviously a software issue, and despite what you say about having watchdog disabled I’m still of the opinion that this has to be watchdog related. Otherwise you’d be broadcasting a system wide kernel signal.
However my fix was based on the 3.2 kernel. I am not familiar with the kernels you are working with. And I don’t know if the USB-OTG is root cause in your case.
BBB and BBW have different PMIC designs. You could take a look at the schematic.
If you really want to isolate out the hardware, you can try to patch and build from 3.2 kernel to see if BBB still reboots. I have mulitple systems running for months and never had any random reboot issues.
I’m kind of a noob but willing to help investigate if needed.
I once had random reboots and traced it to an overheating problem. I don’t know if log files trap overheating messages or not. I had a blocked vent and once it was cleared, no probem.
On a second point, my BBB is stable running 3.14.17-ti-r15. If you make an image send it to me, I could load it on my side and see if it crashes or not. If it crashes, it sounds like software. If it does not crash, it could be hardware (QA?) or environment related (EM?). - As I said, I am a noob, so perhaps this could be a waste of your time.
I have used several Bone Blacks in projects. One of them ran for about 3 months without reboot. Due to some other
software I am using, I used the machinekit distribution (which is based on the esteemed Robert Nelson distro, but
has Xenomai RT extensions on the kernel.) So, you might try out the machinekit distro and see if this problem
goes away.
Had a minute or two to try machinekit, loaded onto uSD. Unfortunately, it’s based on 3.8.x which doesn’t support USB Hotplug so a non-starter. Also, it froze after about 3 hours so I just shut it down for now.
There's no need to pull in wicd to solve this; all you need to do is to
replace "auto eth0" with "allow-hotplug eth0" (not both) in
"/etc/network/interfaces". This gives you eth0 at boot if it's plugged in
but it doesn't wait if it's not, and if you plug it in later it comes right
up. Oddly it doesn't even wait very long if it's plugged in at start-up
and there is no dhcp being offered. (all of this is assuming "iface eth0
inet dhcp" is in there too; I imagine a static route comes up right away
regardless.)
There's no need to pull in wicd to solve this; all you need to do is to
replace "auto eth0" with "allow-hotplug eth0" (not both) in
"/etc/network/interfaces". This gives you eth0 at boot if it's plugged in
but it doesn't wait if it's not, and if you plug it in later it comes right
up. Oddly it doesn't even wait very long if it's plugged in at start-up and
there is no dhcp being offered. (all of this is assuming "iface eth0 inet
dhcp" is in there too; I imagine a static route comes up right away
regardless.)
Every time I've tried just "allow-hotplug eth0" i get random
no-connections when the eth0 is plugged in..
For jessie, I've been using connman + cmst (gui for wifi users) and so
far it's been a lot smother then wicd in wheezy..
This is not what allow-hotplug means. It refers to an ethernet interface such
as a USB device being plugged in. In order to get the behaviour you want
you need ifplugd. To quote from the package description:-
Description-en: configuration daemon for ethernet devices
ifplugd is a daemon which will automatically configure your ethernet device
when a cable is plugged in and automatically de-configure it if the cable is
pulled out. This is useful on laptops with onboard network adapters, since it
will only configure the interface when a cable is really connected.
I just ripped connman and the desktop out of that image. I haven't had
a problem with it failing to connect when plugging into my desktop (ubuntu
14.04) but maybe that's because I've set up my Network Manager to not
automatically connect, so as soon as I plug in the beagle I have to go to
the drop down menu (NM) and activate the connection. I'll change that to
auto and see if I have problems.
Okay, (@Robert) I can confirm that it is not reliable when I am not manually initiating the dhcp from my desktop. Also (@David) the beagle does not automatically remove the connection when I disconnect the ethernet, and so I have to manually remove the no longer valid default route. This is probably where ifplugd would make life easier.
OK I did two things at once which from my old Beta Tester days is a no-no since you can’t figure out which change made a difference. But…
I updated the kernel to 3.14.23-ti-r34
Then I did an apt-get update/upgrade and I noticed that dbus got upgraded in the process.
Now when I hot plug a USB stick into my external 7 port hub it comes right up. Before, it wouldn’t get recognized unless I had a ‘constantly on’ device also plugged into the hub (like a printer), so dbus upgrade ‘fixed’ something regarding that issue
The really good news is I’ve been up for two days with no random reboots. New kernel or dbus? Don’t know, don’t care, as long as the reboot monster has been banished into the deep dark pit.
Welcome to the wonderful world of Linux. This is how it used to be for ANYTHING new to Debian, back in the day. This is why ppl such as myself will often tell you research your hardware before you install debian on it. Or more correctly. By hardware that has known debian support.
Now days, this seems to be less of a problem, and you can very easily exchange “debian” for “Linux” in general. But the general idea of “researching” whatever you do, before you do it still stands. I even do this with Windows in mind, and windows has far better driver support compared to ANY OS out there. Period.
I just had a strange incident in which a USB-connected device entirely lost
power on the BBB rev.C. Otherwise the BBB continued operating normally.
I'm on a 6A power supply, with the software that shipped with the BBB.
Might this be related to these fixes? Is there anything else on the software
side that might shut down power to the USB port?
@William: you speak as if I was a newcomer to Linux. Truth is, I was one of the first to embrace Linux back in the 80s when I worked in Computer Services at the local University. I replaced several Windoze servers with Linux Servers and built Linux-based ‘internet appliances’ as we called them back then. I’ve probably forgotten more than most younger folks have figured out yet. So, please save your ‘lecturing’ for another time and place and let all of us here who are obviously less enlightened than yourself continue to figure out the reboot issue. Sharing our experiences (even if they are silly noob mistakes) all has merit in forming a picture of the issue that we as a group can evaluate and perhaps discover a solution. That’s one of the great things about discussion forums such as this.
Isn't "Windoze" a trademarked feature of "Micro$oft Windows"? Windows
detects user load, thus artificially slowing down basic tasks to reset
user user experience, unless customer loads up amazon.com and searches
for cpu/memory upgrade.
Robert, heh yeah I do not know about that, but what would that say about Linux considering at least around 2011 Microsoft was something like the 17th top code contributor for Linux . . . maybe they’re trying to slow things down ? hehehe
Honestly there is nothing wrong with any OS, only the users using them. Mostly. WinME was pretty bad . . .
I haven't had