Re: [beagleboard] Re: 3.17.1-rc4 sudden reset
The problem still isn't fixed on my end, but I've certainly been getting closer. I've tried - Disabling all watchdog timers in u-boot and Linux, still crashes - A different 5V power supply, still crashes - Disconnecting all USB devices, still crashes And to ensure I don't have faulty hardware, I tried running on a different BBB (still crashes) as well as changing the kernel to the old 3.8 (does not crash). The one thing I have found that actually works, is disabling the custom application that's running all the time. The application uses pcscd to constantly poll (interrupt based wasn't supported) if a smartcard is being inserted. I have to suspect that through these repeated USB reads, I'm somehow triggering the same bug that Jens and David could eliminate by disabling OTG. As to how I could actually pinpoint that bug, I really have no idea - the USB subsystem is rather complicated. All help is welcome. Op zondag 9 november 2014 19:50:46 UTC+1 schreef david turvene: 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3.17.1-rc4 sudden reset
Setting the usb0 dr_mode to peripheral and disabling OTG in the .config definitely makes a big difference. I have a 3.18-rc2-bone1 currently running for almost 24 hours with this patch, much more than I've ever previously achieved with 3.18 or 3.17. Op woensdag 5 november 2014 01:36:09 UTC+1 schreef Jens Peter Schroer: I followed up on the USB OTG hint as mentioned in my previous post. I patched the dtb for the bbb so that the mini usb port runs as peripheral and not as OTG. The patch was deployed to 7 systems so far and they all are stable (no reboot) since then on any of the systems. The uptime is more than 3 days now. If interested, I can post more details. On Tuesday, November 4, 2014 3:01:53 PM UTC+1, Ives van der Flaas wrote: Have you had *any* resets since the upgrade to the new u-boot version? I've also been suspecting u-boot, hence my Meaning that I'm also running an old u-boot. in the last post. Op dinsdag 4 november 2014 00:18:43 UTC+1 schreef david turvene: On Saturday, November 1, 2014 3:24:33 PM UTC-4, david turvene wrote: The system runs fine when I'm not messing around with the plugs, changing the wifi properties, or sniffing. When I do any of these the system occasionally silently reboots - I've been able to test up to 20 sniffing sessions before it reboots, sometimes it will reboot immediately when I start an monitor session. * I run the BBB headless, generally using SSH xterm. * The silent reboot happens with NO indication. NOTHING. The uart console just shows a system restart. * I triggered a watchdog NMI (it takes 22 seconds) and it showed a lot of diagnostic info - so that's not it. Further research - similar behavior was reported last year. Lot's of red herrings (USB control appeared to be the most suspicious because that's my main interface but also long threads blaming the power management unit.) Someone found that another clock source was needed for low-power state and moved the new code into u-boot. I was running with a local build from RCN's git repo described at: https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot and 2014.7 baseline. I noticed it is now at 2014.10 so I rebuilt and installed on target. The system is much more stable after testing for a lot longer than I could before. And I'm pretty sure the clocking/power is the root cause of the silent reboots so I'm checking how the clock change, to the RTC32K clock, works. Also, since I'm running from emmc, I used am335x_boneblack_defconfig to build u-boot. The only difference is it sets EMMC_BOOT but a quick grep shows it changes logic in a couple places. Anyway, it's a start... -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3.17.1-rc4 sudden reset
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. The boot log after reset can be found at http://pastebin.com/YGnNpJyQ Op zaterdag 8 november 2014 10:37:51 UTC+1 schreef Ives van der Flaas: Setting the usb0 dr_mode to peripheral and disabling OTG in the .config definitely makes a big difference. I have a 3.18-rc2-bone1 currently running for almost 24 hours with this patch, much more than I've ever previously achieved with 3.18 or 3.17. Op woensdag 5 november 2014 01:36:09 UTC+1 schreef Jens Peter Schroer: I followed up on the USB OTG hint as mentioned in my previous post. I patched the dtb for the bbb so that the mini usb port runs as peripheral and not as OTG. The patch was deployed to 7 systems so far and they all are stable (no reboot) since then on any of the systems. The uptime is more than 3 days now. If interested, I can post more details. On Tuesday, November 4, 2014 3:01:53 PM UTC+1, Ives van der Flaas wrote: Have you had *any* resets since the upgrade to the new u-boot version? I've also been suspecting u-boot, hence my Meaning that I'm also running an old u-boot. in the last post. Op dinsdag 4 november 2014 00:18:43 UTC+1 schreef david turvene: On Saturday, November 1, 2014 3:24:33 PM UTC-4, david turvene wrote: The system runs fine when I'm not messing around with the plugs, changing the wifi properties, or sniffing. When I do any of these the system occasionally silently reboots - I've been able to test up to 20 sniffing sessions before it reboots, sometimes it will reboot immediately when I start an monitor session. * I run the BBB headless, generally using SSH xterm. * The silent reboot happens with NO indication. NOTHING. The uart console just shows a system restart. * I triggered a watchdog NMI (it takes 22 seconds) and it showed a lot of diagnostic info - so that's not it. Further research - similar behavior was reported last year. Lot's of red herrings (USB control appeared to be the most suspicious because that's my main interface but also long threads blaming the power management unit.) Someone found that another clock source was needed for low-power state and moved the new code into u-boot. I was running with a local build from RCN's git repo described at: https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot and 2014.7 baseline. I noticed it is now at 2014.10 so I rebuilt and installed on target. The system is much more stable after testing for a lot longer than I could before. And I'm pretty sure the clocking/power is the root cause of the silent reboots so I'm checking how the clock change, to the RTC32K clock, works. Also, since I'm running from emmc, I used am335x_boneblack_defconfig to build u-boot. The only difference is it sets EMMC_BOOT but a quick grep shows it changes logic in a couple places. Anyway, it's a start... -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3.17.1-rc4 sudden reset
@David, did you try it on 3.17 or 3.18? Jens did his patch on 3.17 so there could potentially be a difference there (unlikely that it is). Op donderdag 6 november 2014 23:31:43 UTC+1 schreef david turvene: On Thursday, November 6, 2014 11:10:37 AM UTC-5, Jens Peter Schroer wrote: I have followed the USB OTG hint as mentioned in my previous post. I patched the dtb for the bbb so that the mini usb port runs as peripheral and not as OTG. The patch was deployed to 7 systems so far and they all are stable (no reboot) since then on any of the systems. The uptime is more than 3 days now. @Jens - thanks for the tip. I tried it: setting usb0 dr_mode = peripheral and usb1 dr_mode = host. I don't use usb0 at all; usb1 has a usb hub with wifi plugs. The BBB ran for about a three hours under heavy load (125K packet captures w/ about 10K dropped) and then silently reset. I'm going to try (1) soaking the BBB with a light load overnight, 2) run power over usb0. Dave -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3.17.1-rc4 sudden reset
Have you had *any* resets since the upgrade to the new u-boot version? I've also been suspecting u-boot, hence my Meaning that I'm also running an old u-boot. in the last post. Op dinsdag 4 november 2014 00:18:43 UTC+1 schreef david turvene: On Saturday, November 1, 2014 3:24:33 PM UTC-4, david turvene wrote: The system runs fine when I'm not messing around with the plugs, changing the wifi properties, or sniffing. When I do any of these the system occasionally silently reboots - I've been able to test up to 20 sniffing sessions before it reboots, sometimes it will reboot immediately when I start an monitor session. * I run the BBB headless, generally using SSH xterm. * The silent reboot happens with NO indication. NOTHING. The uart console just shows a system restart. * I triggered a watchdog NMI (it takes 22 seconds) and it showed a lot of diagnostic info - so that's not it. Further research - similar behavior was reported last year. Lot's of red herrings (USB control appeared to be the most suspicious because that's my main interface but also long threads blaming the power management unit.) Someone found that another clock source was needed for low-power state and moved the new code into u-boot. I was running with a local build from RCN's git repo described at: https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot and 2014.7 baseline. I noticed it is now at 2014.10 so I rebuilt and installed on target. The system is much more stable after testing for a lot longer than I could before. And I'm pretty sure the clocking/power is the root cause of the silent reboots so I'm checking how the clock change, to the RTC32K clock, works. Also, since I'm running from emmc, I used am335x_boneblack_defconfig to build u-boot. The only difference is it sets EMMC_BOOT but a quick grep shows it changes logic in a couple places. Anyway, it's a start... -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3.17.1-rc4 sudden reset
I can confirm that the problem still exists on the 3.18-rc2-bone1. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 3.17.1-rc4 sudden reset
Op donderdag 30 oktober 2014 18:15:33 UTC+1 schreef William Hermans: So I'm curious. Did all of you follow Roberts DebianOnARM kernel build instructions, or are you all using a prebuilt image ? I'm using a pretty old prebuilt 13.04 image (with lots of libraries and scripts with quite a few units running in production, not easily upgraded). Meaning that I'm also running an old u-boot. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] 3.17.1-rc4 sudden reset
I'm running Robert C Nelson's latest 3.17 kernel (3.17.1-bone4) because I need the new TI musb babble recovery code. It seems however that I'm having some strange instability on my BBB. After somewhere between 10 and 24 hours, the device seems to reset suddenly and without warning. There's no kernel panic as far as I can see (no kernel.panic time-out in my sysctl either) and nothing in the dmesg or kern log files. It suddenly resets. On the serial console, using my own FTDI cable, I was running watch, and when I returned the next day the program wasn't refreshing as it should have been. I pressed enter and immediately a login prompt appeared. Uptime was also way shorter than it should have been. Any clues on what might cause this? This seems a bit like a power supply issue, but I've been running the same BBB for weeks using the same power supply on a 3.8.13 kernel and that's always worked fine, while on this kernel it can't even last a day. Thanks, Ives -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: CAUTION: musb: Babble Interrupt Occurred
Do you by any chance know in what revision the babble interrupt problem was fixed? Was it only fixed in 3.12 or also in other trees (e.g. 3.8)? Op dinsdag 13 mei 2014 17:19:42 UTC+2 schreef cody: What version of the 3.12 kernel do you have? The latest version of the 3.12 kernel should have a patch that fixes that problem. On Tue, May 13, 2014 at 8:04 AM, Renato Riolino renato.n...@gmail.com javascript: wrote: Hi! I'm having this same issue with my BeagleBone Black. I have an USB keyboard connected direct on the beagle's usb port and I'm using ubuntu 13.04 with kernel 3.12. After some random amount of time, the keyboard stop working and the only thing I see on dmesg is: CAUTION: musb: Babble Interrupt Occurred If I remove keyboard, nothing appears on dmesg and even with the keyboard removed, if I do a lsusb it still shows up as been connected. The only way to get it working again is doing a full reboot. I've already tried to do things like: echo 'on' /sys/bus/usb/devices/usb1/power/control on rc.local and to make a script that keeps on a infinite loop doing a cat on /proc/bus/usb/xxx/yyy, but the problem persist. Thanks Renato Em sábado, 31 de agosto de 2013 12h42min09s UTC-3, jez...@gmail.com escreveu: I'm using my Beaglebone Black with a USB temperature sensor. It works very well, however I noticed monitoring stopped last night after roughly 35 days uptime. This morning I looked more closely into the log file and noticed: kernel: [2892926.929555] CAUTION: musb: Babble Interrupt Occurred I wasn't able to successfully reset the USB device and before I was able to restart the BBB stopped responding. I power-cycled it and it was back to normal again. Any ideas what caused this kernel message? -- 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 javascript:. 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Prevent linux from clearing GPIO pins during boot
Some more information: I'm running the BeagleBone Black with a 3.8.13-bone33 kernel. Op donderdag 26 december 2013 09:42:12 UTC+1 schreef Ives van der Flaas: I have two GPIO pins that I'd like to be high during the boot process. These pins, GPIO 44 and 23, are connected to LEDs through some circuitry. I've managed to set those pins when uBoot runs, but they are reset during the boot process: as soon as the linux kernel starts these pins are pulled low. After linux finishes booting I install a device tree overlay and can resume control of the pins. How can I prevent these pins from being cleared? Is this done by the linux kernel itself or some driver? How do I start looking for the code responsible? (I also posted this question 3 days ago but it hasn't appeared in the relevant group). -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[beagleboard] Prevent linux from clearing GPIO P8_12 and P8_13 on boot
Hi everyone, I'm building a product based on the BeagleBone Black that uses LEDs to indicate the current status. These LEDs are connected to P8_12 and P8_13 (GPIO 44 and 23) and need to be turned on during boot. I succeeded in setting the relevant pins to high in uBoot, but as soon as the linux kernel boots, the pins are immediately cleared. After boot I can regain control through a device tree overlay, but the GPIO pins I mentioned before need to be high during the entire boot process. Any ideas on what driver/module is responsible for this behaviour and how I can prevent linux from clearing the relevant GPIO ports? Thanks Ives -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[beagleboard] Prevent linux from clearing GPIO pins during boot
I have two GPIO pins that I'd like to be high during the boot process. These pins, GPIO 44 and 23, are connected to LEDs through some circuitry. I've managed to set those pins when uBoot runs, but they are reset during the boot process: as soon as the linux kernel starts these pins are pulled low. After linux finishes booting I install a device tree overlay and can resume control of the pins. How can I prevent these pins from being cleared? Is this done by the linux kernel itself or some driver? How do I start looking for the code responsible? (I also posted this question 3 days ago but it hasn't appeared in the relevant group). -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
