Beaglebone Black Rebooting Several Times Every Day

[Greg Kelley]

Got my first BBB last week, installed latest Debian. USB Hot Plug was completely hosed in Kernel 3.8 so I upgraded to 3.16 (latest non-rc version). Currently running CUPS print services (including Airprint) and weewx. It appears that the BBB is rebooting three or four times between 10pm and 1am, this has happened the last two days. I discovered it because weewx was going into an ftp loop because the system clock time was getting whacked (it is time/date sensitive to process weather data). Nothing in the log files unusual. Powered with a 5v 2a supply. Ethernet cable attached and external USB Hub (has external power but not used) with printer (turned off) and Weather Data Logger attached (has it's own power).

Before I start experimenting with removing USB Hub, plugging in just Weather Data Logger, etc. thought I'd check here first.

[Michaël Vaes]

Hi Greg -

Are you booting from your SD Card or have it inserted?

Michaël

[David Lambert]

If you have a serial interface, I suggest turn on logging and post the results here.

On 09/02/2014 06:44 AM, Greg Kelley wrote:

Got my first BBB last week, installed latest Debian. USB Hot Plug was completely hosed in Kernel 3.8 so I upgraded to 3.16 (latest non-rc version). Currently running CUPS print services (including Airprint) and weewx. It appears that the BBB is rebooting three or four times between 10pm and 1am, this has happened the last two days. I discovered it because weewx was going into an ftp loop because the system clock time was getting whacked (it is time/date sensitive to process weather data). Nothing in the log files unusual. Powered with a 5v 2a supply. Ethernet cable attached and external USB Hub (has external power but not used) with printer (turned off) and Weather Data Logger attached (has it's own power).

Before I start experimenting with removing USB Hub, plugging in just Weather Data Logger, etc. thought I'd check here first.

--
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 beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michaël Vaes]

When the SD card is inserted it automatically boots from there. Have a look if there is a file called 'eMMC-flasher.txt' in the root of your SD card it will start flashing on each reboot and reboots again.

If that doesn't solve it I would suggest overwrite the following commands with a bash script that logs the output of a PSTREE to a logfile.
- halt
- shutdown
- reboot

That will allow you to see what is triggering it.

Michaël

[Greg Kelley]

I am booting straight from eMMC that I flashed, no uSD and no serial interface. I have disabled cups and weewx from starting and removed the external USB HUB and changed the power supply to another 5v 2a. I can tell it has rebooted by looking at syslog for ntpdate 'step time server' events. My syslog resets daily at 6am, so looking at syslog1 it rebooted 10 times in last 24hrs. This is not a shutdown or reboot it is a system reset. Since I have removed all external attachments and USB is idle, I have to assume it's either a board hardware issue or the 3.16 kernel as reboot times are random and I don't have anything in cron.hourly. In 3.16 leds have been renamed to heartbeat, mmc0, usr2, usr3. I have heartbeat turned off. PSTREE not installed and apparently not a .deb dist either.

[Greg Kelley]

I have downgraded the kernel from 3.16.0-bone2 to 3.15.10-bone8 and so far no reboots in the last 3 hours. If I get a full 24 hr cycle without reboots, I'll blame it on 3.16.0 and try to re-attach ext USB HUB, weather data logger, printer, and enable cups and weewx and see how far I get this time.

[Robert Nelson]

Thanks for the report, please let us know how v3.15.x react's too..
I'm currently chasing a few other issues with v3.16.x (acpi isn't
working)

btw, if you want something that's going to be a lot more
supported/tested down the road.

sudo apt-get update
sudo apt-get install linux-image-3.14.17-ti-r15

We are preping for a big transition.
http://elinux.org/Beagleboard:Capes_3.8_to_3.14

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[PLyttle]

Maybe check your power plug. There are many plugs that fit the socket on a BBB, but some do not provide a reliable connection. The one you should be using is having a spring-loaded central socket - see picture

LP

[Greg Kelley]

Plug on both power supplies is correct size and fit nice and snug.

[Greg Kelley]

Instead of rebooting 10 to 12 times it only rebooted 3 times in syslog, at 6:24pm and 11:06pm and 12:03am. Still random reboots though with nothing in USB and sitting idle. Not so sure it's a kernel issue at this point, could be hardware related but willing to try another kernel to see what happens.

[Maxim Podbereznyy]

power the board by USB, remove the wall adapter and test again. This issue was described long ago but there was the kernel 3.2. The issue disappeared with the 3.8

2014-09-04 14:45 GMT+04:00 Greg Kelley <suekk...@gmail.com>:

Instead of rebooting 10 to 12 times it only rebooted 3 times in syslog, at 6:24pm and 11:06pm and 12:03am. Still random reboots though with nothing in USB and sitting idle. Not so sure it's a kernel issue at this point, could be hardware related but willing to try another kernel to see what happens.

--

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 beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

LinkedIn - http://www.linkedin.com/in/maximpodbereznyy

Company - http://www.linkedin.com/company/mentorel

Facebook - https://www.facebook.com/mentorel.company

[Greg Kelley]

I just downgraded to 3.14.17-bone8 so let's see how that works. Will watch syslog for 24 hrs and see if it reboots.

[Greg Kelley]

Thanks for the suggestion, if I get reboots with 3.14.17 I'll try the usb power and if that doesn't work I'll go back to 3.8 although I had USB hot plug issues with that version.

[Greg Kelley]

BBB ran for 6 hours and just rebooted at 12:30pm so I now have it powered through the USB port with a 5v1a power supply instead of through the main power plug. If this reboots my last attempt will be to downgrade back to 3.8 and if it still reboots I'll have to send it back. It's an element14 purchased from an online vendor.

[Greg Kelley]

