On 07/24/2010 05:01 PM, Alexander Holler wrote:
> Hello,
>
> Am 24.07.2010 16:30, schrieb Wolfgang Grandegger:
>
>>> My first simple solution for this is currently the following patch:
>>>
>>> --------------------------------
>>> diff --git a/drivers/net/can/mcp251x.c b/drivers/net/can/mcp251x.c
>>> index b11a0cb..e1a3745 100644
>>> --- a/drivers/net/can/mcp251x.c
>>> +++ b/drivers/net/can/mcp251x.c
>>> @@ -835,7 +835,7 @@ static irqreturn_t mcp251x_can_ist(int irq, void
>>> *dev_id)
>>> }
>>> }
>>>
>>> - if (intf == 0)
>>> + if ((intf& ~CANINTF_MERRF) == 0)
>>> break;
>>>
>>> if (intf& (CANINTF_TX2IF | CANINTF_TX1IF |
>>> CANINTF_TX0IF)) {
>>> --------------------------------
>>>
>>> With that patch the IRQ will be released even if the MERRF is set in the
>>> CANINTF-register. This will not fix the problem, but at least the system
>>> is still usable in such a case.
>>
>> You seem not to use the MCP251x driver from the mainline kernel. There,
>> MERR is not enabled any more. Here is the commit message:
>
> I'm using the driver from the mainline kernel.
>
>> See above. Just disable the MERR interrrupt.
>
> That doesn't help. The irq isn't trigger by MERR but the loop in the IRQ
> will not be left if that bit is set. Clearing the bit doesn't help,
> either clearing it doesn't work, or the bit will get set again almost
> right after it was cleared.
Hm, I personally never worked with that CAN controller. Maybe Christian
has an idea what goes wrong.
Wolfgang.
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
