Barry Song wrote: > On Fri, Nov 13, 2009 at 4:00 PM, Wolfgang Grandegger <[email protected]> > wrote: >> Barry Song wrote: >>> On Thu, Nov 12, 2009 at 8:36 PM, Wolfgang Grandegger <[email protected]> >>> wrote: [snip] >>>> Please remove the TX watchdog. We don't need it. >>> I am strange if hardware fails to send packets, how could we resume >>> the blocked TX queue if we don't call netif wakeup in the timeout >>> function? >> The hardware will retry until it succeeds or the device is stopped. Non >> of the other CAN drivers uses the TX timeout. > I am not insisting on adding timeout. Maybe I worry too much. I just > have a question about failure/restore mechanism for CAN driver. If the > transmit completion interrupt is lost due to some unknown failure, but > we block the incoming TX stream because the current tx is not > completed. Then is there any mechanism for the driver to reset and > resume to normal again? > I think Ethernet uses the timeout to handler this kind of issue.
Ethernet is different. If the transmit completion interrupt gets lost due to some unknown failure, your hardware seems to be broken. In that case you can try a ifconfig down/up cycle. CAN maintains internal error counters and if they exceeds a certain limit, the error state is changed from active to error warning, error passive and finally to bus-off. For bus-off recovery, we have a dedicated interface, which the user can control via the restart-ms option: ./ip link set can0 type can restart-ms 100 If restart-ms is 0 (default), it's the user/applications responsibility to trigger a manual bus-off recovery using: ./ip link set can0 type can restart If restart-ms > 0, an automatic recovery will be performed after the specified time. In anyway, state changes are reported to the user/application via CAN error messages. Unfortunately, some CAN controllers do automatic bus-off recovery when the bus gets idle again. How does the BFIN CAN contoller behave? Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
