Vladimir Cotfas wrote:
> Jan,
>
>
>> Better look at the git commits upstream ("gitk v2.6.29..HEAD --
>> drivers/net/e100.c", or so), they are more telling than an all-in-one
>> diff. But already that diff tells me that upstream gained support for
>> yet another adapter variant. Maybe it also received some bug fixes.>
>>
> I could port this RTNET driver to 2.6.33 however our (test) setup here is
> 2.6.29.Also for that reason, let's have a look at individual changes, picking up at least those bits that aren't adoptions to latest kernel API changes. As long as the result still builds warning-free (I'm willing to test against 2.6.34), I'm fine. Cleanups can still be done later on. > > >> That's simple: RTnet, RTDM, and Linux, no single RTAI bit. >> > I am looking at rtdm/drvlib.c and I saw the replacements for rt_task_* and > rt_sem_*. Don't look at the implementation first, check the documentation. > > How do I replace the barrier stuff? (I am coming from a pthreads > environment, hence the APIs I use.) > > >> Before suggesting that there are proper RTDM abstractions for this: Why >> do you need all this extra threading and IPC at all? And can't that be >> provided via some abstraction by RTnet, *up to the application*? What >> part of the normal RTnet RX/TX path (RX IRQ -> stack manager -> recv >> (application task) / send (application task) -> xmit handler) is >> problematic or insufficient for you? >> >> Well, I did not *represent* that I fully understand the e100 driver. I > tried to keep most of the functionality in the driver in place trusting that > the authors *had a real need* for it [sans power management and WoL]. The > parts I do understand, e.g, LED blink timer, ioctl(), etc I removed. Some > power-managemnt bits are re-used in the normal driver. > > I tried to replace Linux delayed-work schemes with RTAI/RTNET equivalents. > (I assumed that the WTD is required to correct chipset bugs -- and I > stumbled into them in the rt_eepro100 driver). "Correcting" depends on your scenario: If you have timing requirements below any bug detection timeout, you are busted with or without the watchdog. But, as explained, the bug should not show up in a properly managed network (with limited peak load). If you are in an unmanaged, aka indeterministic network anyway and you can perfectly recover from the bug via the help of the watchdog, we can keep it fully functional, ie. not only use it to warn but also to clean up. You should just convert rtdm_lock_get to an IRQ-safe variant (the Linux timer handler is not IRQ-save /wrt RTDM). > > As I am new a to this RT bussiness I implemented a quick IPC scheme that > allows the driver to function as it does in normal Linux. > > The RX path is problematic as (again) we intend to drive it from a > FPGA-fired timer IRQ as our IRQ (#11) is shared with USB and sometimes that > wrecks havoc with network timing. Hence using a binary semaphore that is > being kicked by the card IRQ (in the initial port) or by the FPGA IRQ (in > our setup) + a thread. So, in other words, you were looking for a way to _poll_ the NICs RX queue instead of using the normal IRQ-based mechanism. That would basically require a NAPI-like infrastructure for RTnet. Useful, no question (also e.g. for high load GBit networks), we just don't have it yet. But I'm not sure if your case actually requires it. Please check http://www.xenomai.org/index.php/FAQs#What_can_I_do_if_Xenomai_and_Linux_devices_share_the_same_IRQ.3F Those suggestions apply to RTAI as well. The way you seem to follow with the FPGA timer looks like some option that comes not only after this list, but also after a _much_ simpler platform timer based approach (there is e.g. rtdm_timer_*, and no need for a task at all). In any case, this workaround for a hardware deficit is nothing that should be submitted for upstream. If you are really trapped with such a bug (though I seriously doubt you are), fork off a private branch of RTnet - and put a note on the hardware spec to fix it properly in the next revision. Shared IRQs between RT and non-RT are a design no-go. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
