rtnet-developers — development-related list

[RTnet-developers] rtnet: COPYING in DOS format

[Hillier, G. <ger...@si...>]

Hi there!

Just noticed that COPYING in current git head is stored in DOS mode:

> file COPYING
COPYING: ASCII English text, with CRLF line terminators

Could you please dos2unix it? TIA!

-- 
Gernot Hillier

Siemens AG, CT SE 2
Corporate Competence Center Embedded Linux
Corporate Technology, Software & Engineering, Architecture
Otto-Hahn-Ring 6, 81730 München, Germany
Tel.: +49 89 636-24320, Fax: -45450

[RTnet-developers] [PATCH] rtnet: remove shebang from rtnet.conf

[Hillier, G. <ger...@si...>]

Hi there!

The current git head of rtnet installs PREFIX/etc/rtnet.conf with
non-exec permissions but with a she-bang at start.

If I'm not completely wrong, this script is not intended to be called
directly (would make no sense as it only sets environment vars), the
she-bang is wrong here.

It also causes rpmlint to complain about installing a shell script in
/etc when e.g. building a SUSE package.

So please apply the attached patch. TIA!

-- 
Gernot Hillier

Siemens AG, CT SE 2
Corporate Competence Center Embedded Linux
Corporate Technology, Software & Engineering, Architecture
Otto-Hahn-Ring 6, 81730 München, Germany
Tel.: +49 89 636-24320, Fax: -45450

Re: [RTnet-developers] ethernet hub

[Jan K. <jan...@we...>]

br...@da... wrote:
> Hi all, I intend to use RT-Net on my application using beagle board where
> I'm also trying to embed Linux/Xenomai. Unfortunately that board has no
> ethernet interface but only a usb port which inspire me to use a USB hub.
> I'm now concern about the compatibility of using RT-NET with such a
> adapter in my board. Is there any restriction?

You need a RT USB stack for this. And you most probably want a
2.0-capable stack. There is USB4RT with some unfixed bug and no USB 2.0
support, and there is unmaintained USB20RT which used to have some RT
problems last time I checked (a few years ago).

Jan

[RTnet-developers] ethernet hub

[<br...@da...>]

Hi all, I intend to use RT-Net on my application using beagle board where
I'm also trying to embed Linux/Xenomai. Unfortunately that board has no
ethernet interface but only a usb port which inspire me to use a USB hub.
I'm now concern about the compatibility of using RT-NET with such a
adapter in my board. Is there any restriction?

Thanks,

Breno

[RTnet-developers] [ANNOUNCE] RTnet 0.9.11 released

[Jan K. <jan...@we...>]

Almost exactly one year has passed since the last release, so quite a
few changes piled up. We gained a some more drivers, performance and
usability improvements were done and, of course, the usual kernel
alignment took place.

Here is the full changelog:
 - kernel support up to 2.6.29
 - statistics support for RT NICs
 - enhancements of rtnetproxy (UDP, ARP)
 - fixes and enhancements of rt_e1000
 - new experimental e1000 driver (shall once replace rt_e1000)
 - rtmacb driver for AT91
 - hash table based UDP socket lookup
 - support for select() on blocking receive
 - configurable routing table sizes
 - drop socket creation/destruction from RT context
 - rewritten mpc52xx driver
 - kernel 2.4 build fixes

And I hope we can announce even more news some - another reason to do
the release now.

Enjoy,
Jan

[RTnet-developers] [ANNOUNCE] RTnet moved to git

[Jan K. <jan...@we...>]

Hi,

in order to unify my local code management and also because of the
significant advantages over subversion, I just migrated the RTnet
repository to SourceForge's new git service. The old SVN repository is
still visible, but no more commits will take place against it. You can
now obtain the latest code via

    git clone git://rtnet.git.sourceforge.net/gitroot/rtnet rtnet

Browse the code online at

    http://rtnet.git.sourceforge.net/

Web pages will be updated over the next weeks, together with a release
that is planned, too.

If you want to contribute some code, please use from now on the standard
patch submission format:

    [PATCH] Subject line

    Comprehensive patch description.

    Signed-off-by: your name <your email>

    Patch content

git is supporting you here (git format-patch etc.). If you prepare a
larger set of changes, I can warmly recommend using stgit (Stacked git)
as local management tool for patches series.

Jan

