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 [email protected]. For more options, visit https://groups.google.com/d/optout.
