Vladimir Cotfas wrote: > Jan, > > Sorry for the delay in my response: I have been away due to my work > schedule. > > On Fri, May 14, 2010 at 6:24 AM, Jan Kiszka <jan.kis...@siemens.com> wrote: > >> Vladimir Cotfas wrote: >>> Folks, >>> >>> At Manta Test we have noticed that the rt_eepro100 driver would sometimes >>> lock up overnight due to traffic on the local net (the same did not >> happen >>> if we used an isolated segment that had well-known traffic generated by >> us). >> >> That chip, at least some variants of it, had a hardware bug that could >> cause such transmitter lockups. Given that non-deterministic traffic is >> not directly the common use case for RTnet, I once decided to disable >> any recovery from that and rather left only the detection code that >> reports this as a fatal error. Actually, you should see corresponding >> kernel log entries after the lockup. >> >>> We decided to port the Intel e100 driver to RTNET as it's more recent and >> is >>> uses the microcode supplied by Intel/the Linux kernel. >> Before starting my complaints :) : Extending hardware support is >> definitely appreciated! >> >>> The e100.c base driver comes Linux 2.6.29-vanilla. >> Picking up the latest git or at least 2.6.33.x version would have been >> even greater - or are there no differences between those kernels? >> > 5 months ago RTAI and RTNET did not compile cleanly on 2.6.31 [latest at the > time] with either HAL or Adeos. Hence I backtracked kernel versions until I > got them to compile. > > The differences in e100.c between 2.6.29 and 2.6.33 are minimal (see > e100.diff, attached).
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.
>
>
>>> Due to mailing list
>>> message size limits it's not attached.
>> I removed the limit for the rtnet-developers list, you may repost your
>> work as complete patch ('git format-patch' style please, see [1], and it
>> requires build system extensions as well) if you can to address my
>> remarks below.
>>
> I am not sure I have the patch "ready", we need to discuss the code a bit
> more [see below]. A bit of coaxing/guidance on your side would be good.
Basic steps are to apply your patch on a recent git checkout of RTnet
(git clone ...), adjust also the build system to generate the driver
during normal RTnet build (scan configure.ac and the driver subdirectory
for some other recently added driver, e.g. igb, to derive the pattern
and apply it), and then commit and sign (git commit -s) the result and
let "git format-patch" generate a properly formated patch out of that
commit. Of course, you can also hand-craft this format, but it usually
causes more complications than reading up the few involved git commands
(unless git isn't already familiar to you anyway).
>
>
>>> Porting notes:
>>> a) most of the eth_tool functions are not used and gcc warns;
>> Would have to be fixed for inclusion.
>>
> I kept them to be closer to e100.c in source form -- this could make
> applying patches from the mainline easier [automatic merge]. If required I
> can yank them.
At the bare minimum, disable them as I don't want new warnings. But I
would actually prefer a cleanup these days, specifically of bits that
are irrelevant to RTnet (power management e.g.).
>
>>> b) e100_ioctl is a no-op (nobody uses it);
>>> c) we use an RTAI thread in lieu of the NAPI delayed-work scheme;
>>> d) ditto for schedule_work / TX timeout;
>>> e) we disabled the LED blink timer;
>>> f) we kept the watchdog timer as a Linux timer -- however this uses a RT
>>> mutex that may be used in the RT tasks -- I am quite new at this RT stuff
>> ->
>>> problems to be seen here?
>> CONFIG_IPIPE_DEBUG_CONTEXT will warn you about illicit Linux calls from
>> RT context, CONFIG_XENO_OPT_DEBUG_RTDM would warn you about invalid RTDM
>> use (don't know if RTAI has any equivalent for RTDM). Based on your
>> description, I'm sure the latter would bark at you.
>>
>
> I compiled a list of RTAI / RTNET / RTDM calls that I use. Please let me
> know which are not admissable:
That's simple: RTnet, RTDM, and Linux, no single RTAI bit.
>
> rt_alloc_etherdev
> rtdev_alloc_name
> rtdev_free
> rt_rtdev_connect
> rt_rtdev_disconnect
> rt_register_rtnetdev
> rt_unregister_rtnetdev
>
> rtdm_irq_request
> rtdm_irq_free
> rtdm_irq_get_arg
>
> rtdm_printk
>
> rt_eth_type_trans
> rtnetif_carrier_ok
> rtnetif_start_queue
> rtskb_pool_init
> rtskb_pool_release
> rt_stack_connect
> rt_stack_disconnect
> rt_mark_stack_mgr
>
> rt_named_sem_init
> rt_typed_sem_init
> rt_sem_delete
> rt_sem_signal
> rt_sem_wait
> rt_sem_wait_barrier
>
> rt_task_init
> rt_task_delete
> rt_task_resume
> rt_make_hard_real_time
> rtdm_task_busy_sleep
>
> rtdm_lock_init
> rtdm_lock_get
> rtdm_lock_put
> rtdm_lock_get_irqsave
> rtdm_lock_put_irqrestore
>
> Is there an official consistent documentation for RTDM?
For sure:
http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__rtdm.html
>
> The barrier stuff is there so I can stop the extra threads upon driver
> removal.
>
> The rt_sem_* are IRQ -> thread IPC. I need semaphores not spinlocks/mutexes
> for this.
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?
>
>
>>> g) we intend to use an external timer interrupt to drive the e100 driver
>> in
>>> lieu of its own IRQ, hence USE_RTAI_IRQ;
>>> h) the RX budget is 10 packets -- just an empirical value which is
>>> hard-coded.
>>>
>>> We tested this with rtnetproxy/proxy ARP running on top of it.
>>>
>>> Please consider incorporating this driver into RTnet.
>> Please understand that I will not merge any ha^w"extensions" on top of
>> an RT Linux variant, neither RTAI nor any other approach. The proper
>> abstractions are RTDM for RT, Linux for non-RT base services, and any
>> other services have to be provided by the RTnet core. If something is
>> missing, let us discuss clean extensions.
>>
> This I do not understand: the RTNET stack works *only* on top of RTAI so
> what is wrong with using RTAI calls?
RTAI is one user of RTnet, but surely not THE user. Many (I dare to say:
most) new industrial use cases are built on Xenomai these days.
But in order to keep up support for RTAI and to allow to port RTnet to
PREEMPT-RT one day, RTDM was introduced long ago as a proper abstraction
of these "details".
>
>
>> Key question regarding e100 vs. eepro100: Does the former no longer lock
>> up for you _without_ requiring any help from the watchdog?
>>
>
> I had it running only for a short while w/o the WDT and I did not see any
> lockup. I could do a longer test.
That would make e100 _very_ interesting as a eepro100 replacement, at
least mid-term when we know that no eepro100 users suffer from potential
regressions with e100.
Thanks again for your work!
Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
