C-Can or Other SocketCAN Issue

C-Can or Other SocketCAN Issue

[Harrington, Sean M.]

Hello all,

I'm having some fairly odd  issues with can-utils and SocketCAN and could use some help if anyone  has a bit of time to spare. Specifically, I'm trying to use SocketCAN on  a Beaglebone Black to read in and write CAN messages to a CAN bus using similar methods to how the can-utils'  "candump" works. My issues do not seem to occur when using the cangen  tool to load a bus but instead when I use a different method of  generating messages and loading the bus (mainly a Kvaser Eagle). Although messages are intercepted with no issues for a short  amount of time, a system crash will then occur soon after when using the  Beaglebone Black. This crash happens with running both the can-utils  "candump" tool and when running my personal CAN reading software. The issue can usually be replicated easily by generating enough messages  to fill the entire bus. However, I do not think the issue is caused by  bus load alone since sometimes everything will run well at full bus load  and at other times it will crash with only half the bus being filled. Using a serial connection, I am able to get  the following system message before the entire Beaglebone freezes up:

[  864.029581] BUG: soft lockup - CPU#0 stuck for 22s! [main:1119] 
[  864.036222] BUG: scheduling while atomic: main/1119/0x40010100 
[  864.045930] Kernel panic - not syncing: softlockup: hung tasks 
[  864.052066] [<c0013598>] (unwind_backtrace+0x0/0xe0) from [<c061b230>] (panic+0x84/0x1e0) 
[  864.060643] [<c061b230>] (panic+0x84/0x1e0) from [<c0093200>] (watchdog_timer_fn+0x120/0x164) 
[  864.069587] [<c0093200>] (watchdog_timer_fn+0x120/0x164) from [<c005cf2c>] (__run_hrtimer+0xec/0x1e4) 
[  864.079253] [<c005cf2c>] (__run_hrtimer+0xec/0x1e4) from [<c005d960>] (hrtimer_interrupt+0x108/0x25c) 
[  864.088924] [<c005d960>] (hrtimer_interrupt+0x108/0x25c) from [<c00247c0>] (omap2_gp_timer_interrupt+0x20/0x30) 
[  864.099501] [<c00247c0>] (omap2_gp_timer_interrupt+0x20/0x30)  from [<c0093c20>] (handle_irq_event_percpu+0x60/0x214) 
[  864.110530] [<c0093c20>] (handle_irq_event_percpu+0x60/0x214) from [<c0093e10>] (handle_irq_event+0x3c/0x5c) 
[  864.120832] [<c0093e10>] (handle_irq_event+0x3c/0x5c) from [<c0096810>] (handle_level_irq+0xd4/0xec) 
[  864.130405] [<c0096810>] (handle_level_irq+0xd4/0xec) from [<c0093658>] (generic_handle_irq+0x20/0x30) 
[  864.140158] [<c0093658>] (generic_handle_irq+0x20/0x30) from [<c000e15c>] (handle_IRQ+0x64/0x8c) 
[  864.149366] [<c000e15c>] (handle_IRQ+0x64/0x8c) from [<c0008760>] (omap3_intc_handle_irq+0x60/0x74) 
[  864.158847] [<c0008760>] (omap3_intc_handle_irq+0x60/0x74) from [<c0623280>] (__irq_svc+0x40/0x50) 
[  864.168230] Exception stack(0xde29fd40 to 0xde29fd88) 
[  864.173524] fd40: 00008000 00000044 fa1d0000 fa1d00b0 de31d540 00000010 00000022 c099c3e4 
[  864.182094] fd60: de31d000 c09cb80c c09cd640 c094c0c0 00745a2f de29fd88 bf007014 bf00e018 
[  864.190658] fd80: 40000113 ffffffff 
[  864.194320] [<c0623280>] (__irq_svc+0x40/0x50) from  [<bf00e018>] (c_can_plat_read_reg_aligned_to_16bit+0x18/0x24  [c_can_platform]) 
[  864.206628] [<bf00e018>]  (c_can_plat_read_reg_aligned_to_16bit+0x18/0x24 [c_can_platform]) from  [<bf007014>] (c_can_read_reg32+0x14/0x30 [c_can]) 
[  864.220299] [<bf007014>] (c_can_read_reg32+0x14/0x30 [c_can]) from [<bf008158>] (c_can_poll+0x66c/0x818 [c_can]) 
[  864.230970] [<bf008158>] (c_can_poll+0x66c/0x818 [c_can]) from [<c053b780>] (net_rx_action+0x6c/0x1bc) 
[  864.240727] [<c053b780>] (net_rx_action+0x6c/0x1bc) from [<c0042d30>] (__do_softirq+0xfc/0x22c) 
[  864.249845] [<c0042d30>] (__do_softirq+0xfc/0x22c) from [<c0043120>] (irq_exit+0x44/0x84) 
[  864.258417] [<c0043120>] (irq_exit+0x44/0x84) from [<c000e160>] (handle_IRQ+0x68/0x8c) 
[  864.266715] [<c000e160>] (handle_IRQ+0x68/0x8c) from [<c0008760>] (omap3_intc_handle_irq+0x60/0x74) 
[  864.276195] [<c0008760>] (omap3_intc_handle_irq+0x60/0x74) from [<c0623280>] (__irq_svc+0x40/0x50) 
[  864.285578] Exception stack(0xde29fe70 to 0xde29feb8) 
[  864.290869] fe60:                                     df259010 df259010 04e404e3 00000001 
[  864.299438] fe80: 60000013 00000000 00000007 00000000 de698407 df259010 de5b8800 a0000013 
[  864.308006] fea0: 00000c1b de29feb8 c0622f70 c0622f74 60000013 ffffffff 
[  864.314940] [<c0623280>] (__irq_svc+0x40/0x50) from [<c0622f74>] (_raw_spin_unlock_irqrestore+0x10/0x14) 
[  864.324877] [<c0622f74>] (_raw_spin_unlock_irqrestore+0x10/0x14) from [<c035a3b4>] (uart_write+0xc8/0xd4) 
[  864.334906] [<c035a3b4>] (uart_write+0xc8/0xd4) from [<c0344e2c>] (n_tty_write+0x238/0x394) 
[  864.343660] [<c0344e2c>] (n_tty_write+0x238/0x394) from [<c034236c>] (tty_write+0x184/0x214) 
[  864.352505] [<c034236c>] (tty_write+0x184/0x214) from [<c00f5c00>] (vfs_write+0xa8/0x178) 
[  864.361077] [<c00f5c00>] (vfs_write+0xa8/0x178) from [<c00f5ee0>] (sys_write+0x38/0x64) 
[  864.369466] [<c00f5ee0>] (sys_write+0x38/0x64) from [<c000d880>] (ret_fast_syscall+0x0/0x30) 
[  864.378309] drm_kms_helper: panic occurred, switching back to text console 

I'm thinking this might be a  kernel or driver issue but this problem reaches far beyond my knowledge.  Any feedback would be greatly appreciated. I wouldn't mind trying to  sort through and fix this problem myself if I can get a bit of guidance on what needs to be done. I can't be the  only one using a Beaglebone Black to do CAN work so I must have  something set up wrong.

The Beaglebone Black should be running Ubuntu 13.04. I'm willing to  rebuild the kernel and install the latest distribution if I can some  feedback on the proper method to get SocketCAN functional and if it  would most likely resolve the issue. 

Thanks for your time,
Sean Harrington
                

 

Re: C-Can or Other SocketCAN Issue

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 6370 bytes --]

On 03/03/2014 05:26 PM, Harrington, Sean M. wrote:
> I'm having some fairly odd  issues with can-utils and SocketCAN and
> could use some help if anyone  has a bit of time to spare.
> Specifically, I'm trying to use SocketCAN on  a Beaglebone Black to
> read in and write CAN messages to a CAN bus using similar methods to
> how the can-utils'  "candump" works. My issues do not seem to occur
> when using the cangen  tool to load a bus but instead when I use a
> different method of  generating messages and loading the bus (mainly
> a Kvaser Eagle). Although messages are intercepted with no issues for
> a short  amount of time, a system crash will then occur soon after
> when using the  Beaglebone Black. This crash happens with running
> both the can-utils  "candump" tool and when running my personal CAN
> reading software. The issue can usually be replicated easily by
> generating enough messages  to fill the entire bus. However, I do not
> think the issue is caused by  bus load alone since sometimes
> everything will run well at full bus load  and at other times it will
> crash with only half the bus being filled. Using a serial connection,
> I am able to get  the following system message before the entire
> Beaglebone freezes up:
> 
> [  864.029581] BUG: soft lockup - CPU#0 stuck for 22s! [main:1119] 
> [  864.036222] BUG: scheduling while atomic: main/1119/0x40010100 
> [  864.045930] Kernel panic - not syncing: softlockup: hung tasks 
> [  864.052066] [<c0013598>] (unwind_backtrace+0x0/0xe0) from [<c061b230>] (panic+0x84/0x1e0) 
> [  864.060643] [<c061b230>] (panic+0x84/0x1e0) from [<c0093200>] (watchdog_timer_fn+0x120/0x164) 
> [  864.069587] [<c0093200>] (watchdog_timer_fn+0x120/0x164) from [<c005cf2c>] (__run_hrtimer+0xec/0x1e4) 
> [  864.079253] [<c005cf2c>] (__run_hrtimer+0xec/0x1e4) from [<c005d960>] (hrtimer_interrupt+0x108/0x25c) 
> [  864.088924] [<c005d960>] (hrtimer_interrupt+0x108/0x25c) from [<c00247c0>] (omap2_gp_timer_interrupt+0x20/0x30) 
> [  864.099501] [<c00247c0>] (omap2_gp_timer_interrupt+0x20/0x30)  from [<c0093c20>] (handle_irq_event_percpu+0x60/0x214) 
> [  864.110530] [<c0093c20>] (handle_irq_event_percpu+0x60/0x214) from [<c0093e10>] (handle_irq_event+0x3c/0x5c) 
> [  864.120832] [<c0093e10>] (handle_irq_event+0x3c/0x5c) from [<c0096810>] (handle_level_irq+0xd4/0xec) 
> [  864.130405] [<c0096810>] (handle_level_irq+0xd4/0xec) from [<c0093658>] (generic_handle_irq+0x20/0x30) 
> [  864.140158] [<c0093658>] (generic_handle_irq+0x20/0x30) from [<c000e15c>] (handle_IRQ+0x64/0x8c) 
> [  864.149366] [<c000e15c>] (handle_IRQ+0x64/0x8c) from [<c0008760>] (omap3_intc_handle_irq+0x60/0x74) 
> [  864.158847] [<c0008760>] (omap3_intc_handle_irq+0x60/0x74) from [<c0623280>] (__irq_svc+0x40/0x50) 
> [  864.168230] Exception stack(0xde29fd40 to 0xde29fd88) 
> [  864.173524] fd40: 00008000 00000044 fa1d0000 fa1d00b0 de31d540 00000010 00000022 c099c3e4 
> [  864.182094] fd60: de31d000 c09cb80c c09cd640 c094c0c0 00745a2f de29fd88 bf007014 bf00e018 
> [  864.190658] fd80: 40000113 ffffffff 
> [  864.194320] [<c0623280>] (__irq_svc+0x40/0x50) from  [<bf00e018>] (c_can_plat_read_reg_aligned_to_16bit+0x18/0x24  [c_can_platform]) 
> [  864.206628] [<bf00e018>]  (c_can_plat_read_reg_aligned_to_16bit+0x18/0x24 [c_can_platform]) from  [<bf007014>] (c_can_read_reg32+0x14/0x30 [c_can]) 
> [  864.220299] [<bf007014>] (c_can_read_reg32+0x14/0x30 [c_can]) from [<bf008158>] (c_can_poll+0x66c/0x818 [c_can]) 
> [  864.230970] [<bf008158>] (c_can_poll+0x66c/0x818 [c_can]) from [<c053b780>] (net_rx_action+0x6c/0x1bc) 
> [  864.240727] [<c053b780>] (net_rx_action+0x6c/0x1bc) from [<c0042d30>] (__do_softirq+0xfc/0x22c) 
> [  864.249845] [<c0042d30>] (__do_softirq+0xfc/0x22c) from [<c0043120>] (irq_exit+0x44/0x84) 
> [  864.258417] [<c0043120>] (irq_exit+0x44/0x84) from [<c000e160>] (handle_IRQ+0x68/0x8c) 
> [  864.266715] [<c000e160>] (handle_IRQ+0x68/0x8c) from [<c0008760>] (omap3_intc_handle_irq+0x60/0x74) 
> [  864.276195] [<c0008760>] (omap3_intc_handle_irq+0x60/0x74) from [<c0623280>] (__irq_svc+0x40/0x50) 
> [  864.285578] Exception stack(0xde29fe70 to 0xde29feb8) 
> [  864.290869] fe60:                                     df259010 df259010 04e404e3 00000001 
> [  864.299438] fe80: 60000013 00000000 00000007 00000000 de698407 df259010 de5b8800 a0000013 
> [  864.308006] fea0: 00000c1b de29feb8 c0622f70 c0622f74 60000013 ffffffff 
> [  864.314940] [<c0623280>] (__irq_svc+0x40/0x50) from [<c0622f74>] (_raw_spin_unlock_irqrestore+0x10/0x14) 
> [  864.324877] [<c0622f74>] (_raw_spin_unlock_irqrestore+0x10/0x14) from [<c035a3b4>] (uart_write+0xc8/0xd4) 
> [  864.334906] [<c035a3b4>] (uart_write+0xc8/0xd4) from [<c0344e2c>] (n_tty_write+0x238/0x394) 
> [  864.343660] [<c0344e2c>] (n_tty_write+0x238/0x394) from [<c034236c>] (tty_write+0x184/0x214) 
> [  864.352505] [<c034236c>] (tty_write+0x184/0x214) from [<c00f5c00>] (vfs_write+0xa8/0x178) 
> [  864.361077] [<c00f5c00>] (vfs_write+0xa8/0x178) from [<c00f5ee0>] (sys_write+0x38/0x64) 
> [  864.369466] [<c00f5ee0>] (sys_write+0x38/0x64) from [<c000d880>] (ret_fast_syscall+0x0/0x30) 
> [  864.378309] drm_kms_helper: panic occurred, switching back to text console 
> 
> I'm thinking this might be a  kernel or driver issue but this problem
> reaches far beyond my knowledge.  Any feedback would be greatly
> appreciated. I wouldn't mind trying to  sort through and fix this
> problem myself if I can get a bit of guidance on what needs to be
> done. I can't be the  only one using a Beaglebone Black to do CAN
> work so I must have  something set up wrong.

