On Sat, Dec 13, 2014 at 10:29 AM, david turvene <[email protected]> wrote: > On Thursday, December 11, 2014 7:35:39 AM UTC-5, Julian Gold wrote: >> >> On both B and C revisions of Beaglebone black, our application (running >> under either the shipped Angstrom or Debian distros) locks up after random >> amounts of time. The debug port reports the following problems: >> >> [ 752.038977] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:1:15] >> [ 752.063631] BUG: scheduling while atomic: kworker/0:1/15/0x40010100 >> [ 754.935632] Kernel panic - not syncing: softlockup: hung tasks >> [ 754.946347] [<c0010443>] (unwind_backtrace+0x1/0x8a) from [<c0455ced>] >> (panic >> +0x51/0x148) >> [ 754.960814] [<c0455ced>] (panic+0x51/0x148) from [<c00678df>] >> (watchdog_timer >> _fn+0xc3/0xf8) > > This is a watchdog non-maskable interrupt (NMI). The kernel needs to write > a fixed pattern to a hardware register once in a while to prevent the > interrupt. If it does not, the Watchdog Timer (WDT) will count down and an > interrupt will automatically occur. It's used as a last effort to recover > from a cpu lockup. My guess from the stack trace is the CPU is handling so > many interrupts from the USB drivers that the watchdog is not serviced. > I've seen a similar issue on a IEEE80211/usb driver. Don't expect > high-performance computing from a $50 card. > > Possible solutions (recognizing I know nothing about FTDI) > > 1) The best is to squelch the traffic flow, thus reducing the interrupts. > Review the amount of traffic on the FTDI interface and see if some can be > dropped or filtered before hitting the interface. Or program the FTDI chip > to filter before sending through the USB interface. If still a problem, > modify the driver to discard some types of FTDI packets. > > 2) Change to a more powerful CPU. The multicore TI offerings (e.g. > Pandaboard has an dual-core Cortex-A9, the forthcoming BBB X15 has a > dual-core A15 I think, TI Keystone line) should do the trick. But almost > everything on that level is $$$$ compared to the BBB. > > If you try to change the interrupt priorities or disable the WDT you'll just > be moving the problem to another logical area. > > -- > 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.
Wouldn't it make sense to raise the priority of the timer or whatever code was hitting the WDT? It seems like a bug if usb or other interrupts could cause the watchdog to fail to be serviced given that the system is still working properly. How is the wdt serviced by the kernel? Is it easy to raise its priority? Chris -- 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.
