mcp251x: mcp2515 stops receiving

mcp251x: mcp2515 stops receiving

[Rost, Martin]

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

Hello List,

We are using the MCP2515 on a tegra3 (Toradex Colibri T30, to be precise) and every now and then the driver just stops.
The interrupt line stays low, and the driver does not collect the data.
From my investigations I conclude, that the MCP lowers the IRQ line before the value in the INTF register is  updated, 
so when the driver reads the INTF register, a 0 is returned, and the driver assumes nothing has to be done.
 
(
Chances are I'm misinterpreting my observations. 
It might as well be that the call to the IST is suspended, because the previous instance is still running and processes the new irq cause as well, 
so the next call will not see the signal at all. 
But in that case the driver should not stop with the irq line held low, or should it?
)
 
We are using the 3.1.10 kernel from the toradex repository, which should be in sync with the nvidia tegra4linux one.
I have browsed through the patches between 3.1.10 and head and have applied all those that seem to address issues and don't interfere with the 3.1.10 kernel structures, but to no avail.
In fact, these patches have been applied:
cab32f39dcc5b35db96497dc0a026b5dea76e4e7
db388d6460ffa53b3b38429da6f70a913f89b048
ae5d589e5f9f3217656ada632869968178886ac6
b1ef05a5a20afe50d4188a5b59579bd140758cf0
I have changed the IST loop to poll the INTF register beforehand for up to 10ms, and now the driver seems a lot more stable in our environment.
Has someone seen this issue before, or can confirm I am not completely off the path?
 
On a side note, I have a second reason that makes the driver stop, which has to do with smp somehow.
Disabling core1..3 keeps that from happening, but the problem addressed above would persist.
Switching the irq to a different core by setting /proc/irq/91/smp_affinity does not trigger this problem.
Any insights or starting point on this would also be greatly appreciated.
 
Best regards
Martin 

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2015 bytes --]

Re: mcp251x: mcp2515 stops receiving

[Oliver Hartkopp]

Hi Martin,

I'm not really deep in any of these MCP251x and SPI topic but I know from an
intern who was using the Raspberry Pi together with a MCP2515 that he tried a
different driver (mcp2515 instead of mcp251x) and also a SPI low latency patch
which seems to enable some DMA functionality in the Raspberry Pi:

	http://elinux.org/RPi_CANBus

Don't know what of these tweaks should go into mainline as I personally do not
have any experiences with this stuff.

Maybe it helps in your environment.

Btw. I did not want to prevent others (with more experiences on this mcp251x
topic) to answer your question in a more specific way ;-)

Regards,
Oliver


On 21.03.2014 13:40, Rost, Martin wrote:
> Hello List,
> 
> We are using the MCP2515 on a tegra3 (Toradex Colibri T30, to be precise) and every now and then the driver just stops.
> The interrupt line stays low, and the driver does not collect the data.
> From my investigations I conclude, that the MCP lowers the IRQ line before the value in the INTF register is  updated, 
> so when the driver reads the INTF register, a 0 is returned, and the driver assumes nothing has to be done.
>  
> (
> Chances are I'm misinterpreting my observations. 
> It might as well be that the call to the IST is suspended, because the previous instance is still running and processes the new irq cause as well, 
> so the next call will not see the signal at all. 
> But in that case the driver should not stop with the irq line held low, or should it?
> )
>  
> We are using the 3.1.10 kernel from the toradex repository, which should be in sync with the nvidia tegra4linux one.
> I have browsed through the patches between 3.1.10 and head and have applied all those that seem to address issues and don't interfere with the 3.1.10 kernel structures, but to no avail.
> In fact, these patches have been applied:
> cab32f39dcc5b35db96497dc0a026b5dea76e4e7
> db388d6460ffa53b3b38429da6f70a913f89b048
> ae5d589e5f9f3217656ada632869968178886ac6
> b1ef05a5a20afe50d4188a5b59579bd140758cf0
> I have changed the IST loop to poll the INTF register beforehand for up to 10ms, and now the driver seems a lot more stable in our environment.
> Has someone seen this issue before, or can confirm I am not completely off the path?
>  
> On a side note, I have a second reason that makes the driver stop, which has to do with smp somehow.
> Disabling core1..3 keeps that from happening, but the problem addressed above would persist.
> Switching the irq to a different core by setting /proc/irq/91/smp_affinity does not trigger this problem.
> Any insights or starting point on this would also be greatly appreciated.
>  
> Best regards
> Martin 
> 

Re: mcp251x: mcp2515 stops receiving

[John Whitmore]

Sorry Martin just catching up with this list.

On Fri, Mar 21, 2014 at 12:40:30PM +0000, Rost, Martin wrote:
> Hello List,
> 
> We are using the MCP2515 on a tegra3 (Toradex Colibri T30, to be precise) and every now and then the driver just stops.
> The interrupt line stays low, and the driver does not collect the data.
> From my investigations I conclude, that the MCP lowers the IRQ line before the value in the INTF register is  updated, 
> so when the driver reads the INTF register, a 0 is returned, and the driver assumes nothing has to be done.
>  

What you have described is something that I've been getting with the
MCP2515. I do have the MCP2515 connected on the RPi, but I've not been using
that setup for a few weeks. I'm currently working with a MCP2515 connected to
a Microchip PIC24 and cannot get the MCP2515 to work in Interrupt mode as it
triggers an Interrupt but the Flags are zero indicating that there is no
interrupt so my driver does nothing and the interrupt line is locked low. I
can only get the 2515 to work in polled mode. 