[RTnet-developers] Question

[Jan P. <ma...@ja...>]

I have a few ignorant questions:

How can I shutdown the network device which shall become part of the
RT-network and
   remove its driver module from the kernel?

How do I load required real-time modules?

Many thanks!
-Jan

Re: [RTnet-developers] RT variant of e100 driver

[Jan K. <jan...@we...>]

Sebastian Smolorz wrote:
> Jan Kiszka wrote:
>> Sebastian Smolorz wrote:
>>> is anyone working on a rt_e100 driver? Maybe half-finished? If not I
>>> would probably start a port since we need such a driver soon.
>>
>> Did you already tried to add the new PCI ID to the rt_eepro100? As RTnet
>> only needs basic support from the NIC, they might be hope to get along
>> with a cheap update of the existing code.
> 
> Yes, a one-liner indeed is a cheap solution. ;-)
> 
> You'll find the small patch attached.

Merged, thank you.

Jan

Re: [RTnet-developers] RT variant of e100 driver

[Sebastian S. <sm...@rt...>]

Jan Kiszka wrote:
> Sebastian Smolorz wrote:
>> is anyone working on a rt_e100 driver? Maybe half-finished? If not I 
>> would probably start a port since we need such a driver soon.
> 
> Did you already tried to add the new PCI ID to the rt_eepro100? As RTnet
> only needs basic support from the NIC, they might be hope to get along
> with a cheap update of the existing code.

Yes, a one-liner indeed is a cheap solution. ;-)

You'll find the small patch attached.

Thanks.

-- 
Sebastian

Re: [RTnet-developers] RT variant of e100 driver

[Jan K. <jan...@we...>]

Sebastian Smolorz wrote:
> Hi,
> 
> is anyone working on a rt_e100 driver? Maybe half-finished? If not I 
> would probably start a port since we need such a driver soon.

Did you already tried to add the new PCI ID to the rt_eepro100? As RTnet
only needs basic support from the NIC, they might be hope to get along
with a cheap update of the existing code.

Jan

[RTnet-developers] RT variant of e100 driver

[Sebastian S. <sm...@rt...>]

Hi,

is anyone working on a rt_e100 driver? Maybe half-finished? If not I 
would probably start a port since we need such a driver soon.

-- 
Sebastian

Re: [RTnet-developers] rtnet w. interrupts disabled

[Jan K. <jan...@we...>]

Tom Schouten wrote:
> On Mon, Jan 19, 2009 at 09:27:58AM +0100, Jan Kiszka wrote:
>> Tom Schouten wrote:
>>> Hello,
>>>
>>> Is it planned to have rtnet operate without network device interrupts?
>> Not yet.
>>
>>> I.e. a non-blocking recv() call would query the card directly without 
>>> buffering, leaving all read timing up to the application.
>> Note that this gets "tricky" if there is additional protocol handling
>> required (like ARP, ICMP, UDP, RTmac, TDMA etc.) or if more than one
>> thread is receiving data at the same time. The model only works
>> straightforward if you do plain Ethernet access with users that all
>> expect the polling mode.
>>
> 
> Yes.  We would use it only for exclusive raw ethernet access with a 
> dedicated segment and completely predictable traffic.
> 
>>> If not planned, maybe you have some advice on how to implement this?
>>> I'm currently looking into modifying the eepro100 driver, but maybe
>>> there is a more highlevel way?
>> A definitely needs a high level handling as well because you always go
>> through the stack to access a driver. As a first step, you may want to
>> study Linux' NAPI interface and check what might be applicable to RTnet.
>> Then I would suggest posting your ideas about an extended driver
>> interface here so that we can discuss how to integrate it best into the
>> stack.
>>
> 
> Thanks for the hints.
> 
>> Out of curiosity: What is your scenario, your cycle frequency so that
>> you may need polling?
>>
> 
> We're at 8 kHz now with multiple packets per clock, but would like to get 
> as high as the hardware allows.  Since we know when the packets arrive, an 
> interrupt doesn't add anything useful.  It reduces determinism and even 
> causess trouble in some hardware configurations (interrupt arrives before 
> pci bus transfer is ready, leading to delayed packets.)

Yep, I see.

> 
> I was wondering if it makes sense to split RTnet into stack + HAL, or to add 
> some kind of hook that allows the stack to be bypassed, or adds a 
> plugin inbetween stack and HAL.
> 
> Instead of adding the suggested interrupt-less feature to the highlevel 
> code, it could be part of the raw packet HAL which we would then use 
> directly.

First of all, the stack is already fairly modular. You don't need to
load IP support, you don't need to insmod RTmac etc. Then, unless you
want to start hacking your application inside kernel space (generally
not recommended, e.g. when you need a non-GPL license), you still need
some user interface. And that's one feature the stack core provides.
Another is the management, of the device state and of buffer pools. So
there is not much to gain by cutting everything away above the driver,
but quite some stuff to be re-invented.

Jan

Re: [RTnet-developers] rtnet w. interrupts disabled

[Tom S. <to...@zw...>]

On Mon, Jan 19, 2009 at 09:27:58AM +0100, Jan Kiszka wrote:
> Tom Schouten wrote:
> > Hello,
> > 
> > Is it planned to have rtnet operate without network device interrupts?
> 
> Not yet.
> 
> > I.e. a non-blocking recv() call would query the card directly without 
> > buffering, leaving all read timing up to the application.
> 
> Note that this gets "tricky" if there is additional protocol handling
> required (like ARP, ICMP, UDP, RTmac, TDMA etc.) or if more than one
> thread is receiving data at the same time. The model only works
> straightforward if you do plain Ethernet access with users that all
> expect the polling mode.
> 

Yes.  We would use it only for exclusive raw ethernet access with a 
dedicated segment and completely predictable traffic.

> > 
> > If not planned, maybe you have some advice on how to implement this?
> > I'm currently looking into modifying the eepro100 driver, but maybe
> > there is a more highlevel way?
> 
> A definitely needs a high level handling as well because you always go
> through the stack to access a driver. As a first step, you may want to
> study Linux' NAPI interface and check what might be applicable to RTnet.
> Then I would suggest posting your ideas about an extended driver
> interface here so that we can discuss how to integrate it best into the
> stack.
> 

Thanks for the hints.

> Out of curiosity: What is your scenario, your cycle frequency so that
> you may need polling?
> 

We're at 8 kHz now with multiple packets per clock, but would like to get 
as high as the hardware allows.  Since we know when the packets arrive, an 
interrupt doesn't add anything useful.  It reduces determinism and even 
causess trouble in some hardware configurations (interrupt arrives before 
pci bus transfer is ready, leading to delayed packets.)

I was wondering if it makes sense to split RTnet into stack + HAL, or to add 
some kind of hook that allows the stack to be bypassed, or adds a 
plugin inbetween stack and HAL.

Instead of adding the suggested interrupt-less feature to the highlevel 
code, it could be part of the raw packet HAL which we would then use 
directly.

Re: [RTnet-developers] rtnet w. interrupts disabled

[Jan K. <jan...@we...>]

Tom Schouten wrote:
> Hello,
> 
> Is it planned to have rtnet operate without network device interrupts?

Not yet.

> I.e. a non-blocking recv() call would query the card directly without 
> buffering, leaving all read timing up to the application.

Note that this gets "tricky" if there is additional protocol handling
required (like ARP, ICMP, UDP, RTmac, TDMA etc.) or if more than one
thread is receiving data at the same time. The model only works
straightforward if you do plain Ethernet access with users that all
expect the polling mode.

> 
> If not planned, maybe you have some advice on how to implement this?
> I'm currently looking into modifying the eepro100 driver, but maybe
> there is a more highlevel way?

A definitely needs a high level handling as well because you always go
through the stack to access a driver. As a first step, you may want to
study Linux' NAPI interface and check what might be applicable to RTnet.
Then I would suggest posting your ideas about an extended driver
interface here so that we can discuss how to integrate it best into the
stack.

Out of curiosity: What is your scenario, your cycle frequency so that
you may need polling?

Jan

[RTnet-developers] rtnet w. interrupts disabled

[Tom S. <to...@zw...>]

Hello,

Is it planned to have rtnet operate without network device interrupts?
I.e. a non-blocking recv() call would query the card directly without 
buffering, leaving all read timing up to the application.

If not planned, maybe you have some advice on how to implement this?
I'm currently looking into modifying the eepro100 driver, but maybe
there is a more highlevel way?

Cheers,
Tom

