On Saturday, November 8, 2014 10:01:52 AM UTC-5, Ives van der Flaas wrote: > > However, not enoug of a difference apparently. I just had a sudden reset > occur. This is on a 3.18-rc2-bone1 with both a Dymo labelwriter and a > smartcard reader attached through USB. >
Jens Peter Schroer gave me the recipe to make it work in my configuration. I tried to enter an issue in http://bugs.elinux.org/projects/beaglebone-black/issues but it kept giving me an internal error, so I'm adding it here. There are a number of google group threads with similar characteristics to this issue; search group for: * "Beaglebone Black Rebooting Several Times Every Day" * "Beaglebone Black Random Reboot" * "3.17.1-rc4 sudden reset" Scenario: * BBBv3 * 3.17.1-rc4, 7.6 wheezy * usb0 is NOT connected * running BBB headless, control through uart and SSH * usb1 has a hub with one to three wireless plugs * 1.5A 5V power source Goal is a low-cost wifi monitor where the wifi plug runs with two interfaces: one in standard 802.11 mode and the second in monitor/otherbss mode capturing all traffic. I use the netlink iw package to add the second interface and set it to 802.11 monitor mode. I use wireshark to read on that interface and save packets to the sdcard. The normal interface is used for SSH control/monitor of the BBB. Initially the system ran okay using the wifi but when I ran the second monitor, it silently reboot at erratic times but all within 3 hours. There was no cause indication on the console or the logs. I built a couple versions of the kernel, up to 3.18.0-rc3-bone1, and tried a pre-built RCN image - all showing the same problem. Jens Peter Schroer emailed me a possible solution, which I have attached, of forcing usb0 to act as a peripheral and not OTG. His solution worked for my configuration. It appears there are other configurations that manifest the same silent reboot that the changing of usb0 dr_mode DOES NOT fix. -- 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.
From: Jens Peter Schroer Date: Fri, 7 Nov 2014 01:52:40 +0100 Subject: Re: Beaglebone reboot To: dturvene gmail Cc: Ives van der Flaas Hi, Sorry for the late reply. I was out on a business trip all day and could not reply earlier. Let me outline how I traced the issue on my systems, so that you can reproduce this with your systems. A few things up front: a. I did my experiments with 3.17.1-bone4. I assume it works under other kernel versions as well, but just as a heads up. b. I used Lei Wang's post in https://groups.google.com/forum/#!topic/beagleboard/xPxzYyNsA78 as gudianc= e c. You need to have debugfs and CONFIG_DYNAMIC_DEBUG enabled in the kernel (it's the case by default) d. I assume debugfs is mounted at /sys/kernel/debug e. I assume you know how to build a kernel Let's get started. First, let's see the issue (according to Lei Wang the probing for OTG devices can sometimes cause an overload and the system will reboot). 1. We need to become root: $> sudo su 2. Enable tracing for the OTG probing: $> echo 'file tps65217.c line 189 +p' > /sys/kernel/debug/dynamic_debug/control 3. Check dmesg for OTG probing logging: $> dmesg Output should show: [ 217.095367] tps65217_irq: USB power status change [ 217.259338] tps65217_irq: USB power status change [ 219.096801] tps65217_irq: USB power status change [ 219.256103] tps65217_irq: USB power status change [ 221.094177] tps65217_irq: USB power status change 4. Patch the kernel to make usb_0 run in peripheral mode with the following patch: diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi index 0dc22d2..dffe269 100644 --- a/arch/arm/boot/dts/am335x-bone-common.dtsi +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi @@ -94,6 +94,7 @@ &usb0 { status =3D "okay"; + dr_mode =3D "peripheral"; }; &usb1 { 5. As precaution I also disabled USB OTG support in the kernel. 6. Rebuild the kernel and reboot with it 7. Repeat step 3 to confirm patch was applied correctly. The ouput should NOT be present anymore! 8. Done Since I have applied this patch, our systems are running stable again. Our systems are making heavy use of Wifi as well. The two different system setups we are using: 1. BBB with D-LINK 7port USB 2.0 HUB and 2x Netgear WNA1100 dongles + 1 Bluetooth smart dongle 2. BBB with D-LINK 4port USB 2.0 HUB and 1 UWN200 dongle All systems rock solid so far even under wifi load. Dave, could you share what you are exactly are doing with your system (sample commands and programs used)? Kind regards, Jens
