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).
>
> > 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.
>
> >
> > 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.
>
> > 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:
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?
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.
>
> > 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?
> 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.
Regards,
Vlad
e100.diff
Description: Binary data
------------------------------------------------------------------------------
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