It's probably a driver issue. From the above backtrace it might be the
problem that the driver loops in the c_can_poll() function.

> The Beaglebone Black should be running Ubuntu 13.04. I'm willing to
> rebuild the kernel and install the latest distribution if I can some
> feedback on the proper method to get SocketCAN functional and if it
> would most likely resolve the issue.

Which Kernel version are you using?

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

RE: C-Can or Other SocketCAN Issue

[Harrington, Sean M.]

>> The Beaglebone Black should be running Ubuntu 13.04. I'm willing to
>> rebuild the kernel and install the latest distribution if I can some
>> feedback on the proper method to get SocketCAN functional and if it
>> would most likely resolve the issue.

>Which Kernel version are you using?

Here is what uname -a returned:
Linux arm 3.8.13-bone35 #2 SMP Sat Jan 4 10:18:07 PST 2014 armv7l armv7l armv7l GNU/Linux

cat /proc/version returned:
Linux version 3.8.13-bone35 (root@ubuntu) (gcc version 4.7.3 20130328 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) ) #2 SMP Sat Jan 4 10:18:07 PST 2014

Sean

      

Re: C-Can or Other SocketCAN Issue

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

On 03/03/2014 06:31 PM, Harrington, Sean M. wrote:
>>> The Beaglebone Black should be running Ubuntu 13.04. I'm willing to
>>> rebuild the kernel and install the latest distribution if I can some
>>> feedback on the proper method to get SocketCAN functional and if it
>>> would most likely resolve the issue.
> 
>> Which Kernel version are you using?
> 
> Here is what uname -a returned:
> Linux arm 3.8.13-bone35 #2 SMP Sat Jan 4 10:18:07 PST 2014 armv7l armv7l armv7l GNU/Linux

