Project Home
Project Home		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Networking/Discussion/Technology/tx_down() returned -1, errno 255/List of Posts
Forum Topic - tx_down() returned -1, errno 255: (10 Items)
   
Update
Mario Charest
06/17/2009 4:31 PM
post32002
tx_down() returned -1, errno 255   
A system of ours has this qnet log all over the place.  I understand errno 255 is no buffer space but more info would 
help point me in the right direction.

This is with 6.3.2 e1000 driver running at 1Gig, tx description has been raised to 512.
Xiaodan Tang(deleted)
06/17/2009 4:35 PM
post32003
RE: tx_down() returned -1, errno 255   
Usually, the transmitting engine is halted for some reason, packets get
stuck in TX descript ring, once the ring is full, try to transmit will
result to a ENOBUF error.

-xtang

> -----Original Message-----
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: June 17, 2009 4:31 PM
> To: technology-networking
> Subject: tx_down() returned -1, errno 255
> 
> A system of ours has this qnet log all over the place.  I understand
errno
> 255 is no buffer space but more info would help point me in the right
> direction.
> 
> This is with 6.3.2 e1000 driver running at 1Gig, tx description has
been
> raised to 512.
> 
> 
> 
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post32002
Mario Charest
06/17/2009 4:41 PM
post32004
RE: tx_down() returned -1, errno 255   
 
> -----Original Message-----
> From: Xiaodan Tang [mailto:community-noreply@qnx.com]
> Sent: June-17-09 4:35 PM
> To: technology-networking
> Subject: RE: tx_down() returned -1, errno 255
> 
> Usually, the transmitting engine is halted for some reason, packets get
> stuck in TX descript ring, once the ring is full, try to transmit will
> result to a ENOBUF error.
> 


Given the tx descriptor has been raised to 512 it`s unlikely if not impossible that the software fills the buffer, the 
protocol (qnet) would have throttle it down right?  That would indicate the interrupt aren`t being received/generate?

What is odd is that we have tried two model of cards,  Intel 100Mbits with the speedo driver and Intel 1Gig with e1000 
driver with the same error.

> -xtang
> 
> > -----Original Message-----
> > From: Mario Charest [mailto:community-noreply@qnx.com]
> > Sent: June 17, 2009 4:31 PM
> > To: technology-networking
> > Subject: tx_down() returned -1, errno 255
> >
> > A system of ours has this qnet log all over the place.  I understand
> errno
> > 255 is no buffer space but more info would help point me in the right
> > direction.
> >
> > This is with 6.3.2 e1000 driver running at 1Gig, tx description has
> been
> > raised to 512.
> >
> >
> >
> > _______________________________________________
> > Technology
> > http://community.qnx.com/sf/go/post32002
> 
> 
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post32003
>
Andrew Boyd(deleted)
06/17/2009 4:51 PM
post32007
RE: tx_down() returned -1, errno 255   
> Given the tx descriptor has been raised to 512 
> it`s unlikely if not impossible that the software 
> fills the buffer

Not so.  I have seen a single IP transmit request come
down from the stack with 100 fragments (!).  Generally
most drivers will try to defrag such a silly request, 
but ...
 
Also, qnet will NOT pass down fragmented transmits
but it may pass down an awful lot of them, depending
upon what it is asked to do by the various clients
and servers.  IIRC procnto, when it is loading remote
executables, likes to read huge chunks.

I would try 4096 transmit descriptors to see if that
makes a difference.  I actually made that the default
on the now-deprecated devnp-i82544.so    :-)

--
aboyd    www.pittspecials.com/images/gat_t7.jpg
Mario Charest
06/18/2009 8:19 AM
post32028
RE: tx_down() returned -1, errno 255   

> -----Original Message-----
> From: Andrew Boyd [mailto:community-noreply@qnx.com]
> Sent: June-17-09 4:52 PM
> To: technology-networking
> Subject: RE: tx_down() returned -1, errno 255
> 
> 
> > Given the tx descriptor has been raised to 512
> > it`s unlikely if not impossible that the software
> > fills the buffer
> 
> Not so.  I have seen a single IP transmit request come
> down from the stack with 100 fragments (!).  Generally
> most drivers will try to defrag such a silly request,
> but ...
> 
> Also, qnet will NOT pass down fragmented transmits
> but it may pass down an awful lot of them, depending
> upon what it is asked to do by the various clients
> and servers.  IIRC procnto, when it is loading remote
> executables, likes to read huge chunks.
> 
> I would try 4096 transmit descriptors to see if that
> makes a difference.  I actually made that the default
> on the now-deprecated devnp-i82544.so    :-)

