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?
> 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.
>
> Porting notes:
> a) most of the eth_tool functions are not used and gcc warns;
Would have to be fixed for inclusion.
> 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.
> 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.
Key question regarding e100 vs. eepro100: Does the former no longer lock
up for you _without_ requiring any help from the watchdog?
Jan
[1] http://thread.gmane.org/gmane.linux.real-time.rtnet.devel/388
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
------------------------------------------------------------------------------
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
