Note that there are plenty of other things in my kernel config. I only showed the differences between the original (when I would get kernel panic) and the modified (no kernel panic).
On Wednesday, November 26, 2014 10:07:00 AM UTC-5, beagler001 wrote: > > My kernel is no longer crashing. Unfortunately, I do not have the exact > work-around - as I was messing around with a lot of stuff to try to get > this to work. > > The one thing consistent in all this is the backtrace (/var/log/kern.log) > in that the routine c_can_get_berr_counter is doing something that it > should not do. But trying to get someone that knows about this code to take > a look seems to be a huge challenge. If you would like to see the > backtrace, let me know. > > I do know that the resolution was one of two things: > > 1. Our CAN transceiver's enable line was being shared with MMC1_DAT0 - > which was brought out to P8-25 on an expansion header. I tried (various > methods) to reset the eMMC in hopes of driving its pins to an open-drain > state. I could never get that to work, and therefore I could never drive > the CAN transceiver's enable line low. I got around this by wiring P8-25 > directly to ground. That could have been causing problems with either the > CAN transceiver or the processor itself. Or it could be that leaving the > CAN transceiver enabled through the boot process caused issues as well. > Nonetheless, I clipped the P8-25 pin on our cape and wired from another > GPIO line that was routed to the P8 expansion header (P8-17 I think). This > allowed me to enable the CAN transceiver cleanly, post-boot. > > 2. I disabled some things in my kernel config. > > ---------------------------- > Original default (defconfig) > ---------------------------- > CONFIG_CAN_SLCAN=m > CONFIG_CAN_TI_HECC=m > CONFIG_CAN_MCP251X=m > CONFIG_CAN_GRCAN=m > # CONFIG_CAN_DEBUG_DEVICES is not set > > CONFIG_WIMAX=m > CONFIG_WIMAX_DEBUG_LEVEL=8 > CONFIG_RFKILL=m > CONFIG_RFKILL_LEDS=y > CONFIG_RFKILL_INPUT=y > CONFIG_RFKILL_GPIO=m > > CONFIG_USB_HSO=m > > # WiMAX Wireless Broadband devices > # > # CONFIG_WIMAX_I2400M_USB is not set > > CONFIG_RADIO_WL128X=m > > > ---------------------------- > Modified defconfig > ---------------------------- > # CONFIG_CAN_SLCAN is not set > # CONFIG_CAN_TI_HECC is not set > # CONFIG_CAN_MCP251X is not set > # CONFIG_CAN_GRCAN is not set > CONFIG_CAN_DEBUG_DEVICES=y > > # CONFIG_WIMAX is not set > # CONFIG_RFKILL is not set > > # Enable WiMAX (Networking options) to see the WiMAX drivers > # > > # CONFIG_FB_BACKLIGHT is not set > > # CONFIG_USB_APPLEDISPLAY is not set > > > Hope that helps. > > > On Friday, November 21, 2014 2:47:21 PM UTC-5, Me Nee wrote: >> >> Thanks, very informative links, particularly the last one. >> >> On Friday, November 21, 2014 8:09:41 AM UTC-7, beagler001 wrote: >>> >>> >>> No solution here yet, but I have found some very relevant discussions >>> out there. Something must have changed with the kernel scheduler that >>> requires drivers (CAN in our case) to be updated. I copied the BeagleBone >>> kernel support guru to this post (Robert Nelson). Perhaps he is already >>> aware of this problem and knows of a work-around. I will post something >>> if/when I get this figured out. Until then, here are some relevant links. >>> >>> >>> http://stackoverflow.com/questions/3537252/how-to-solve-bug-scheduling-while-atomic-swapper-0x00000103-0-cpu0-in-ts >>> http://e2e.ti.com/support/omap/f/849/t/250383.aspx >>> https://community.freescale.com/thread/330079 >>> >> -- 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.