Well it just ran for about 15 minutes and rebooted using USB power, so I'm going to reflash eMMC with original distro and try that then return if it reboots again. Will get a BBB from Adafruit although the vendor has offered to send another element14 replacement.

[Robert Nelson]

On Thu, Sep 4, 2014 at 1:26 PM, Greg Kelley <suekk...@gmail.com> wrote:
> Well it just ran for about 15 minutes and rebooted using USB power, so I'm
> going to reflash eMMC with original distro and try that then return if it
> reboots again. Will get a BBB from Adafruit although the vendor has offered
> to send another element14 replacement.

Greg, please give this image a shot.

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-09-03

It includes all the "3.8" kernel fixes since the May release came out..

[Greg Kelley]

Hi Robert, I reflashed the original distro and it ran for about a half hour and rebooted so I have determined it is a hardware issue, (probably a grounding problem according to the vendor so perhaps there is a QC issue at element14) so I have returned the element14 BBB to the vendor for a refund and ordered a CircuitCo BBB from Adafruit. Will arrive Monday so will have it up and running on Tuesday. I plan to upgrade the kernel to 3.14.17-bone8 which is close to what you recommended for stability and long term support. I can give the 2014-09-13 image a try before kernel upgrade if you need me to test but it will be on a new BBB and not the 'problem child'. Thanks for all you hard work, makes maintaining a BBB pretty painless.

[Greg Kelley]

Robert, I just looked at the kernel in this image (3.8.13-bone64) and that was the first image I flashed after receiving the BBB. I had USB hot plug issues with that kernel version so I upgraded to 3.16.0. It would not recognize an external USB Hub plugged in after startup, only when plugged in at power up and would not recognize any USB devices hot plugged into the Hub. Not a problem with 3.14, 3.15, 3.16 when I was testing.

On Thursday, September 4, 2014 2:28:58 PM UTC-4, RobertCNelson wrote:

[Greg Kelley]

Update: I received my new BBB - a CurcuitCo version from Adafruit on Tuesday. On Wednesday I got it set up almost identical to the other one I sent back. It has 3.14.17-bone8 kernel. It rebooted/reset on Thursday at 2:15am and the physical ethernet port was down, so I had to connect via the USB port to look at syslog and see what happened. There is no entry for reboot or shutdown so it looks like a complete reset is taking place. Logs show ethernet port not coming up and dhcpclient says network unreachable

I did a power down and restart and it ran fine until Friday morning and reset twice at 7:35am and almost immediately again at 7:50am. Both times it looks like during the boot sequence that network services are starting after ntpd as ntpd can't resolve hosts. dhcpclient can't find the network and retries about a half dozen times then the ethernet port finally comes up and it's back online. This is physically plugged into the same hub that my RasPi is plugged into (and has been running non-stop for over two weeks now, no issues with it whatsoever).

I certainly can't use this BBB as a print and weather data server with it behaving this way so I'll keep these running on the RasPi until I can figure out why this is resetting constantly. Using a 5v 2a power supply and I've tried two different ones with the other BBB so I don't think it's a PS issue, but that doesn't leave much else to blame for random resets.

Ideas and suggestions welcome.

[Robert Nelson]

On Fri, Sep 12, 2014 at 8:37 AM, Greg Kelley <suekk...@gmail.com> wrote:
> Update: I received my new BBB - a CurcuitCo version from Adafruit on
> Tuesday. On Wednesday I got it set up almost identical to the other one I
> sent back. It has 3.14.17-bone8 kernel. It rebooted/reset on Thursday at
> 2:15am and the physical ethernet port was down, so I had to connect via the
> USB port to look at syslog and see what happened. There is no entry for
> reboot or shutdown so it looks like a complete reset is taking place. Logs
> show ethernet port not coming up and dhcpclient says network unreachable

I know it's a little intrussive, but can you do me a favor... Have
another machine log the debug serial port... Then we can see what's
going on..

BTW, that "3.14.x" isn't being worked on... If you have a new "testnig" image:

sudo apt-get update
sudo apt-get install linux-image-3.14.17-ti-r19

[Greg Kelley]

Hi Robert, I just checked around and a Debug Cable (34M8872 FTDI TTL-232R-3V3) is $42 on eBay. I don't mind spending some time troubleshooting this but not willing to go out and invest in pieces and parts. I do have two Serial to USB cables to connect to some HAM Radio gear, but not the right header connectors.

I'll upgrade to the latest 3.14 image too.

[Robert Nelson]

On Fri, Sep 12, 2014 at 10:43 AM, Greg Kelley <suekk...@gmail.com> wrote:
> Hi Robert, I just checked around and a Debug Cable (34M8872 FTDI
> TTL-232R-3V3) is $42 on eBay. I don't mind spending some time
> troubleshooting this but not willing to go out and invest in pieces and
> parts. I do have two Serial to USB cables to connect to some HAM Radio gear,
> but not the right header connectors.

Wow, they go for a premium on ebay..

http://www.digikey.com/product-detail/en/TTL-232R-3V3/768-1015-ND/1836393

>
> I'll upgrade to the latest 3.14 image too.

Try that newer 3.14 for a few days first.

[Greg Kelley]

Robert, apt-get couldn't find linux-image-3.14.17-ti-r19, will go check on your site and get install-me.sh

[Robert Nelson]

On Fri, Sep 12, 2014 at 10:49 AM, Greg Kelley <suekk...@gmail.com> wrote:
> Robert, apt-get couldn't find linux-image-3.14.17-ti-r19, will go check on
> your site and get install-me.sh

The repo wasn't added till mid july:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots

in your case, you can also do:

cd /opt/scripts/tools/
git pull

sudo ./update_kernel.sh --ti-kernel

[Greg Kelley]

Robert,

