flexcan napi poll and error frames
Hi,
I was running some tests on my patches when I noticed the following:
If I have 2 flexcan devices on the bus, each sending to the bus using cangen,and then I disconnect the cable to one of them, that device will enter"error-warning" state, but it will not continue on to "error-passive" as itshould.
However, when I reconnect the cable, I get the "error-passive" message followed by an "error-warning" and eventually "back-to-error-active".
Notice the time differences:
root@(none):~# candump -td -e can0,0~0,#FFFFFFFFFF
(000.000000) can0 20000004 [8] 00 08 00 00 00 00 00 00 ERRORFRAME
controller-problem{tx-error-warning}
(006.493209) can0 20000004 [8] 00 40 00 00 00 00 00 00 ERRORFRAME
controller-problem{back-to-error-active}
(002.701331) can0 20000004 [8] 00 08 00 00 00 00 00 00 ERRORFRAME
controller-problem{tx-error-warning}
(006.498567) can0 20000004 [8] 00 20 00 00 00 00 00 00 ERRORFRAME
controller-problem{tx-error-passive}
(000.013915) can0 20000004 [8] 00 08 00 00 00 00 00 00 ERRORFRAME
controller-problem{tx-error-warning}
(001.990695) can0 20000004 [8] 00 40 00 00 00 00 00 00 ERRORFRAME
controller-problem{back-to-error-active}I suspect that the problem is that the driver doesn't receive any interruptsother than the one for "error-passive" and so things won't "weigh" enoughfor napi. There seems to be some truth in this conjecture, because when Itried setting the napi weight to 1, the message got through.
Another thing that I found peculiar was that I had to be sending on both devices for the error states to change to anything other than "error-warning".
Best regards,
Andri Yngvason
Quoted 10 lines · Andri Yngvason
Hi,
I was running some tests on my patches when I noticed the following:
If I have 2 flexcan devices on the bus, each sending to the bus using cangen,and then I disconnect the cable to one of them, that device will enter"error-warning" state, but it will not continue on to "error-passive" as itshould.However, when I reconnect the cable, I get the "error-passive" message followed by an "error-warning" and eventually "back-to-error-active".
Yes, I think I observed that behaviour as well as you can see here:
https://gitorious.org/linux-can/wg-linux-can-next/commit/bd3acb12dbb9551541d28ae8766c154d3cf6ed57.patch
Quoted 3 lines
Notice the time differences:
root@(none):~# candump -td -e can0,0~0,#FFFFFFFFFF (000.000000) can0 20000004 [8] 00 08 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-warning}(006.493209) can0 20000004 [8] 00 40 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{back-to-error-active}(002.701331) can0 20000004 [8] 00 08 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-warning}(006.498567) can0 20000004 [8] 00 20 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-passive}(000.013915) can0 20000004 [8] 00 08 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-warning}(001.990695) can0 20000004 [8] 00 40 00 00 00 00 00 00
ERRORFRAME
Quoted 8 lines
controller-problem{back-to-error-active}I suspect that the problem is that the driver doesn't receive any interruptsother than the one for "error-passive" and so things won't "weigh" enoughfor napi. There seems to be some truth in this conjecture, because when Itried setting the napi weight to 1, the message got through.
Hm, why should it depend on NAPI. It does not delay messages for a long time. I think the problem is that the state change is not signalled my an interrupt but some time later when another event (message) occurs.
Quoted 3 lines
Another thing that I found peculiar was that I had to be sending on both devices for the error states to change to anything other than "error-warning".
Well, the error reporting on the SJA1000 is perfect... on all other CAN controllers it's more or less worse.
Wolfgang.
Quoted 10 lines · Wolfgang Grandegger
Quoted 8 lines · Andri Yngvason
Hi,
I was running some tests on my patches when I noticed the following:
If I have 2 flexcan devices on the bus, each sending to the bus using cangen,and then I disconnect the cable to one of them, that device will enter"error-warning" state, but it will not continue on to "error-passive" as itshould.
Quoted 4 lines
Quoted 2 lines
However, when I reconnect the cable, I get the "error-passive" message followed by an "error-warning" and eventually "back-to-error-active".
Yes, I think I observed that behaviour as well as you can see here:
https://gitorious.org/linux-can/wg-linux-can-next/commit/bd3acb12dbb9551541d28ae8766c154d3cf6ed57.patch
Good to know.
Quoted 27 lines
Quoted 3 lines
Notice the time differences:
root@(none):~# candump -td -e can0,0~0,#FFFFFFFFFF (000.000000) can0 20000004 [8] 00 08 00 00 00 00 00 00ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-warning}(006.493209) can0 20000004 [8] 00 40 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{back-to-error-active}(002.701331) can0 20000004 [8] 00 08 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-warning}(006.498567) can0 20000004 [8] 00 20 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-passive}(000.013915) can0 20000004 [8] 00 08 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-warning}(001.990695) can0 20000004 [8] 00 40 00 00 00 00 00 00
ERRORFRAME
Quoted 8 lines
controller-problem{back-to-error-active}I suspect that the problem is that the driver doesn't receive any interruptsother than the one for "error-passive" and so things won't "weigh" enoughfor napi. There seems to be some truth in this conjecture, because when Itried setting the napi weight to 1, the message got through.
Quoted 5 lines
Hm, why should it depend on NAPI. It does not delay messages for a long time. I think the problem is that the state change is not signalled my an interrupt but some time later when another event (message) occurs.
Perhaps, but how do you explain that the message got through when I set the weight to 1?
Quoted 6 lines
Quoted 3 lines
Another thing that I found peculiar was that I had to be sending on both devices for the error states to change to anything other than "error-warning".
Well, the error reporting on the SJA1000 is perfect... on all other CAN controllers it's more or less worse.
Should we just ignore this problem then? I'd rather like to figure out if this is problem with the controller or not. Do you remember if you've had this problem with flexcan?
Andri.
Quoted 11 lines · Andri Yngvason
Quoted 10 lines · Wolfgang Grandegger
Quoted 8 lines · Andri Yngvason
Hi,
I was running some tests on my patches when I noticed the following:
If I have 2 flexcan devices on the bus, each sending to the bus using cangen,and then I disconnect the cable to one of them, that device will enter"error-warning" state, but it will not continue on to "error-passive" as itshould.
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
However, when I reconnect the cable, I get the "error-passive" message followed by an "error-warning" and eventually "back-to-error-active".
Yes, I think I observed that behaviour as well as you can see here:
Quoted 28 lines
Good to know.
Quoted 27 lines
Quoted 3 lines
Notice the time differences:
root@(none):~# candump -td -e can0,0~0,#FFFFFFFFFF (000.000000) can0 20000004 [8] 00 08 00 00 00 00 00 00ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-warning}(006.493209) can0 20000004 [8] 00 40 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{back-to-error-active}(002.701331) can0 20000004 [8] 00 08 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-warning}(006.498567) can0 20000004 [8] 00 20 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-passive}(000.013915) can0 20000004 [8] 00 08 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-warning}(001.990695) can0 20000004 [8] 00 40 00 00 00 00 00 00
ERRORFRAME
Quoted 8 lines
controller-problem{back-to-error-active}I suspect that the problem is that the driver doesn't receive any interruptsother than the one for "error-passive" and so things won't "weigh" enoughfor napi. There seems to be some truth in this conjecture, because when Itried setting the napi weight to 1, the message got through.
Quoted 7 lines
Quoted 5 lines
Hm, why should it depend on NAPI. It does not delay messages for a long time. I think the problem is that the state change is not signalled my an interrupt but some time later when another event (message) occurs.
Perhaps, but how do you explain that the message got through when I set the weight to 1?
If it's really true it would be a bug in the NAPI handling. Could you please elaborate a bit more by adding some printouts in the interrupt handler. I will have a closer look tomorrow.
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
Another thing that I found peculiar was that I had to be sending on both devices for the error states to change to anything other than "error-warning".
Well, the error reporting on the SJA1000 is perfect... on all other CAN controllers it's more or less worse.
Should we just ignore this problem then? I'd rather like to figure out if this is problem with the controller or not. Do you remember if you've had this problem with flexcan?
We can do little if the CAN controller does not notify the Software via interrupt.
Wolfgang.
Quoted 51 lines · Wolfgang Grandegger
Quoted 11 lines · Andri Yngvason
Quoted 10 lines · Wolfgang Grandegger
Quoted 8 lines · Andri Yngvason
Hi,
I was running some tests on my patches when I noticed the following:
If I have 2 flexcan devices on the bus, each sending to the bus using cangen,and then I disconnect the cable to one of them, that device will enter"error-warning" state, but it will not continue on to "error-passive" as itshould.Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
However, when I reconnect the cable, I get the "error-passive" message followed by an "error-warning" and eventually "back-to-error-active".
Yes, I think I observed that behaviour as well as you can see here:
Quoted 33 lines
Good to know.
Quoted 32 lines
Quoted 3 lines
Notice the time differences:
root@(none):~# candump -td -e can0,0~0,#FFFFFFFFFF (000.000000) can0 20000004 [8] 00 08 00 00 00 00 00 00ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-warning}(006.493209) can0 20000004 [8] 00 40 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{back-to-error-active}(002.701331) can0 20000004 [8] 00 08 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-warning}(006.498567) can0 20000004 [8] 00 20 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-passive}(000.013915) can0 20000004 [8] 00 08 00 00 00 00 00 00
ERRORFRAME
Quoted 2 lines
controller-problem{tx-error-warning}(001.990695) can0 20000004 [8] 00 40 00 00 00 00 00 00
ERRORFRAME
Quoted 8 lines
controller-problem{back-to-error-active}I suspect that the problem is that the driver doesn't receive any interruptsother than the one for "error-passive" and so things won't "weigh" enoughfor napi. There seems to be some truth in this conjecture, because when Itried setting the napi weight to 1, the message got through.
Hm, why should it depend on NAPI. It does not delay messages for a long time. I think the problem is that the state change is not signalled my an interrupt but some time later when another event (message) occurs.
Quoted 5 lines
Quoted 2 lines
Perhaps, but how do you explain that the message got through when I set the weight to 1?
If it's really true it would be a bug in the NAPI handling. Could you please elaborate a bit more by adding some printouts in the interrupt handler. I will have a closer look tomorrow.
I wasn't lying about it. Perhaps by changing the weight it got through with something else. I don't know; I'm not an expert on the inner workings of napi.
But let's just forget about the weight thing. I found out by looking in the i.mx6 reference manual that there is no interrupt for this transition. I found that quite incredible so I searched through it a few times. Anyway, there are only interrupts for active->tx-warning, active->rx-warning and active->bus-off.
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Another thing that I found peculiar was that I had to be sending on both devices for the error states to change to anything other than "error-warning".
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Well, the error reporting on the SJA1000 is perfect... on all other CAN controllers it's more or less worse.
Should we just ignore this problem then? I'd rather like to figure out if this is problem with the controller or not. Do you remember if you've had this problem with flexcan?
We can do little if the CAN controller does not notify the Software via interrupt.
Yes, that's why I wanted to figure out if it's a controller problem or not. Turns out it's a controller problem, but perhaps we can work around it? E.g. if we check esr for state changes every time someone transmits a frame, both of these problems would go away. Would it be unacceptable overhead to do so?
Cheers,
Andri
Quoted 21 lines · Andri Yngvason
Quoted 20 lines · Wolfgang Grandegger
Quoted 11 lines · Andri Yngvason
Quoted 10 lines · Wolfgang Grandegger
Quoted 8 lines · Andri Yngvason
Hi,
I was running some tests on my patches when I noticed the following:
If I have 2 flexcan devices on the bus, each sending to the bus using cangen,and then I disconnect the cable to one of them, that device will enter"error-warning" state, but it will not continue on to "error-passive" as itshould.Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
However, when I reconnect the cable, I get the "error-passive" message followed by an "error-warning" and eventually "back-to-error-active".
Yes, I think I observed that behaviour as well as you can see here:
Quoted 2 lines
Good to know.
Quoted 1 line
...
Quoted 34 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
I suspect that the problem is that the driver doesn't receive any interruptsother than the one for "error-passive" and so things won't "weigh" enoughfor napi. There seems to be some truth in this conjecture, because when Itried setting the napi weight to 1, the message got through.
Hm, why should it depend on NAPI. It does not delay messages for a long time. I think the problem is that the state change is not signalled my an interrupt but some time later when another event (message) occurs.Quoted 5 lines
Quoted 2 lines
Perhaps, but how do you explain that the message got through when I set the weight to 1?
If it's really true it would be a bug in the NAPI handling. Could you please elaborate a bit more by adding some printouts in the interrupt handler. I will have a closer look tomorrow.
I wasn't lying about it. Perhaps by changing the weight it got through with something else. I don't know; I'm not an expert on the inner workings of napi.
But let's just forget about the weight thing. I found out by looking in the i.mx6 reference manual that there is no interrupt for this transition. I found that quite incredible so I searched through it a few times. Anyway, there are only interrupts for active->tx-warning, active->rx-warning and active->bus-off.
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
Another thing that I found peculiar was that I had to be sending on both devices for the error states to change to anything other than "error-warning".
Well, the error reporting on the SJA1000 is perfect... on all other CAN controllers it's more or less worse.
Should we just ignore this problem then? I'd rather like to figure out if this is problem with the controller or not. Do you remember if you've had this problem with flexcan?
Quoted 8 lines
Quoted 2 lines
We can do little if the CAN controller does not notify the Software via interrupt.
Yes, that's why I wanted to figure out if it's a controller problem or not. Turns out it's a controller problem, but perhaps we can work around it? E.g. if we check esr for state changes every time someone transmits a frame, both of these problems would go away. Would it be unacceptable overhead to do so?
I've just confirmed that this "fix" works, but only if berr-reporting is enabled.
Andri.
Hello,
Am Freitag, 24. Oktober 2014, 16:04:56 schrieben Sie:
Quoted 10 lines
Quoted 9 lines
We can do little if the CAN controller does not notify the Software
Quoted 1 line
via interrupt.
Yes, that's why I wanted to figure out if it's a controller problem or not.
Turns out it's a controller problem, but perhaps we can work around it? E.g. if we check esr for state changes every time someone transmits a frame, both of these problems would go away. Would it be unacceptable overhead to do so?
Quoted 2 lines
I've just confirmed that this "fix" works, but only if berr-reporting is enabled.
Is this workaround working in case of an open CAN Bus? (Ack error situation)
The flexcan can generate an error interrupt after every CAN bus error. But in case of an error situation the interrupt load would be very high (e.g. short circuit of the CAN).
Signature · 4 lines
Mit freundlichen Grüßen Steffen Rose www.emtas.de
Quoted 11 lines · Steffen Rose
Hello,
Am Freitag, 24. Oktober 2014, 16:04:56 schrieben Sie:
Quoted 8 lines
Quoted 8 lines
We can do little if the CAN controller does not notify the Software
Quoted 1 line
via interrupt.
Yes, that's why I wanted to figure out if it's a controller problem or not.
Turns out it's a controller problem, but perhaps we can work around it? E.g. if we check esr for state changes every time someone transmits a frame, both of these problems would go away. Would it be unacceptable overhead to do so?
Quoted 4 lines
Quoted 2 lines
I've just confirmed that this "fix" works, but only if berr-reporting is enabled.
Is this workaround working in case of an open CAN Bus? (Ack error situation)
Yes
Quoted 4 lines
The flexcan can generate an error interrupt after every CAN bus error. But in case of an error situation the interrupt load would be very high (e.g. short circuit of the CAN).
That's what berr-reporting does, right? Considering that when the bus is flooded with errors, things are in a pretty bad shape anyway, I think it's not really going to contribute much to the over-all mess to just leave the error interrupts on all the time. It's far worse if the user doesn't get the correct error state.
Anyway, defensive measures can be taken. When the bus has reached error-passive, the driver is not going to need those interrupts any more so it could turn off the interrupts until the bus goes to bus-off or back down to warning or active; except when berr-reporting is enabled.
--
Andri
Hi Andri,
Quoted 28 lines · On Fri, 24 Oct 2014 17:40:19 +0000 Andri Yngvason <[email protected]>…
Quoted 11 lines · Steffen Rose
Hello,
Am Freitag, 24. Oktober 2014, 16:04:56 schrieben Sie:
Quoted 8 lines
Quoted 8 lines
We can do little if the CAN controller does not notify the Software
Quoted 1 line
via interrupt.
Yes, that's why I wanted to figure out if it's a controller problem or not.
Turns out it's a controller problem, but perhaps we can work around it? E.g. if we check esr for state changes every time someone transmits a frame, both of these problems would go away. Would it be unacceptable overhead to do so?Quoted 4 lines
Quoted 2 lines
I've just confirmed that this "fix" works, but only if berr-reporting is enabled.
Is this workaround working in case of an open CAN Bus? (Ack error situation)
Yes
Quoted 4 lines
The flexcan can generate an error interrupt after every CAN bus error. But in case of an error situation the interrupt load would be very high (e.g. short circuit of the CAN).
That's what berr-reporting does, right? Considering that when the bus is flooded with errors, things are in a pretty bad shape anyway, I think it's not really going to contribute much to the over-all mess to just leave the error interrupts on all the time. It's far worse if the user doesn't get the correct error state.
Quoted 4 lines
Anyway, defensive measures can be taken. When the bus has reached error-passive, the driver is not going to need those interrupts any more so it could turn off the interrupts until the bus goes to bus-off or back down to warning or active; except when berr-reporting is enabled.
Would you mind trying out the patch series posted a few days ago here:
http://article.gmane.org/gmane.linux.can/6654
It applies to the flexcan-next branch ofgit://gitorious.org/linux-can/linux-can-next.git
(base commit should be 907aa2d61697035a921cad6375c0d546b1d18af6 if HEAD fails).
I think it solves your problem.
Best regards,
Signature · 2 lines
David Jander Protonic Holland.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 45 lines · On Mon, 27 Oct 2014 11:27:21 +0000 Andri Yngvason <[email protected]>…
Hi David,
Quoted 42 lines · David Jander
Quoted 27 lines · Andri Yngvason
Quoted 11 lines · Steffen Rose
Hello,
Am Freitag, 24. Oktober 2014, 16:04:56 schrieben Sie:
Quoted 8 lines
Quoted 8 lines
We can do little if the CAN controller does not notify the Software
Quoted 1 line
via interrupt.
Yes, that's why I wanted to figure out if it's a controller problem or not.
Turns out it's a controller problem, but perhaps we can work around it? E.g. if we check esr for state changes every time someone transmits a frame, both of these problems would go away. Would it be unacceptable overhead to do so?Quoted 4 lines
Quoted 2 lines
I've just confirmed that this "fix" works, but only if berr-reporting is enabled.
Is this workaround working in case of an open CAN Bus? (Ack error situation)
Yes
Quoted 4 lines
The flexcan can generate an error interrupt after every CAN bus error. But in case of an error situation the interrupt load would be very high (e.g. short circuit of the CAN).
That's what berr-reporting does, right? Considering that when the bus is flooded with errors, things are in a pretty bad shape anyway, I think it's not really going to contribute much to the over-all mess to just leave the error interrupts on all the time. It's far worse if the user doesn't get the correct error state.
Quoted 4 lines
Anyway, defensive measures can be taken. When the bus has reached error-passive, the driver is not going to need those interrupts any more so it could turn off the interrupts until the bus goes to bus-off or back down to warning or active; except when berr-reporting is enabled.
Would you mind trying out the patch series posted a few days ago here:
http://article.gmane.org/gmane.linux.can/6654
It applies to the flexcan-next branch of
git://gitorious.org/linux-can/linux-can-next.git
(base commit should be907aa2d61697035a921cad6375c0d546b1d18af6if HEAD fails).
Quoted 6 lines
Quoted 2 lines
I think it solves your problem.
Sure, I'll try those patches, but applying them is non-trivial. I.e. they don't apply. Patching the base commit fails after "Applying: can: rx-fifo:
fix long lines". Could you maybe just send me a link to a git repo or branch where they're already applied? A single .patch file might also work.
Hmmm. It seems that tree is kind of a moving target sometimes.... Here's a link to the whole series re-based on top of vanilla 3.17:
https://github.com/yope/linux/tree/flexcan-v3.17
I hope this works for you.
Best regards,
Signature · 2 lines
David Jander Protonic Holland.
Quoted 55 lines · David Jander
Quoted 45 lines · On Mon, 27 Oct 2014 11:27:21 +0000 Andri Yngvason <[email protected]>…
Hi David,
Quoted 42 lines · David Jander
Quoted 27 lines · Andri Yngvason
Quoted 11 lines · Steffen Rose
Hello,
Am Freitag, 24. Oktober 2014, 16:04:56 schrieben Sie:
Quoted 8 lines
Quoted 8 lines
We can do little if the CAN controller does not notify the Software
Quoted 1 line
via interrupt.
Yes, that's why I wanted to figure out if it's a controller problem or not.
Turns out it's a controller problem, but perhaps we can work around it? E.g. if we check esr for state changes every time someone transmits a frame, both of these problems would go away. Would it be unacceptable overhead to do so?Quoted 4 lines
Quoted 2 lines
I've just confirmed that this "fix" works, but only if berr-reporting is enabled.
Is this workaround working in case of an open CAN Bus? (Ack error situation)
Yes
Quoted 4 lines
The flexcan can generate an error interrupt after every CAN bus error. But in case of an error situation the interrupt load would be very high (e.g. short circuit of the CAN).
That's what berr-reporting does, right? Considering that when the bus is flooded with errors, things are in a pretty bad shape anyway, I think it's not really going to contribute much to the over-all mess to just leave the error interrupts on all the time. It's far worse if the user doesn't get the correct error state.
Quoted 4 lines
Anyway, defensive measures can be taken. When the bus has reached error-passive, the driver is not going to need those interrupts any more so it could turn off the interrupts until the bus goes to bus-off or back down to warning or active; except when berr-reporting is enabled.
Would you mind trying out the patch series posted a few days ago here:
http://article.gmane.org/gmane.linux.can/6654
It applies to the flexcan-next branch of
git://gitorious.org/linux-can/linux-can-next.git
(base commit should be907aa2d61697035a921cad6375c0d546b1d18af6if HEAD fails).Quoted 6 lines
Quoted 2 lines
I think it solves your problem.
Sure, I'll try those patches, but applying them is non-trivial. I.e. they don't apply. Patching the base commit fails after "Applying: can: rx-fifo:
fix long lines". Could you maybe just send me a link to a git repo or branch where they're already applied? A single .patch file might also work.
Quoted 7 lines
Hmmm. It seems that tree is kind of a moving target sometimes.... Here's a link to the whole series re-based on top of vanilla 3.17:
https://github.com/yope/linux/tree/flexcan-v3.17
I hope this works for you.
Thanks for rabasing this for me. It turns out that the source of all my problems was my mail client (Thunderbird). It seems to mangle even maildir.
I switched to offlineimap and mutt, and the patches applied. I've been trying to make thunderbird work because co-workers keep sending me HTML mail...
Sorry for making you do that extra work.
--
Andri
Quoted 60 lines · Andri Yngvason
Quoted 21 lines · Andri Yngvason
Quoted 20 lines · Wolfgang Grandegger
Quoted 11 lines · Andri Yngvason
Quoted 10 lines · Wolfgang Grandegger
Quoted 8 lines · Andri Yngvason
Hi,
I was running some tests on my patches when I noticed the following:
If I have 2 flexcan devices on the bus, each sending to the bus using cangen,and then I disconnect the cable to one of them, that device will enter"error-warning" state, but it will not continue on to "error-passive" as itshould.Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
However, when I reconnect the cable, I get the "error-passive" message followed by an "error-warning" and eventually "back-to-error-active".
Yes, I think I observed that behaviour as well as you can see here:
Quoted 2 lines
Good to know.
Quoted 1 line
...
Quoted 36 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
I suspect that the problem is that the driver doesn't receive any interruptsother than the one for "error-passive" and so things won't "weigh" enoughfor napi. There seems to be some truth in this conjecture, because when Itried setting the napi weight to 1, the message got through.
Hm, why should it depend on NAPI. It does not delay messages for a long time. I think the problem is that the state change is not signalled my an interrupt but some time later when another event (message) occurs.Quoted 5 lines
Quoted 2 lines
Perhaps, but how do you explain that the message got through when I set the weight to 1?
If it's really true it would be a bug in the NAPI handling. Could you please elaborate a bit more by adding some printouts in the interrupt handler. I will have a closer look tomorrow.
I wasn't lying about it. Perhaps by changing the weight it got through with something else. I don't know; I'm not an expert on the inner workings of napi.
But let's just forget about the weight thing. I found out by looking in the i.mx6 reference manual that there is no interrupt for this transition. I found that quite incredible so I searched through it a few times. Anyway, there are only interrupts for active->tx-warning, active->rx-warning and active->bus-off.
Quoted 11 lines
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
Another thing that I found peculiar was that I had to be sending on both devices for the error states to change to anything other than "error-warning".
Well, the error reporting on the SJA1000 is perfect... on all other CAN controllers it's more or less worse.
Should we just ignore this problem then? I'd rather like to figure out if this is problem with the controller or not. Do you remember if you've had this problem with flexcan?
We can do little if the CAN controller does not notify the Software via interrupt.
Quoted 8 lines
Quoted 6 lines
Yes, that's why I wanted to figure out if it's a controller problem or not. Turns out it's a controller problem, but perhaps we can work around it? E.g. if we check esr for state changes every time someone transmits a frame, both of these problems would go away. Would it be unacceptable overhead to do so?
I've just confirmed that this "fix" works, but only if berr-reporting is enabled.
Ah, oh, this reminds me that there is a related bug in some versions of the FLEXCAN core. If you look to "flexcan.c" you will find:
#define FLEXCAN_HAS_BROKEN_ERR_STATE BIT(2) /* [TR]WRN INT not connected */
On these cores bus-error reporting is required to realize these state changes.
Wolfgang.