Mario Charest
|
tx_down() returned -1, errno 255
|
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)
|
RE: tx_down() returned -1, errno 255
|
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
|
RE: tx_down() returned -1, errno 255
|
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)
|
RE: tx_down() returned -1, errno 255
|
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
|
RE: tx_down() returned -1, errno 255
|
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)
|
RE: tx_down() returned -1, errno 255
|
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
|
RE: tx_down() returned -1, errno 255
|
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)
|
RE: tx_down() returned -1, errno 255
|
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)
|
RE: tx_down() returned -1, errno 255
|
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
|
RE: tx_down() returned -1, errno 255
|
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
>
|
|
|
|