Jan Kiszka wrote: > Vladimir Cotfas wrote: >> Jan, >> I may have missed that point. But if the original code already uses >> schedule_work, there is likely not much to gain via an RT task: when it >> triggers, RT systems are typically already broken. >> >> I have no problem with error detection, also error recovery. We should >> just avoid over-designing (note that every RT task in a system has a >> design cost /wrt RT). >> The schedule_work may be invoked from a RT context so I thought prudent to >> use a semaphore and an RT task (txTimeoutTaxk). >> >> I don't understand the interactions between Linux's delayed-work scheme >> (NAPI, schedule_work, timers) and RATI/etc so I reckoned I mode it all to >> RTAI. > > For signaling "down" (RT->Linux) we have rtdm_nrtsig. It can fire off a > soft-IRQ in Linux context that can then trigger whatever Linux job is > required. > > But I will check the code later on as well and come back with a concrete > suggestion.
OK, to recover from a transmitter hang (or timeout) let's go this route:
rtdm_nrtsig_init(&nic->tx_timeout_signal, e100_timeout_handler, nic);
e100_exec_cb:
if (err == -ENOSPC)
rtdm_nrtsig_pend(nic->tx_timeout_signal);
static void e100_timeout_handler(rtdm_nrtsig_t nrt_sig, void *arg)
{
struct nic *nic = arg;
schedule_work(&nic->tx_timeout_task);
}
Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