I think part of the reason ntp and dhcpclient aren't getting network connections at boot is because they are set at S03 in init and wicd is set at S06 and is last to get going. It appears that eth0 is not coming up until wicd loads?

Also, the install-me.sh failed at the end with final zImage copy because it creates backups of everything and /boot (92Mb) runs out of space. I had to manually remove previous image files from /boot and /boot/uboot then run the script so it had room to install everything. Seems /boot partition is too small.

[Robert Nelson]

On Fri, Sep 12, 2014 at 11:27 AM, Greg Kelley <suekk...@gmail.com> wrote:
> Robert,
>
> I think part of the reason ntp and dhcpclient aren't getting network
> connections at boot is because they are set at S03 in init and wicd is set
> at S06 and is last to get going. It appears that eth0 is not coming up until
> wicd loads?

Correct, wicd set's up eth0, that's how we got the 11-12 second bootup
time. Otherwise if eth0 is handled by /etc/network/interfaces bootup
could last 2 minutes for users who don't connect eth0. I should
atleast really move ntp from S03 to S06..

> Also, the install-me.sh failed at the end with final zImage copy because it
> creates backups of everything and /boot (92Mb) runs out of space. I had to
> manually remove previous image files from /boot and /boot/uboot then run the
> script so it had room to install everything. Seems /boot partition is too
> small.

Yeah it runs out of space fast.

That's one of the reasons we moved all the boot files out of the 96Mb
boot partition..

You can see the high level details (1) what i did (first implemented
in the july testing image (2))

Basicly, all the kernel/modules/dtbs are now in the big ext4 partition...

1: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

2: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots

[Greg Kelley]

Robert,

I discovered the /etc/network/interfaces issue snooping around and just set eth0 to auto load there and my total boot time is now 7s instead of 12s with all the ntp and dhcpclient retries gone.

So I guess if using the install-me script, I'll have to manually remove the previous kernel files in /boot and /boot/uboot before running it so there's room. Does the .deb file install (apt-get install) also do backups? If so, it should fail as well. Looks like about 110Mb for /boot partition should be enough to hold current and backups of previous.

I'm getting a ton of these in syslog at boot:

kernel: [   xx.xxxxxx] unwind: Index not found bf0f4334

Also, I noticed that in a reboot it keeps the current time for all syslog boot messages, so I know it's getting a full reset randomly because the time in syslog is from /etc/timestamp (which I update every 15 minutes so I can tell when it's resetting).

[Robert Nelson]

On Fri, Sep 12, 2014 at 12:08 PM, Greg Kelley <suekk...@gmail.com> wrote:
> Robert,
>
> I discovered the /etc/network/interfaces issue snooping around and just set
> eth0 to auto load there and my total boot time is now 7s instead of 12s with
> all the ntp and dhcpclient retries gone.
>
> So I guess if using the install-me script, I'll have to manually remove the
> previous kernel files in /boot and /boot/uboot before running it so there's
> room. Does the .deb file install (apt-get install) also do backups? If so,
> it should fail as well. Looks like about 110Mb for /boot partition should be
> enough to hold current and backups of previous.

With the new "apt-get install linux-image-xyz" partition setup

each "linux-image-xyz" has it's own set of:

/boot/vmlinuz-xyz
/boot/initrd.img-xyz
/boot/dtbs/xyz/*.dtb

You can switch between different kernels by updating (uname_r) in:

/boot/uEnv.txt

(all located in ext4, so it'll take a while to run out of space)

> I'm getting a ton of these in syslog at boot:
>
> kernel: [ xx.xxxxxx] unwind: Index not found bf0f4334

Yeap, unwind isn't setup yet.. The 3.14 is wip in progress, but it's
more reliable then v3.8.x for me..

> Also, I noticed that in a reboot it keeps the current time for all syslog
> boot messages, so I know it's getting a full reset randomly because the time
> in syslog is from /etc/timestamp (which I update every 15 minutes so I can
> tell when it's resetting).

[Greg Kelley]

Robert,

I just made a note to myself to comment out the backup commands in your install-me script file (so that should leave enough space in uboot) before I run it.

[Robert Nelson]

On Fri, Sep 12, 2014 at 1:37 PM, Greg Kelley <suekk...@gmail.com> wrote:
> Robert,
>
> I just made a note to myself to comment out the backup commands in your
> install-me script file (so that should leave enough space in uboot) before I
> run it.

With the direction we are heading, those install-me.sh's are becoming
obsolete.. ;)

[Greg Kelley]

Makes sense, but if apt-get doesn't work it's a good fall-back for now.

I guess if I get more random resets, I'll have to spring for that serial debug cable @ $23 shipped from DigiKey.

[William Hermans]

If you've got an MSP430 launchpad laying around, you could use that too ( for serial debug ). But you'll have to make / use 3 jumpers, and baud rate is limited to 9600bps ( msp430 side ).

--

[Przemek Klosowski]

On Fri, Sep 12, 2014 at 7:29 PM, William Hermans <yyr...@gmail.com> wrote:
> If you've got an MSP430 launchpad laying around, you could use that too (
> for serial debug ). But you'll have to make / use 3 jumpers, and baud rate
> is limited to 9600bps ( msp430 side ).

Do you mind saying how you'd use it for serial debug? does it have a
USB-serial passthrough burned in, or are you saying that it could be
programmed to bridge serial <-> USB?

[William Hermans]

It can be setup as a Serial pass through / Bridge. No programming required.

http://forum.beaglefu.com/topic/92-msp430-launchpad-v15-serial-debug/

[Greg Kelley]

Update: I installed 3.14.17-ti-r19 yesterday about 3pm and set eth0 to auto so it comes up earlier than wicp. Ran fine until 7:13am this morning then did it's usual reset thing. Very frustrating. Guess I'll have to spring for that cable.

On Friday, September 12, 2014 9:55:47 AM UTC-4, RobertCNelson wrote:

[Greg Kelley]

Update: the BBB just reset again at 7:49am. That's interesting, because it reset twice yesterday at almost the same times 7:35am and 8:13am and today at 7:13am and 7:49am. cron daily runs at 6:25am and I have no ctontab jobs at those times. Appears to be some sort of pattern due to the daily reset times being so close, but there is nothing is syslog except cron.hourly until the new boot sequence starts.

[Greg Kelley]

Update: I got a third reset yesterday at 11:53pm but no resets this morning between 7am and 8am. The only log file entry I could find that matched a reset was in wtmp: Sat Sep 13 07:13 - crash (-5369+-11:-  and there are a half dozen other 'crash' entries in the log as well.

[Maxim Podbereznyy]

Why don't you share the crash log?

14 Сен 2014 г. 18:31 пользователь "Greg Kelley" <suekk...@gmail.com> написал:

Update: I got a third reset yesterday at 11:53pm but no resets this morning between 7am and 8am. The only log file entry I could find that matched a reset was in wtmp: Sat Sep 13 07:13 - crash (-5369+-11:-  and there are a half dozen other 'crash' entries in the log as well.

On Saturday, September 13, 2014 8:14:05 AM UTC-4, Greg Kelley wrote:

Update: the BBB just reset again at 7:49am. That's interesting, because it reset twice yesterday at almost the same times 7:35am and 8:13am and today at 7:13am and 7:49am. cron daily runs at 6:25am and I have no ctontab jobs at those times. Appears to be some sort of pattern due to the daily reset times being so close, but there is nothing is syslog except cron.hourly until the new boot sequence starts.

[Greg Kelley]

Another reset early this afternoon, so I have shutdown and removed the 5v2a cheapo PS and replaced it with a Garmin 5v1a PS I have that uses the mini USB instead of the banana plug. I want to eliminate the current PS as the problem. All my PS are in two power strips plugged into an APC Battery Backup so power is conditioned, filtered, and constant.

I'm spending waaayyyy too much time with this since my RasPi has been set up same way and running 24/7 since I plugged it in with zero issues.

Am I the only one with constant resets on a BBB?

I'm hesitant to drop $24 on a serial debug cable that I'll use maybe two days to capture data that might or might not shed light on the issue.

[William Hermans]

william@arm:~$ uptime
 14:38:02 up 4 days,  4:31,  1 user,  load average: 0.04, 0.03, 0.05

And this is a small uptime. I've had it run for months at a time. Others yet have had longer uptimes.

One thing you have not mentioned, or at least i have not seen you mention is if you're connecting anything on the IO pins. IF so, what.

[William Hermans]

Oh, and right, only time I've had my beaglebone black reset, is when it loses power ( we switch from generator, and back to solar ). Or I've intentionally reset it. Mostly I reset my own board because I make lots of changes to various things, and I want to make sure it comes back up as intended from a reset.

[William Hermans]

Greg, buying a serial debug cable really is necessary if you intend to do anything serious with the BBB. However . . .

http://www.ebay.com/itm/like/351093728732?lpid=82

According to the PL2303HX datasheet it is 3v3 TTL, but double check for yourself. I've seen these cheap USB<->Serial converters go for as low as 2-3 USD. Cables, 6 bux US is about as low as I remember having seen them. From what I understand they're also supposed to be fairly decent, but as with anything else YMMV.

You said something about having other cables / modules just wrong header ? why not whip an adapter up ? Not that hard to make / use jumper wires . . . does matter if it looks pretty so long as it serves it's purpose.

[David Lambert]

I agree, serial cable is a must. Here's one a bit cheaper and on Amazon Prime:
http://www.amazon.com/gp/product/B008AGDTA4/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1

[Mike]

On 09/14/2014 08:24 PM, David Lambert wrote:

I agree, serial cable is a must. Here's one a bit cheaper and on Amazon Prime:
http://www.amazon.com/gp/product/B008AGDTA4/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1

On 09/14/2014 04:53 PM, William Hermans wrote:

Greg, buying a serial debug cable really is necessary if you intend to do anything serious with the BBB. However . . .

http://www.ebay.com/itm/like/351093728732?lpid=82

According to the PL2303HX datasheet it is 3v3 TTL, but double check for yourself. I've seen these cheap USB<->Serial converters go for as low as 2-3 USD. Cables, 6 bux US is about as low as I remember having seen them. From what I understand they're also supposed to be fairly decent, but as with anything else YMMV.

<snipped>

Not on prime, but only 2.43.
http://www.amazon.com/niceeshop-PL2303HX-RS232-Module-Converter/dp/B00F167PWE/ref=pd_cp_e_1

I've got several similar to this based on a Maxim 3232 chip.  Supports both 3.3 and 5 volts.
http://www.amazon.com/RS232-converter-board-Female-3-3V/dp/B005D5T292/ref=pd_sim_pc_6?ie=UTF8&refRID=12YRHXYJFNYQ50A5D8BZ

The shipping on the above rather kills the low price.  I ordered mine from China and the slow boat shipping, typically 3 to 4 weeks.  They are very versatile little boards.

Another option if you have a level converter handy is use your Rpi to get the serial output from the BBB.  If memory serves the Rpi is 5 volt on everything.

Mike

[skjo...@gmail.com]

William which kernel release are you running when you have no reboots? 

[skjo...@gmail.com]

Hi Robert i am having the same issues with at least 10 individual bbb boards both rev 5b and 5c and from booth adafruit and curcuitco. We are currently running them on a board with nice lab qualiy profesional 5v sources and ethernet and are pinging them constantly to simulate some sort of network activity. We have two of them connected via uart0 serial and have been logging that without spotting anything weird. Basically they just reboot. there is no trace of Oops or Panic...

We have tried the 3.14 kernels from ti and your kernel builds up to the 3.16.2-bone5 build. we have also compiled custom kernels trying to disable stuff like the otg based on another thread without success. 

Still we still have an average of one reboot per day.

we do have access to serial cables and are happy to assist with any debug info you might want. We have found nothing in dmesg and when logging the serial console we have so far seen nothing. I actually starts looking as a proper reset. 

Some reboot stats.. 
192.168.1.x:uptime 4:19 ;reboot 3

192.168.1.x:uptime 1 day 2:12 reboot 0

192.168.1.162:uptime 1 day 2:13;reboot 0

192.168.1.x:uptime 16:10;reboot 1

192.168.1.x:uptime 19:21;reboot 2

192.168.1.x:uptime 11:23;reboot 1

192.168.1.x:uptime 15:05;reboot 1

192.168.1.x:uptime 11:14;reboot 1

192.168.1.x:uptime 02:29;reboot 1

--Thomas

On Friday, September 12, 2014 2:55:47 PM UTC+1, RobertCNelson wrote:

On Fri, Sep 12, 2014 at 8:37 AM, Greg Kelley <suekk...@gmail.com> wrote:

> Update: I received my new BBB - a CurcuitCo version from Adafruit on
> Tuesday. On Wednesday I got it set up almost identical to the other one I
> sent back. It has 3.14.17-bone8 kernel. It rebooted/reset on Thursday at
> 2:15am and the physical ethernet port was down, so I had to connect via the
> USB port to look at syslog and see what happened. There is no entry for
> reboot or shutdown so it looks like a complete reset is taking place. Logs
> show ethernet port not coming up and dhcpclient says network unreachable

I know it's a little intrussive, but can you do me a favor...  Have
another machine log the debug serial port... Then we can see what's
going on..

[skjo...@gmail.com]

Hi we are experiencing the same problems as Greg. We are currently running more then 10 bbb in test booth revision 5b and 5c with the same results. We have tested both kernel version 3.14, 3.15 from ti as well as your builds with the same results.

Here are some stats from our boards running the  3.16.2-bone5 release..

192.168.1.160:uptime 9:52 ;reboot 3

192.168.1.161:no connection

192.168.1.162:uptime 2:16;reboot 1

192.168.1.163:uptime 8:06;reboot 2

192.168.1.164:uptime 2:50;reboot 3

192.168.1.165:uptime 5:12;reboot 1

192.168.1.167:uptime 13:38;reboot 3

192.168.1.169:no connection

We do have access to serial cables and are happy to support with any debug information you might want... We do not see anything weird in dmesg or the serial console which we have logged during the reboots.

On Wednesday, September 3, 2014 5:28:04 PM UTC+1, RobertCNelson wrote:

On Wed, Sep 3, 2014 at 11:21 AM, Greg Kelley <suekk...@gmail.com> wrote:
> I have downgraded the kernel from 3.16.0-bone2 to 3.15.10-bone8 and so far
> no reboots in the last 3 hours. If I get a full 24 hr cycle without reboots,
> I'll blame it on 3.16.0 and try to re-attach ext USB HUB, weather data
> logger, printer, and enable cups and weewx and see how far I get this time.

Thanks for the report, please let us know how v3.15.x react's too..
I'm currently chasing a few other issues with v3.16.x (acpi isn't
working)

btw, if you want something that's going to be a lot more
supported/tested down the road.

sudo apt-get update
sudo apt-get install linux-image-3.14.17-ti-r15

We are preping for a big transition.
http://elinux.org/Beagleboard:Capes_3.8_to_3.14

[Greg Kelley]

William,

I'm not using any I/O at this time. Setting this up in steps. First was to get it running as a CUPS and weewx Server like my RasPi. I can 'play' with it later once it's stable. Found a cable on eBay for $6 shipped from CA using PL303HX claims 3.3v TTL.

Also, no resets since 3pm yesterday when I switched PS. Maybe there is a problem with the SuperPowerSupply model KZ0502000, although the other BBB (element14) was resetting using both PS (SPS and Garmin) and even a direct USB connection. It's possible that there was a problem with both the other BBB and the SPS power supply. If it's happy with the Garmin I'll get a different 5v2a supply.

I am also solar but use a hybrid Grid-Tie Outback and a Manual Transfer Switch so when we lose power, it's dark until I can get to the switch. That's why I have all my electronics (cable modem, router, Vonage, etc on a UPS.

[Thomas O]

Well we are seeing exactly the same problems as Greg has experienced. We have 10 bbb running for a project and we are seeing on avg a crash per 24 hours or maybe rather a reboot.

We have tested the 3.14. 3.15 and 3.16 kernels built via Roberts build environment as well as installing the ti kernels wtih the same result.

We have ruled out the powers since we are now running all the boards from a profesional lab supply with measured ripple and performance way above the specs for the board.

We have had serial cables connected to the uart0 and have not seen anything strange in the dmesg or the serial console. No trace of oops or panic just restarts...

There is now difference between kernel versions or board revisions.

We do have access to serial cables and are happy to help with providing any debug info needed. 

--Thomas

On Tuesday, September 2, 2014 12:44:12 PM UTC+1, Greg Kelley wrote:

Got my first BBB last week, installed latest Debian. USB Hot Plug was completely hosed in Kernel 3.8 so I upgraded to 3.16 (latest non-rc version). Currently running CUPS print services (including Airprint) and weewx. It appears that the BBB is rebooting three or four times between 10pm and 1am, this has happened the last two days. I discovered it because weewx was going into an ftp loop because the system clock time was getting whacked (it is time/date sensitive to process weather data). Nothing in the log files unusual. Powered with a 5v 2a supply. Ethernet cable attached and external USB Hub (has external power but not used) with printer (turned off) and Weather Data Logger attached (has it's own power).

Before I start experimenting with removing USB Hub, plugging in just Weather Data Logger, etc. thought I'd check here first.

[Greg Kelley]

I have now been running 22 hours without a reset - this is a first. Yesterday at 3:17pm I changed out power supplies. I also killed wicp. So now I'm suspicious of wicp as the culprit. I added 'auto eth0' in /etc/network/interfaces since I'm hard wire connected and wicp was bringing up eth0 far too late in the boot sequence so that dhclient and ntp were both looping looking for the network (which wasn't up yet) but I still had wicp starting up at boot. I suppose I can shutdown and put the other power supply back on and see what happens with wicp removed.

[William Hermans]

Greg, ah yeah wicd . . .IMHO is the worst piece of **** program out there. First thing I do after installing an OS is remove it. If it exists.

After all, how hard is it to manually insert an interface into /etc/network/interfaces ? I'm old school anyhow, and prefer to do it this way.

So boot up times for me with systemd enabled, and static ips set for my interfaces

, is 15-16 seconds. systemd-analyze is great for this.

Using the standard init daemon, but up times are not much slower, but no cool tool to tell you exactly how long it takes.

[Greg Kelley]

Update: I changed power supplies back to the 5v2a and removed wicd yesterday at 3:20pm. Ran fine until 8:42am and reset after 16hrs. This time, it didn't bring up eth0 and was unreachable. I pulled the power and powered back up, booted normally. Interesting thing is that syslog only shows the second boot on power up and not the reset reboot. Syslog was fresh at 6:25am and shows only one bootup sequence. Strange. I was hoping resets were from wicd, guess not. Problem still exists. I could deal with a single reset every day, but not when eth0 fails as my weather server uploads ftp files to my website every 15 minutes. I lost eth0 on reset back on 9/11 at 8:13am, so loss of eth0 is random in the resets. I have a Phihong Switching Power Supply 5v2a that I'm going to put on there and see if that helps, but unlikely since Thomas has lab quality power and all of his are resetting. Here's what's left in rc2.d, I have removed S06weewx for now (as well as apache2 and saned).

README              S01motd     S03cron         S03ssh           S05cups
S01boot_scripts.sh  S01rsyslog  S03dbus         S03udhcpd        S06rc.local
S01capemgr.sh       S01sudo     S03loadcpufreq  S04avahi-daemon  S06rmnologin
S01hostapd          S01xrdp     S03ntp          S04cpufrequtils
S01leds-off         S03acpid    S03rsync        S05bootlogs

[Greg Kelley]

One other note, current Debian distro that comes with BBB has ntpdate installed. I have removed ntpdate and installed ntp in it's place.

[Greg Kelley]

I just changed over to the Switching Power Supply and eth0 failed to come up on boot. I hit the reset button and a reboot brought it up. So now it seems there are eth0 issues as well as resets. Going from bad to worse.

[Thomas Olofsson]

Greg we are experiencing the same issues as well with reset not bringing up the eth0 interface. we were trying to do a hw watchdog that would reset the board and when we press reset the eth0 interface fails as well. We are also setting the interface config static in /etc/network/interfaces.

 

--Skjortan!

On Tue, Sep 16, 2014 at 2:28 PM, Greg Kelley <suekk...@gmail.com> wrote:

I just changed over to the Switching Power Supply and eth0 failed to come up on boot. I hit the reset button and a reboot brought it up. So now it seems there are eth0 issues as well as resets. Going from bad to worse.

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/vgeh336p0P4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Chris Morgan]

On Tue, Sep 16, 2014 at 11:42 AM, Thomas Olofsson <skjo...@gmail.com> wrote:
> Greg we are experiencing the same issues as well with reset not bringing up
> the eth0 interface. we were trying to do a hw watchdog that would reset the
> board and when we press reset the eth0 interface fails as well. We are also
> setting the interface config static in /etc/network/interfaces.
>
>
>
>
> --Skjortan!
>
> On Tue, Sep 16, 2014 at 2:28 PM, Greg Kelley <suekk...@gmail.com> wrote:
>>
>> I just changed over to the Switching Power Supply and eth0 failed to come
>> up on boot. I hit the reset button and a reboot brought it up. So now it
>> seems there are eth0 issues as well as resets. Going from bad to worse.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---

I very much appreciate your efforts in looking at these issues. The
company I work for is planning to use a BBB in a commercial product,
after discussions with CircuitCo, and this issue has me a little bit
worried. We haven't had a wide enough scale usage to know if we are
seeing something similar here with the resets and eth0 issues.

Looking forward to observing as you guys continue to work through this stuff.

Chris

[Gerald Coley]

I plan to address this on the Ethernet issue in the next revision of the board in the form of a GPIO based recovery mechanism that will allow SW to reset the Ethernet PHY.

Gerald

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 beagleboard...@googlegroups.com.

[Robert Nelson]

On Tue, Sep 16, 2014 at 11:53 AM, Chris Morgan <chmo...@gmail.com> wrote:

we do have a phy workaround:

https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.16/patches/beaglebone/phy/0003-cpsw-search-for-phy.patch

i need to rebase it to the 3.14-ti tree..

[Gerald Coley]

Well. That would be nice to have everywhere.

Gerald

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 beagleboard...@googlegroups.com.

[Robert Nelson]

On Tue, Sep 16, 2014 at 12:56 PM, Gerald Coley <ger...@beagleboard.org> wrote:
> Well. That would be nice to have everywhere.

It is all the "bone" branches, except in the new 3.14-ti tree... It
was one of those, I was just tagging a new release, oh crap, should
have added that. But was in a race to leave work today to run some
errands. ;) It'll be the first thing i add back later.

[Gerald Coley]

Thank you!

Gerald

[Thomas Olofsson]

Well new and interesting discoveries on this problem.

Last night we set up 9 bbw as well as the blacks for control. during the night all of the bbb has crashed at least once and none of the bbw. All running the same kernel and software. 3.15.2-bone5.

This means that this is hw related on the bbb board. i am starting to suspect the PMIC that some interference somehow triggers a sys_reset. we are trying to connect a data logger to some pins on the bbb to see if sys_reset goes low prior to reboot but i strongly suspects it does.. 

--Skjortan!

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/vgeh336p0P4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Greg Kelley]

I had a total of 5 resets yesterday one at 8am, 5pm, 9pm, 10pm, 11pm using a switching power supply. Maybe I should go back to the cheapo power supply as I was only resetting once or twice a day with that one. I'll wait and see what Thomas comes up with before ordering the serial debug cable. Only thing I have changed in the last two days has been the power supply, all else is static (kernel, running daemons, attached hub). I'm going to unplug the USB HUB now and see what that does.

[Micka]

I didn't follow all the conversation, but I had a reboot several time every day. 

I found out that the bandwidth of the Network was too much for the BeagleBone black and the watchdog decided to reboot the beagle every time.

[Thomas Olofsson]

Micka that sounds interesting. which watchdog are you talking about?  is this a hardware watchdog on the board or a software watchdog. How can you find evidence that it is the watchdog that is causing the reboot. 

Which circuit are you talking about and is there any dmesg or other information you could share.

As stated i now have 9 black all rebooting and nine white not rebooting. Same kernel. same network same network load. 

--Skjortan!

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/vgeh336p0P4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Micka]

you have to activate the watchdog, normally it's not activated by default. 

I'm talking about the software watchdog. 

[William Hermans]

As stated i now have 9 black all rebooting and nine white not rebooting. Same kernel. same network same network load.

Forget about claiming its a hardware issue. Because it is not. We've had two beaglebone blacks for close to a year, and a half now. Both are rock solid, running off barrel jack power, or USB( one of each ).

Everything the three of you have been talking about does not even seem to be related. EXCEPT perhaps kernel 3.14.x, and reboots.

SO quite with the half cocked guessing, and start doing some *real* troubleshooting. Get a serial debug cable / module, and use it appropriately. Until then, you all are only yanking everyone elses chain.

[Robert Nelson]

On Wed, Sep 17, 2014 at 2:18 PM, William Hermans <yyr...@gmail.com> wrote:
>> As stated i now have 9 black all rebooting and nine white not rebooting.
>> Same kernel. same network same network load.
>
>
> Forget about claiming its a hardware issue. Because it is not. We've had two
> beaglebone blacks for close to a year, and a half now. Both are rock solid,
> running off barrel jack power, or USB( one of each ).
>
> Everything the three of you have been talking about does not even seem to be
> related. EXCEPT perhaps kernel 3.14.x, and reboots.
>
> SO quite with the half cocked guessing, and start doing some *real*
> troubleshooting. Get a serial debug cable / module, and use it
> appropriately. Until then, you all are only yanking everyone elses chain.

One of my boards finally did this with 3.14-ti, just randomly
rebooted, no serial debug messages. Kinda looked like the watchdog
timer, as it was just "too" clean of a kernel reboot..

[William Hermans]

Time to turn verbose mode on ?

[Thomas Olofsson]

Forget about claiming its a hardware issue. Because it is not. We've had two beaglebone blacks for close to a year, and a half now. Both are rock solid, running off barrel jack power, or USB( one of each ).

Ok well just stating facts that bbw is not rebooting and BBB is with the same kernel

Ok i would be happy to stop guessing and actually find the problem. Could you give me some real advise on HOW to use the serial module appropriately. i do have it connected to the serial console and i have event built a kernel with verbosed debugging on i am just not seeing anything. 

So if you would like any information or dumps or whatever i am happy to provide that.

[William Hermans]

Short term, you can disable the hardware watchdog in kernel config. That should temporarily fix your problem, and if it does not . . . bigger mystery.

Long term, it would be good to figure out what is triggering the watchdog. strace on the watchdog PID will not work - I tested this myself.

The only one thing I can think of off hand is perhaps modifying the watchdog module to output a debug message before rebooting the system. As to which process triggered a shutdown, and why. If possible . . .

Will research more tomorrow it is very late ( actually early ) here.

[Sebastian H]

I switched over from kernel 3.8.13 to 3.14.19-ti-r28 (compiled with netconsole support)  and after a little over 24 hours uptime, my BBB rebooted without any entries in the netconsole log or any logs on the BBB that I could find. 

Did anyone have any luck in troubleshooting this issue any further? 

In the meantime, I guess I'll try your suggestion of disabling the watchdog for now.

[Sebastian H]

The issue still happened even using the kernel compiled without any watchdog support. The netconsole log didn't include any details. It just rebooted again without any indication why. That was about 24 hours after the last restart. 

I still had the watchdog package installed (but with even the software watchdog disabled in the kernel, I didn't think it would do anything). Well, I now removed that, but I'm not convinced that it did cause the reboot.

[Sebastian H]

For the record, even with the watchdog package removed, my BBB rebooted on me again after just 7 hours of uptime. :-(

Here's the kernel config I used. Searching for watchdog, there are only two entries. This is the one still enabled:

CONFIG_OMAP_REMOTEPROC_WATCHDOG=y

Should I disable that as well? 

[Micka]

Did you check if memory usage is increasing ? Log file ?

Micka,

[Maxim Podbereznyy]

I remember that once it was suggested to check the reboot reason from the pmic. Definitely your issues are because of some hardware faults in the pmic

13 Окт 2014 г. 12:55 пользователь "Micka" <micka...@gmail.com> написал:

[Sebastian H]

@Micka:

I'm not sure how to check for increased memory usage as it's completely unpredictable when it's going to reboot. Is there some kind of logging I can enable for memory usage so it would get logged to my netconsole?

As for logs, the netconsole log has nothing before the reboot occurs (just like the previous reports on this thread, including the one from RobertCNelson). Here's the kernel log from when it booted up after the sudden reboot.

I also checked the syslog and there's nothing out of the ordinary in it. It appears as if some killed the power for a second and the system just boots up again.

Is there any other log I could look for?

@lisarden: 

How would I go about checking the PMIC? Looking at the kernel log from the boot I can only see this:

[    5.761536] sr_init: No PMIC hook to init smartreflex

[    5.767135] sr_init: platform driver register failed for SR

I've also checked my past kernel logs and it's always the same line.

Checking the kernel config, I'm not seeing any obvious setting to enable. Can you point me in the correct direction?

Thanks to both of you for your replies.

[Sebastian H]

Searching around a bit, I wonder if an old u-boot version might have anything to do with it? From what I can tell, I'm still using an u-boot release from 2013.07 . Should I be updating this? If so, what would be the safest way to do so?

In /boot/uboot/tools, I noticed a couple of scripts (bootloader_update, update and update_boot_files). Would any of these work or should I get a more recent version?

[Greg Kelley]

Mine is still resetting one to three times a day. I have moved both processes I was running on it (CUPS and weewx) over to my RasPi so it is just sitting idle except for CRON jobs. No events in serial debug logs, just a sudden reset and cold boot restart.

[Thomas Olofsson]

We still have the same issues with reboots as well. we have had to move our project to bbw for now instead. the bbw with the same kernel and no reboots for two weeks. The BBB reboots on an average og 1-2 times per 24 hours independent of load.

No serial messages. No kernel messages, no oops. We have also tried a kernel wo watchdog support with no avail...

Any suggestions is highly appreciated at this point..

--Skjortan!

On Mon, Oct 13, 2014 at 8:37 PM, Greg Kelley <suekk...@gmail.com> wrote:

Mine is still resetting one to three times a day. I have moved both processes I was running on it (CUPS and weewx) over to my RasPi so it is just sitting idle except for CRON jobs. No events in serial debug logs, just a sudden reset and cold boot restart.

--
For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/vgeh336p0P4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[William Hermans]

I do not know what to tell you other than . ..

william@arm:~$ uptime
 23:30:30 up 26 days,  6:34,  1 user,  load average: 0.00, 0.01, 0.05

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.

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 beagleboard...@googlegroups.com.

[Lei Wang]

I've run into the BBB random reboot problem a while ago. We've eventually found out the root cause is the USB-OTG detection. The USB-OTG periodical probing actually caused the problem. Details and fix please the link below:

https://groups.google.com/forum/#!searchin/beagleboard/unexpected$20reset/beagleboard/xPxzYyNsA78/DOlXIlyYTqIJ

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 hope this helps.

Lei Wang

[DLF]

Hello,

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.

cheers,

[jmelson]

On Monday, October 13, 2014 1:37:18 PM UTC-5, Greg Kelley wrote:

Mine is still resetting one to three times a day. I have moved both processes I was running on it (CUPS and weewx) over to my RasPi so it is just sitting idle except for CRON jobs. No events in serial debug logs, just a sudden reset and cold boot restart.

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.

Jon

[Greg Kelley]

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.

[Jason Lange]

On Fri, Sep 12, 2014 at 9:35 AM, Robert Nelson <robert...@gmail.com> wrote:

On Fri, Sep 12, 2014 at 11:27 AM, Greg Kelley <suekk...@gmail.com> wrote:
> Robert,
>
> I think part of the reason ntp and dhcpclient aren't getting network
> connections at boot is because they are set at S03 in init and wicd is set
> at S06 and is last to get going. It appears that eth0 is not coming up until
> wicd loads?

Correct, wicd set's up eth0, that's how we got the 11-12 second bootup
time. Otherwise if eth0 is handled by /etc/network/interfaces bootup
could last 2 minutes for users who don't connect eth0.  I should
atleast really move ntp from S03 to S06..

@Robert

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

Cheers.

[Robert Nelson]

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

[David Goodenough]

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.

David

[Jason Lange]

On Tue, Nov 18, 2014 at 11:43 AM, Robert Nelson <robert...@gmail.com> wrote:

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

Regards,

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.

[Jason Lange]

@david

I have tested this.  Try it, it works.

--
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 beagleboard...@googlegroups.com.

[Jason Lange]

Hello again,

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. 

Cheers.

[Greg Kelley]

Update to Reboot Issue:

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.

[Robert Nelson]

We had a couple musb patches get rolled in from ti..

https://github.com/beagleboard/linux/compare/3.14.23-ti-r33...3.14.23-ti-r34

otherwise we are defaulting to peripheral mode for the slave connector.

https://github.com/beagleboard/linux/commit/b30d918f1e9657d3a9b2eaf7fc6ea3f7ea545b5c

Thanks for testing!

[William Hermans]

@Greg Kelley

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.

[Britton Kerin]

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?

Britton

[Greg Kelley]

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

[evilwulfie]

You have disrupted your creditability already by referencing Windows as "Windoze"

[Robert Nelson]

On Wed, Nov 19, 2014 at 8:16 AM, evilwulfie <evilw...@gmail.com> wrote:
> You have disrupted your creditability already by referencing Windows as
> "Windoze"

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.

[William Hermans]

Seems I hit a nerve, however I'm fairly sure that Linux has only been around since 91 so . . .

Maybe you mean UNIX.