Hello Me Nee, Yes. I am having the same problem. How are you doing on this? Have you figured anything out?
I too am using the CAN interface on the BeagleBone Black device. Let me know, and I can update you with my findings if you still need help. On Thursday, November 13, 2014 12:41:48 PM UTC-5, Me Nee wrote: > > Background: my company is using beaglebone blacks in an industrial CAN > bus monitoring application. Our Linux guy quit in June, leaving me to > support this thing. Prior to June I had pretty much zero Linux > experience. Our kernel has custom modifications. One was provided by > Tower Tech (an Italian manufacturer of beaglebone CAN capes), to provide > support for CAN and the other was done by the guy that quit. It was a > modification to the kernel to support high speed serial clocks, as there > was a bug in the original kernel code when setting serial rates greater > than 230,400 baud (if I remember correctly). The base kernel we're working > off of is 2013-09-04, which from what I can gather is the latest official > Angstrom release. > > We're using the beaglebone in 2 different external hardware > configurations. One is with a "straight to AM3359 CAN" interface, and the > other is through a CAN-to-serial external (external to the beaglebone) > interface. The CAN-to-serial incarnation works flawlessly. The straight > to CAN version, we discovered, throws the same kernel panic over & > over when CAN traffic gets high. > > Our suite of programs that runs on the beaglebone includes two > networking-related daemons. One is to catch & react to network requests to > configure our equipment and the other is basically a UDP blaster to > broadcast data. I've found that disabling both of these daemons will > prevent the panic. If I only disable one of these programs (doesn't matter > which one), the panic still happens. > > Anyway, the panic references /net/core/dev.c line 3988 every time. What > I'm wondering is if anyone has seen something similar? Or can someone > maybe point me in the direction of fixing this? Seems that the issue is > likely due to the CAN specific features we got from the Tower Tech kernel, > but I'm hesitant to ask them because I know that my ex-colleague had > trouble communicating with them in the past. Given that the panic does not > occur when we use the indirect CAN-to-serial hardware, that's why I'm > suspicious of the Tower Tech kernel modifications. > > And also note that the panic happens all the time. The dump below > references our "can_mon" program, but it also happens when nothing is > running other than our (custom) daemons. > > The panic dump is below. > > [ 101.133958] ------------[ cut here ]------------ > [ 101.138802] kernel BUG at net/core/dev.c:3988! > [ 101.143440] Internal error: Oops - BUG: 0 [#1] SMP THUMB2 > [ 101.149074] Modules linked in: can_raw can c_can_platform c_can can_dev > iptable_nat nf_conntrack_ipv4 nf_d > efrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables g_multi > libcomposite rfcomm ircomm_tty ircomm i > rda hidp bluetooth rfkill > [ 101.171411] CPU: 0 Tainted: G W (3.8.13-bone53 #1) > [ 101.177689] PC is at __napi_complete+0x36/0x3c > [ 101.182334] LR is at napi_complete+0x1d/0x28 > [ 101.186785] pc : [<c03fa5ca>] lr : [<c03fa5ed>] psr: 400000b3 > [ 101.186785] sp : d902dd50 ip : 54638479 fp : 0000012c > [ 101.198775] r10: c0d12600 r9 : d902c000 r8 : c0d12608 > [ 101.204216] r7 : 00000001 r6 : 00000010 r5 : 40000013 r4 : dcb7eddc > [ 101.211027] r3 : 00000000 r2 : 00000000 r1 : dcb7eddc r0 : dcb7eddc > [ 101.217833] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA Thumb > Segment user > [ 101.225552] Control: 50c5387d Table: 9cacc019 DAC: 00000015 > [ 101.231544] Process can_mon (pid: 450, stack limit = 0xd902c240) > [ 101.237812] Stack: (0xd902dd50 to 0xd902e000) > [ 101.242361] dd40: dcb7eddc 40000013 > 00000010 dcb7e800 > [ 101.250900] dd60: dcb7ed40 bf8f476d dcb7eddc 00000010 df0c8010 df258010 > c0d1176c c0288173 > [ 101.259434] dd80: 00000000 dcb7eddc 00000001 00000010 c08020c0 c0d12608 > d902c000 c0d12600 > [ 101.267967] dda0: 0000012c c03fa65d 00000000 fffe7240 dc8c7440 00000001 > 00000003 0000000c > [ 101.276500] ddc0: c0802090 c080208c d902c000 c08858e4 00000037 c003466b > df00c740 df007bc0 > [ 101.285045] dde0: 00800000 00000100 0000000c 00000000 0000000a 00404100 > df007c10 d902c000 > [ 101.293582] de00: 00000037 00000000 d902de60 c08884bc fa2000d8 fa2000f8 > 00000037 c003493d > [ 101.302105] de20: c07fd728 c000cfdf fa200098 fa200040 fa2000b8 c00085d9 > c04a22c9 c04a22cc > [ 101.310630] de40: 60000033 ffffffff d902de94 dce76800 00000000 60000013 > dcec8409 c04a259b > [ 101.319164] de60: df258010 60000013 00000000 8a108a10 60000013 df2b9800 > 00000002 df258010 > [ 101.327695] de80: dce76800 00000000 60000013 dcec8409 00000039 d902dea8 > c04a22c9 c04a22cc > [ 101.336235] dea0: 60000033 ffffffff 00000000 c028015b c02800d9 00000003 > dcec8407 dce76400 > [ 101.344776] dec0: 14000000 df4e8240 c04d9028 dce76680 dce76800 c0270161 > d902df80 dce76994 > [ 101.353304] dee0: dcec8400 d902c000 dcdd4740 00000000 df50ce00 c004f3dd > dce769a4 dce769a4 > [ 101.361842] df00: fffffffb b6fb0000 0000000a dce76800 00000000 d902c000 > df4e8240 0000000a > [ 101.370375] df20: c0270065 c026e285 0000000a dcdd4740 00000001 df4e8240 > b6fb0000 0000000a > [ 101.378909] df40: d902c000 d902df80 0000000a 00000000 00000000 c00b8887 > 00000000 00000000 > [ 101.387431] df60: beefe5fc 00000000 00000000 df4e8240 00000000 b6fb0000 > 0000000a c00b8a8d > [ 101.395967] df80: 00000000 00000000 d902c000 0000000a b6fb0000 b6dbfa80 > 00000004 c000c8e4 > [ 101.404500] dfa0: d902c000 c000c741 0000000a b6fb0000 00000001 b6fb0000 > 0000000a 00000000 > [ 101.413038] dfc0: 0000000a b6fb0000 b6dbfa80 00000004 0000000a 0000000a > b6fb0000 00000000 > [ 101.421560] dfe0: 00000000 beefe14c b6cfbb2c b6d4e30c 600f0010 00000001 > 00000000 00000000 > [ 101.430104] [<c03fa5ca>] (__napi_complete+0x36/0x3c) from [<00000010>] > (0x10) > [ 101.437555] Code: 3108 bc30 f636 b815 (de02) de02 > [ 101.442565] ---[ end trace 59f323e922c98490 ]--- > [ 101.447382] Kernel panic - not syncing: Fatal exception in interrupt > [ 101.454008] drm_kms_helper: panic occurred, switching back to text > console > -- 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.