Your kernel is probably missing the following patch:

> 5d0f801 can: c_can: Fix RX message handling, handle lost message before EOB

You should update to at least the newest v3.10.x or v3.13.x. You might
also cherry-pick the above patch into you kernel.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 242 bytes --]

Re: C-Can or Other SocketCAN Issue

[Oliver Hartkopp]

On 03.03.2014 20:16, Marc Kleine-Budde wrote:
> On 03/03/2014 06:31 PM, Harrington, Sean M. wrote:
>>>> The Beaglebone Black should be running Ubuntu 13.04. I'm willing to
>>>> rebuild the kernel and install the latest distribution if I can some
>>>> feedback on the proper method to get SocketCAN functional and if it
>>>> would most likely resolve the issue.
>>
>>> Which Kernel version are you using?
>>
>> Here is what uname -a returned:
>> Linux arm 3.8.13-bone35 #2 SMP Sat Jan 4 10:18:07 PST 2014 armv7l armv7l armv7l GNU/Linux
> 
> Your kernel is probably missing the following patch:
> 
>> 5d0f801 can: c_can: Fix RX message handling, handle lost message before EOB
> 
> You should update to at least the newest v3.10.x or v3.13.x. You might
> also cherry-pick the above patch into you kernel.

Indeed two patches made it into linux-3.10.y stable:

http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/net/can/c_can?h=linux-3.10.y

- "can: c_can: Fix RX message handling, handle lost message before EOB"
- "can: c_can: don't call pm_runtime_get_sync() from interrupt context"

So applying these patches ...

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=5d0f801a2ccec3b1fdabc3392c8d99ed0413d216
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=e35d46adc49b469fd92bdb64fea8af93640e6651

to the 3.8.13 tree could help :-)

Tnx,
Oliver

RE: C-Can or Other SocketCAN Issue

[Harrington, Sean M.]

On 03.03.2014 20:16, Marc Kleine-Budde wrote:
> On 03/03/2014 06:31 PM, Harrington, Sean M. wrote:
>>>>> The Beaglebone Black should be running Ubuntu 13.04. I'm willing to
>>>>> rebuild the kernel and install the latest distribution if I can some
>>>>> feedback on the proper method to get SocketCAN functional and if it
>>>>> would most likely resolve the issue.
>>>
>>>> Which Kernel version are you using?
>>>
>>> Here is what uname -a returned:
>>> Linux arm 3.8.13-bone35 #2 SMP Sat Jan 4 10:18:07 PST 2014 armv7l armv7l armv7l GNU/Linux
>>
>> Your kernel is probably missing the following patch:
>>
>>> 5d0f801 can: c_can: Fix RX message handling, handle lost message before EOB
>>
>>You should update to at least the newest v3.10.x or v3.13.x. You might
>> also cherry-pick the above patch into you kernel.

>Indeed two patches made it into linux-3.10.y stable:
>
>http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/net/can/c_can?h=linux-3.10.y
>
> - "can: c_can: Fix RX message handling, handle lost message before EOB"
> - "can: c_can: don't call pm_runtime_get_sync() from interrupt context"
>
> So applying these patches ...
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=5d0f801a2ccec3b1fdabc3392c8d99ed0413d216
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=e35d46adc49b469fd92bdb64fea8af93640e6651
>
> to the 3.8.13 tree could help :-)

I appreciate the help everyone. This looks promising. On a side note though I've never done a kernel patch. Should I do a complete patch or is there a way for me to patch just the c_can file? I'm also assuming any of the linux-3.10.x patches will work such as this one: ftp://ftp.kernel.org/pub/linux/kernel/v3.x/linux-3.10.32.tar.xz

Perhaps the applying patches documentation is throwing me off a bit. I thought patching 3.8 files to 3.10 wouldn't work since the fixes are incremental and 3.X to 3.Y is a large jump? 

Thanks,
Sean

Re: C-Can or Other SocketCAN Issue

[Oliver Hartkopp]

On 03.03.2014 21:48, Harrington, Sean M. wrote:
> On 03.03.2014 20:16, Marc Kleine-Budde wrote:
>> On 03/03/2014 06:31 PM, Harrington, Sean M. wrote:
>>>>>> The Beaglebone Black should be running Ubuntu 13.04. I'm willing to
>>>>>> rebuild the kernel and install the latest distribution if I can some
>>>>>> feedback on the proper method to get SocketCAN functional and if it
>>>>>> would most likely resolve the issue.
>>>>
>>>>> Which Kernel version are you using?
>>>>
>>>> Here is what uname -a returned:
>>>> Linux arm 3.8.13-bone35 #2 SMP Sat Jan 4 10:18:07 PST 2014 armv7l armv7l armv7l GNU/Linux
>>>
>>> Your kernel is probably missing the following patch:
>>>
>>>> 5d0f801 can: c_can: Fix RX message handling, handle lost message before EOB
>>>
>>> You should update to at least the newest v3.10.x or v3.13.x. You might
>>> also cherry-pick the above patch into you kernel.
> 
>> Indeed two patches made it into linux-3.10.y stable:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/net/can/c_can?h=linux-3.10.y
>>
>> - "can: c_can: Fix RX message handling, handle lost message before EOB"
>> - "can: c_can: don't call pm_runtime_get_sync() from interrupt context"
>>
>> So applying these patches ...
>>
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=5d0f801a2ccec3b1fdabc3392c8d99ed0413d216
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=e35d46adc49b469fd92bdb64fea8af93640e6651
>>
>> to the 3.8.13 tree could help :-)
> 
> I appreciate the help everyone. This looks promising. On a side note though I've never done a kernel patch. Should I do a complete patch or is there a way for me to patch just the c_can file? I'm also assuming any of the linux-3.10.x patches will work such as this one: ftp://ftp.kernel.org/pub/linux/kernel/v3.x/linux-3.10.32.tar.xz
> 
> Perhaps the applying patches documentation is throwing me off a bit. I thought patching 3.8 files to 3.10 wouldn't work since the fixes are incremental and 3.X to 3.Y is a large jump? 

Hello Sean,

if you have your 3.8.13-bone35 kernel on your box and you managed to compile
this kernel on your own and successfully booted your self compiled kernel,
then it's no problem at all.

In the URLs above there's a link called "(patch)" which allows you to
download JUST THIS specific patch, which indeed only patches c_can.c to
fix the potential issue.

Download the above patch to a file:

E.g. use "Save Link as ..." for the "(patch)"
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=5d0f801a2ccec3b1fdabc3392c8d99ed0413d216

which creates a file 5d0f801a2ccec3b1fdabc3392c8d99ed0413d216.patch

Then go to your linux 3.8.13-bone35 source tree (where you can see the
MAINTAINERS file in the directory) and say:

patch -p1 < ../Downloads/5d0f801a2ccec3b1fdabc3392c8d99ed0413d216.patch

Then your c_can.c file is fixed.

Recompile the kernel and boot the kernel (and the updated modules!).

Regards,
Oliver

RE: C-Can or Other SocketCAN Issue

[Harrington, Sean M.]

This has fixed the issue I was experiencing. Thanks for the help with locating the patch and the guide.

Sean