All that is of no help to you but I'll have a look at my RPi setup and really
test it on a network and see if I can recreate that problem there. 
 

> (
> Chances are I'm misinterpreting my observations. 
> It might as well be that the call to the IST is suspended, because the previous instance is still running and processes the new irq cause as well, 
> so the next call will not see the signal at all. 
> But in that case the driver should not stop with the irq line held low, or should it?
> )
>  
> We are using the 3.1.10 kernel from the toradex repository, which should be in sync with the nvidia tegra4linux one.
> I have browsed through the patches between 3.1.10 and head and have applied all those that seem to address issues and don't interfere with the 3.1.10 kernel structures, but to no avail.
> In fact, these patches have been applied:
> cab32f39dcc5b35db96497dc0a026b5dea76e4e7
> db388d6460ffa53b3b38429da6f70a913f89b048
> ae5d589e5f9f3217656ada632869968178886ac6
> b1ef05a5a20afe50d4188a5b59579bd140758cf0
> I have changed the IST loop to poll the INTF register beforehand for up to 10ms, and now the driver seems a lot more stable in our environment.
> Has someone seen this issue before, or can confirm I am not completely off the path?
>  
> On a side note, I have a second reason that makes the driver stop, which has to do with smp somehow.
> Disabling core1..3 keeps that from happening, but the problem addressed above would persist.
> Switching the irq to a different core by setting /proc/irq/91/smp_affinity does not trigger this problem.
> Any insights or starting point on this would also be greatly appreciated.
>  
> Best regards
> Martin 

RE: mcp251x: mcp2515 stops receiving

[Mylene Josserand]

Hi everyone,


I have previously posted on this list because of a freeze problem while using the MCP2515 + imx27 : http://marc.info/?l=linux-can&m=136559970919837&w=2 and http://marc.info/?l=linux-can&m=136559970919837&w=2


We find a "solution" of this freeze issue with old kernel 2.6.32.
I did not test it in newer kernel and I did not know the impact on other devices but for the MCP2515 (that is the only device on our SPI bus.. with many devices, maybe, it is not a good solution), it works. I ran CAN simulation during 2 weeks and it did not freeze anymore.

The solution to this issue is linked to SPI imx driver. I have checked and sometimes, the value of tx-fifo buffer of the spi-imx was equals to 429496729.
With some external help, we see it was due to the register MX27_INTREG_TEEN reading instead of
the MX27_INTREG_TSHFEEN register. 


With these changes (reading of the register TSHFEEN), for me, it works well.
I hope it can help.


Best regards,


Mylene JOSSERAND


________________________________________
De : linux-can-owner@vger.kernel.org <linux-can-owner@vger.kernel.org> de la part de John Whitmore <arigead@gmail.com>
Envoyé : samedi 29 mars 2014 19:15
À : Rost, Martin
Cc : linux-can@vger.kernel.org
Objet : Re: mcp251x: mcp2515 stops receiving

Sorry Martin just catching up with this list.

On Fri, Mar 21, 2014 at 12:40:30PM +0000, Rost, Martin wrote:
> Hello List,
>
> We are using the MCP2515 on a tegra3 (Toradex Colibri T30, to be precise) and every now and then the driver just stops.
> The interrupt line stays low, and the driver does not collect the data.
> From my investigations I conclude, that the MCP lowers the IRQ line before the value in the INTF register is  updated,
> so when the driver reads the INTF register, a 0 is returned, and the driver assumes nothing has to be done.
>

What you have described is something that I've been getting with the
MCP2515. I do have the MCP2515 connected on the RPi, but I've not been using
that setup for a few weeks. I'm currently working with a MCP2515 connected to
a Microchip PIC24 and cannot get the MCP2515 to work in Interrupt mode as it
triggers an Interrupt but the Flags are zero indicating that there is no
interrupt so my driver does nothing and the interrupt line is locked low. I
can only get the 2515 to work in polled mode.

All that is of no help to you but I'll have a look at my RPi setup and really
test it on a network and see if I can recreate that problem there.


> (
> Chances are I'm misinterpreting my observations.
> It might as well be that the call to the IST is suspended, because the previous instance is still running and processes the new irq cause as well,
> so the next call will not see the signal at all.
> But in that case the driver should not stop with the irq line held low, or should it?
> )
>
> We are using the 3.1.10 kernel from the toradex repository, which should be in sync with the nvidia tegra4linux one.
> I have browsed through the patches between 3.1.10 and head and have applied all those that seem to address issues and don't interfere with the 3.1.10 kernel structures, but to no avail.
> In fact, these patches have been applied:
> cab32f39dcc5b35db96497dc0a026b5dea76e4e7
> db388d6460ffa53b3b38429da6f70a913f89b048
> ae5d589e5f9f3217656ada632869968178886ac6
> b1ef05a5a20afe50d4188a5b59579bd140758cf0
> I have changed the IST loop to poll the INTF register beforehand for up to 10ms, and now the driver seems a lot more stable in our environment.
> Has someone seen this issue before, or can confirm I am not completely off the path?
>
> On a side note, I have a second reason that makes the driver stop, which has to do with smp somehow.
> Disabling core1..3 keeps that from happening, but the problem addressed above would persist.
> Switching the irq to a different core by setting /proc/irq/91/smp_affinity does not trigger this problem.
> Any insights or starting point on this would also be greatly appreciated.
>
> Best regards
> Martin


--
To unsubscribe from this list: send the line "unsubscribe linux-can" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html