Re: [RTnet-developers] race condition in e1000_xmit_frame ?

[Jan K. <jan...@we...>]

Frederik Bayart wrote:
> By releasing the lock after the e1000_tx_queue command, my problem was
> solved.
> 
>      e1000_tx_queue(adapter, tx_ring, tx_flags,
>                     e1000_tx_map(adapter, tx_ring, skb, first,
>                                  max_per_txd, nr_frags, mss),
>                     skb->xmit_stamp);
>      rtdm_lock_put_irqrestore(&tx_ring->tx_lock, context);

OK, thanks for reporting this issue and suggesting a fix. You can
finally find a patched version in SVN (#1197). Because e1000_xmit_frame
now calls e1000_tx_queue with IRQs disabled, I also dropped the IRQ
disabling from the latter.

Jan

Re: [RTnet-developers] race condition in e1000_xmit_frame ?

[Frederik B. <fb...@tr...>]

By releasing the lock after the e1000_tx_queue command, my problem was
solved.

     e1000_tx_queue(adapter, tx_ring, tx_flags,
                    e1000_tx_map(adapter, tx_ring, skb, first,
                                 max_per_txd, nr_frags, mss),
                    skb->xmit_stamp);
     rtdm_lock_put_irqrestore(&tx_ring->tx_lock, context);

Frederik

From: M. Koehrer <mathias_koehrer@ar...> - 2008-11-26 11:22
Hi Frederick,

I think you are right. This could be actually the source for a race
condition...
Even with the original Intel driver e1000-7.1.9 the code is clean.
Did you try to fix it? Did the driver run without issue?

Best regards

Mathias
>

Re: [RTnet-developers] race condition in e1000_xmit_frame ?

[M. K. <mat...@ar...>]

Hi Frederick,

I think you are right. This could be actually the source for a race condition...
Even with the original Intel driver e1000-7.1.9 the code is clean.
Did you try to fix it? Did the driver run without issue?

Best regards

Mathias
>
>Is it possible that there is a a race condition in the e1000 driver of
>rtnet ?
>
>At the end of the e1000_xmit_frame function in e1000_main.c, there is the
>following code :
>
>rtdm_lock_put_irqrestore(&tx_ring->tx_lock, context);
>first = tx_ring->next_to_use;
>
>if (likely(e1000_tx_csum(adapter, tx_ring, skb)))
>tx_flags |= E1000_TX_FLAGS_CSUM;
>
>e1000_tx_queue(adapter, tx_ring, tx_flags,
>e1000_tx_map(adapter, tx_ring, skb, first,
>max_per_txd, nr_frags, mss),
>skb->xmit_stamp);
>
>First, the tx_ring->tx_lock is released, then the tx_ring->next_to_use
>variable is incremented at the end of the e1000_tx_queue. This means that
>if there is a context switch in between, 2 processes are using the same
>tx_ring->buffer, which means that one of the rtskb's is not freed. This is
>what I noticed after adding some logging in the driver.
>
>According to me, the rtdm_lock_put_irqrestore should be done after the
>e1000_tx_queue. This is also what happens on in the e1000 driver in the
>linux source tree :
>
>e1000_tx_queue(adapter, tx_ring, tx_flags,
>e1000_tx_map(adapter, tx_ring, skb, first,
>max_per_txd, nr_frags, mss));
>
>netdev->trans_start = jiffies;
>
>/* Make sure there is space in the ring for the next send. */
>e1000_maybe_stop_tx(netdev, tx_ring, MAX_SKB_FRAGS + 2);
>
>spin_unlock_irqrestore(&tx_ring->tx_lock, flags);
>
>Can the responsible for the rtnet e1000 driver give some feedback about
>this ?
>
>Frederik 


-- 
Mathias Koehrer
mat...@ar...


Jetzt komfortabel bei Arcor-Digital TV einsteigen: Mehr Happy Ends, mehr Herzschmerz, mehr Fernsehen! Erleben Sie 50 digitale TV Programme und optional 60 Pay TV Sender, einen elektronischen Programmführer mit Movie Star Bewertungen von TV Movie. Außerdem, aktuelle Filmhits und spannende Dokus in der Arcor-Videothek. Infos unter www.arcor.de/tv

[RTnet-developers] race condition in e1000_xmit_frame ?

[<fre...@tr...>]

Hallo,

Is it possible that there is a a race condition in the e1000 driver of
rtnet ?

At the end of the e1000_xmit_frame function in e1000_main.c, there is the
following code :

     rtdm_lock_put_irqrestore(&tx_ring->tx_lock, context);
     first = tx_ring->next_to_use;

     if (likely(e1000_tx_csum(adapter, tx_ring, skb)))
       tx_flags |= E1000_TX_FLAGS_CSUM;

     e1000_tx_queue(adapter, tx_ring, tx_flags,
                    e1000_tx_map(adapter, tx_ring, skb, first,
                                 max_per_txd, nr_frags, mss),
                    skb->xmit_stamp);

First, the tx_ring->tx_lock is released, then the tx_ring->next_to_use
variable is incremented at the end of the e1000_tx_queue. This means that
if there is a context switch in between, 2 processes are using the same
tx_ring->buffer, which means that one of the rtskb's is not freed. This is
what I noticed after adding some logging in the driver.

According to me, the rtdm_lock_put_irqrestore should be done after the
e1000_tx_queue. This is also what happens on in the e1000 driver in the
linux source tree :

     e1000_tx_queue(adapter, tx_ring, tx_flags,
                    e1000_tx_map(adapter, tx_ring, skb, first,
                                 max_per_txd, nr_frags, mss));

     netdev->trans_start = jiffies;

     /* Make sure there is space in the ring for the next send. */
     e1000_maybe_stop_tx(netdev, tx_ring, MAX_SKB_FRAGS + 2);

     spin_unlock_irqrestore(&tx_ring->tx_lock, flags);

Can the responsible for the rtnet e1000 driver give some feedback about
this ?

Frederik

Re: [RTnet-developers] ask infomation about protocol analyzer.

[Rob G. <rg...@gm...>]

On Wed, Oct 15, 2008 at 6:46 PM, Li, Chanjuan <lic...@gm...>wrote:

> hi,all:
>      when you develope a new protocols from scratch like rtnet, do you
> use some kind of hardware protocol analyzer or something like that? If
> anyone uses, please give me specific infomation of the product you use.
> I am collecting product infomation to make a decision. thanks in
> advance.


Hi Lily,

On a day to day basis I think Wireshark (http://www.wireshark.org/) handles
just about everything i need it to.  Its not very often I need a piece of
hardware that is specifically designed to analyze network communication.  At
work we use SmartBits (
http://www.spirent.com/analysis/technology.cfm?media=7&ws=325&ss=110).  I'm
sure its expensive...  Hope that helps.

-Rob

[RTnet-developers] ask infomation about protocol analyzer.

[Li, C. <lic...@gm...>]

hi,all:
      when you develope a new protocols from scratch like rtnet, do you
use some kind of hardware protocol analyzer or something like that? If
anyone uses, please give me specific infomation of the product you use. 
I am collecting product infomation to make a decision. thanks in
advance.





lily

Re: [RTnet-developers] can I use netem on rtnet?

[Li C. <lic...@gm...>]

在 2008-09-01一的 22:45 +0200，Jan Kiszka写道：
> Li Chanjuan wrote:
> > hi,jan:
> >     
> >     I want to do a experiment on rtnet using netem and want to know that
> > how rtnet works when transmission error occurs. but after I setup rtnet,
> > I use:
> >   #tc qdisc add dev rteth0 root netem delay 1ms
> > there is error message: can't find "rteth0" device.
> > I use strace to find what happened, I got:
> > 
> > ioctl(4,SIOCGIFINDEX,{ifr_name="rteth0",..}) =-1(No such device)
> > 
> > I think this because rtnet is invisible to Linux, so tc can not work.
> 
> Exactly.
> 
> > 
> > Is it possible to use netem on rtnet? if it is, what should I do?
> 
> Nope, there is no (publicly known) implementation of a netem-like
> service on top of RTnet. However, it shouldn't be too tricky to write
> such support on top of RTnet's socket API.
> 
> On the other hand, I wonder why you need hard real-time guarantees for a
> "noise generator" like netem? Why is Linux itself unsuited?

what we interests is how rtnet will behave when there is communication
error. Now I redesign our experiement plan like this:
 ______        ________         _______
|       |      |       |        |      | 
| rtnet |----->|Linux  |------->| rtnet|
|_______|      |_______|        |______|

I use netem on the linux to simulate communication error between two
renet nodes. Then I will run some roundtrip test to see what happen.
Do you think such data make sence?


lily
thanks.

> 

Re: [RTnet-developers] Maintaining UDP sockets in a hash instead of a list.

[Jan K. <jan...@we...>]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Thanks, but... mind to integrate it into stack/include/rtnet_port.h?
>>
>> We can then ask Wolfgang to do some tests on 2.4.
> 
> Here it comes.

Thanks. I committed both pieces, finally.

Wolfgang, once you have some time, please check if latest SVN still
builds for Linux 2.4. We both lack appropriate test environments,
unfortunately. TiA.

Jan

Re: [RTnet-developers] can I use netem on rtnet?

[Jan K. <jan...@we...>]

Li Chanjuan wrote:
> hi,jan:
>     
>     I want to do a experiment on rtnet using netem and want to know that
> how rtnet works when transmission error occurs. but after I setup rtnet,
> I use:
>   #tc qdisc add dev rteth0 root netem delay 1ms
> there is error message: can't find "rteth0" device.
> I use strace to find what happened, I got:
> 
> ioctl(4,SIOCGIFINDEX,{ifr_name="rteth0",..}) =-1(No such device)
> 
> I think this because rtnet is invisible to Linux, so tc can not work.

Exactly.

> 
> Is it possible to use netem on rtnet? if it is, what should I do?

Nope, there is no (publicly known) implementation of a netem-like
service on top of RTnet. However, it shouldn't be too tricky to write
such support on top of RTnet's socket API.

On the other hand, I wonder why you need hard real-time guarantees for a
"noise generator" like netem? Why is Linux itself unsuited?

Jan

Re: [RTnet-developers] Maintaining UDP sockets in a hash instead of a list.

[Gilles C. <gil...@xe...>]

Jan Kiszka wrote:
> Thanks, but... mind to integrate it into stack/include/rtnet_port.h?
> 
> We can then ask Wolfgang to do some tests on 2.4.

Here it comes.

--- stack/include/rtnet_port.h~	2008-03-31 19:33:11.000000000 +0200
+++ stack/include/rtnet_port.h	2008-09-01 11:24:31.000000000 +0200
@@ -24,6 +24,7 @@
 
 #include <linux/bitops.h>
 #include <linux/moduleparam.h>
+#include <linux/list.h>
 
 #if 1
 #include <rtskb.h>
@@ -56,6 +57,56 @@
     module_param_array(name, int, NULL, 0444)
 #endif
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)
+# define LIST_POISON1  ((void *) 0x00100100)
+# define LIST_POISON2  ((void *) 0x00200200)
+
+struct hlist_head {
+	struct hlist_node *first;
+};
+
+struct hlist_node {
+	struct hlist_node *next, **pprev;
+};
+
+# define INIT_HLIST_HEAD(ptr) ((ptr)->first = NULL)
+
+static inline void __hlist_del(struct hlist_node *n)
+{
+	struct hlist_node *next = n->next;
+	struct hlist_node **pprev = n->pprev;
+	*pprev = next;
+	if (next)
+		next->pprev = pprev;
+}
+
+static inline void hlist_del(struct hlist_node *n)
+{
+	__hlist_del(n);
+	n->next = LIST_POISON1;
+	n->pprev = LIST_POISON2;
+}
+
+static inline void hlist_add_head(struct hlist_node *n, struct hlist_head *h)
+{
+	struct hlist_node *first = h->first;
+	n->next = first;
+	if (first)
+		first->pprev = &n->next;
+	h->first = n;
+	n->pprev = &h->first;
+}
+
+# define hlist_entry(ptr, type, member) \
+	((type *)((char *)(ptr) - (unsigned long)(&((type *)0)->member)))
+
+# define hlist_for_each_entry(tpos, pos, head, member)			 \
+	for (pos = (head)->first;					 \
+	     pos && ({ prefetch(pos->next); 1;}) &&			 \
+		({ tpos = hlist_entry(pos, typeof(*tpos), member); 1;}); \
+	     pos = pos->next)
+#endif
+
 static inline void rtnetif_start_queue(struct rtnet_device *rtdev)
 {
     clear_bit(__LINK_STATE_XOFF, &rtdev->state);

-- 
                                                 Gilles.