Setting number of transmit descriptor to 4096 solved the problem, thank you
 
> 
> --
> aboyd    www.pittspecials.com/images/gat_t7.jpg
> 
> 
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post32007
>
Andrew Boyd(deleted)
06/18/2009 4:44 PM
post32073
RE: tx_down() returned -1, errno 255   
 
> Setting number of transmit descriptor to 4096 solved the problem, thank you


Excellent.  We should probably create a PR to increase the default number

of transmit descriptors for both devn-e1000.so and devnp-e1000.so to at

least 1024.

I would personally prefer at least 2048 or even 4096, because it oesn't cost 

hardly any memory, unlike rx descriptors.

--

aboyd
Mario Charest
06/18/2009 4:49 PM
post32074
RE: tx_down() returned -1, errno 255   

> -----Original Message-----
> From: Andrew Boyd [mailto:community-noreply@qnx.com]
> Sent: June-18-09 4:44 PM
> To: technology-networking
> Subject: RE: tx_down() returned -1, errno 255
> 
> 
> > Setting number of transmit descriptor to 4096 solved the problem,
> thank you
> 
> 
> Excellent.  We should probably create a PR to increase the default
> number
> 
> of transmit descriptors for both devn-e1000.so and devnp-e1000.so to at
> 
> least 1024.
> 

Maybe also document what the error is about and how to fix it.  We had the same problem with the speedo driver.  As a 
matter of fact wouldn`t a slower link speed results in more of these errors?

> I would personally prefer at least 2048 or even 4096, because it oesn't
> cost
> 
> hardly any memory, unlike rx descriptors.
> 
> --
> 
> aboyd
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post32073
>
Weijie Zhang(deleted)
06/18/2009 4:52 PM
post32075
RE: tx_down() returned -1, errno 255   
Could it be PR68125? The netperf udp streaming shows many tx with
errors, E.g. nicinfo told "Memory Allocation Failures on Transmit .....
9008".

Thanks
Weijie


-----Original Message-----
From: Andrew Boyd [mailto:community-noreply@qnx.com] 
Sent: June 18, 2009 4:44 PM
To: technology-networking
Subject: RE: tx_down() returned -1, errno 255


 
> Setting number of transmit descriptor to 4096 solved the problem,
thank you


Excellent.  We should probably create a PR to increase the default
number

of transmit descriptors for both devn-e1000.so and devnp-e1000.so to at

least 1024.

I would personally prefer at least 2048 or even 4096, because it oesn't
cost 

hardly any memory, unlike rx descriptors.

--

aboyd

 

 



_______________________________________________
Technology
http://community.qnx.com/sf/go/post32073
Andrew Boyd(deleted)
06/17/2009 4:58 PM
post32008
RE: tx_down() returned -1, errno 255   
btw, another cause of the tx descriptor ring filling
up is that the remote end sent a pause frame, and asserted
flow control.

Generally, flow control should be enabled by the IEEE-standard
PHY auto-negotiation, if both ends support it, which is the
norm these days.

IIRC "ifconfig -v" will even tell you if flow control has
been enabled by PHY auto-negotiation (right of "media")
which is information which was never actually even output
by the nicinfo utility.

--
aboyd
Mario Charest
06/17/2009 5:02 PM
post32009
RE: tx_down() returned -1, errno 255   
Unfortunately it's 6.3.2

> -----Original Message-----
> From: Andrew Boyd [mailto:community-noreply@qnx.com]
> Sent: June-17-09 4:59 PM
> To: technology-networking
> Subject: RE: tx_down() returned -1, errno 255
> 
> 
> btw, another cause of the tx descriptor ring filling
> up is that the remote end sent a pause frame, and asserted
> flow control.
> 
> Generally, flow control should be enabled by the IEEE-standard
> PHY auto-negotiation, if both ends support it, which is the
> norm these days.
> 
> IIRC "ifconfig -v" will even tell you if flow control has
> been enabled by PHY auto-negotiation (right of "media")
> which is information which was never actually even output
> by the nicinfo utility.
> 
> --
> aboyd
> 
> 
> 
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post32008
>

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems