If you are using the CAN device and the c_can driver, then implementing the kernel mod and re-building/re-installing would seem to be your only option.
If you need to use CAN and can use a USB-to-CAN adapter, or some other serial-to-CAN adapter, then maybe you could get around this problem. On Friday, December 12, 2014 8:35:03 AM UTC-5, Jean-Pierre Aulas wrote: > > Hello, thanks for your reply, is there another way (more simple than > rebuilt) for this fix ? > Hereunder trace with another problem with mysql : > (Linux BBB4 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l > GNU/Linux) > > debian@larnau:~$ [ 543.774398] BUG: scheduling while atomic: rs:main > Q:Reg/653/0x40000100 > [ 551.739092] BUG: scheduling while atomic: mysqld/1766/0x40000100 > [ 582.732825] BUG: scheduling while atomic: mysqld/1766/0x40000100 > [ 582.759827] ------------[ cut here ]------------ > [ 582.764775] kernel BUG at net/core/dev.c:3988! > [ 582.769500] Internal error: Oops - BUG: 0 [#1] SMP THUMB2 > [ 582.775236] Modules linked in: can_raw can c_can_platform c_can can_dev > mt7601Usta(O) > [ 582.783670] CPU: 0 Tainted: G W O (3.8.13-bone50 #1) > [ 582.790084] PC is at __napi_complete+0x36/0x3c > [ 582.794820] LR is at napi_complete+0x1d/0x28 > [ 582.799368] pc : [<c0423c3a>] lr : [<c0423c5d>] psr: 400000b3 > [ 582.799368] sp : de51deb0 ip : 00000000 fp : c0d36608 > [ 582.811577] r10: c08260c0 r9 : c0d36600 r8 : 0000012c > [ 582.817137] r7 : 00000010 r6 : 00000001 r5 : 40000013 r4 : de68d5dc > [ 582.824078] r3 : 00000000 r2 : 00000000 r1 : de68d5dc r0 : de68d5dc > [ 582.831019] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA Thumb > Segment user > [ 582.838884] Control: 50c5387d Table: 9e664019 DAC: 00000015 > [ 582.844998] Process mysqld (pid: 1766, stack limit = 0xde51c240) > [ 582.851381] Stack: (0xde51deb0 to 0xde51e000) > [ 582.856029] dea0: de68d5dc 40000013 > 00000010 de68d000 > [ 582.864737] dec0: de68d540 bf8c0609 de68d5dc 00000010 fa200098 fa2000b8 > 00000001 ebbdebbc > [ 582.873442] dee0: de51c000 de68d5dc 00000001 de51c000 00000010 0000012c > c0d36600 c08260c0 > [ 582.882146] df00: c0d36608 c0423cd1 00000002 0002356e de51df10 de51df10 > de51dfb0 00000001 > [ 582.890853] df20: c082608c de51c000 00000043 00000003 b709e068 b709e230 > 0000000c c0034f0f > [ 582.899566] df40: 00000008 00000043 00000100 00000000 00000009 00400040 > df008650 de51c000 > [ 582.908276] df60: 00000000 00000043 00000043 de51dfb0 b709e068 b709e230 > a676a328 c0035205 > [ 582.916989] df80: c0821728 c000d0e3 fa200098 fa2000b8 fa2000d8 c00085a9 > b6cbefbe 80000030 > [ 582.925700] dfa0: ffffffff 00000020 000000c8 c04ceca9 258fc214 b4d59e20 > b4d59ebe a676a328 > [ 582.934409] dfc0: 00000031 a676a32c 36b96c00 00000020 000000c8 b709e068 > b709e230 a676a328 > [ 582.943115] dfe0: b6fcdfe4 a676a2e8 b6ba124b b6cbefbe 80000030 ffffffff > 00000000 00000000 > [ 582.951839] [<c0423c3a>] (__napi_complete+0x36/0x3c) from [<00000010>] > (0x10) > [ 582.959435] Code: 3108 bc30 f62c bfe3 (de02) de02 > [ 582.964540] ---[ end trace a72764883bbe4627 ]--- > [ 582.969459] Kernel panic - not syncing: Fatal exception in interrupt > > regards > Jean-Pierre Aulas > > On Tuesday, December 2, 2014 11:02:15 PM UTC+1, beagler001 wrote: >> >> Hello again... >> >> Never mind any of the stuff I previously mentioned regarding changing of >> the kernel config parameters. The problem is rooted in my original comment >> about the c_can driver. There is a patch that exists that solves this >> problem. Unfortunately, it was inserted into the mainline kernel stream >> later than the 3.8+ branch we are using on BeagleBone Black; and therefore, >> the fix is not included in our kernel source. Take a look at this: >> >> http://lists.openwall.net/netdev/2013/11/27/64 >> >> If you have acquainted yourself with building the kernel for BBB, I would >> suggest manually editing that c_can.c file with the changes shown in the >> link above, rebuilding, and re-installing. That should fix your problem. It >> did for me. >> >> Good luck. >> >> On Monday, December 1, 2014 11:13:19 AM UTC-5, beagler001 wrote: >>> >>> >>> RCN's kernel is the kernel source that I am using as well. If you change >>> into that directory, you can run a rebuild script by typing >>> "tools/rebuild.sh". Invoking that script automatically pops up a window >>> showing all the kernel config parameters. The number of parameters and >>> finding the exact ones to match what I listed above is rather daunting. >>> What I recommend is to view the default kernel config file and check if you >>> are using the same config as me (probably not). default config file should >>> be named "defconfig" and should be stored within the patches directory. >>> >>> On Monday, December 1, 2014 11:05:53 AM UTC-5, Me Nee wrote: >>>> >>>> The only reason I know we're using a custom kernel is because our >>>> former Linux guy told me so. Never recompiled a kernel before but I have >>>> a >>>> cursory grasp of what's involved. >>>> >>>> Former coworker's linux laptop has a folder named "Robert C Nelson" >>>> that contains what seems to be the custom kernel mod to fix the UART speed >>>> issue. I'll start poking around in there to see if I can figure it all >>>> out. >>>> >>>> And yes, that does help. I do appreciate it, thanks for your patience. >>>> >>> -- 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.
