Project Home
Project Home		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Networking/Discussion/Networking Drivers/Squelch Test Errors/List of Posts
Forum Topic - Squelch Test Errors: (6 Items)
   
Update
R Brown
11/02/2009 4:05 PM
post41185
Squelch Test Errors   
What is a squelch test error and how do I go about diagnosing and correcting the source of the problem?

Could it occur if I have a networked PC that mistakening did not defined a domain and a default gateway?
Hugh Brown
11/03/2009 7:56 AM
post41209
RE: Squelch Test Errors   
Squelch is normally a problem associated with noise or a signal
threshold and has nothing to do with system TCP/IP settings. What
network driver a re you running and what version of the O/S. The output
from 'nicinfo' would also help.


-----Original Message-----
From: R Brown [mailto:community-noreply@qnx.com] 
Sent: Monday, November 02, 2009 4:05 PM
To: drivers-networking
Subject: Squelch Test Errors

What is a squelch test error and how do I go about diagnosing and
correcting the source of the problem?

Could it occur if I have a networked PC that mistakening did not defined
a domain and a default gateway?





_______________________________________________

Networking Drivers
http://community.qnx.com/sf/go/post41185
Andrew Boyd(deleted)
11/03/2009 9:51 AM
post41221
RE: Squelch Test Errors   
Ahem (red face)

In the 6.4 (io-pkt) devnp-i82544.so and
devnp-e1000.so drivers, I overloaded the 
now-unused SQE counters with rx fifo overruns
which are NOT the same as "internal rx errors"
which on these drivers means it ran out of rx
descriptors (ring full).

The good news is that you can tell exactly
which error you are experiencing - previous
drivers simply added the two together for the
"internal rx errors" counter, which wasn't
very helpful, because the two have absolutely
nothing to do with each other, except that they
resulted in an rx packet being dropped.



--
aboyd
R Brown
11/03/2009 11:42 AM
post41233
Re: RE: Squelch Test Errors   
I am using QNX 6.4.1 and have a mix of nodes using devnp-e1000.so and devnp-i82554.so.

The nodes running devnp-e1000.so seem to capture large numbers of these errors but it takes > 8 hrs < 24 hours for the 
condition to occur and once it starts it just snowballs and renders all nodes on the network unaccessible (at least via 
human interface devices). 

The nodes running devnp-i82554.so do not register these errors but they seem to isolate themselves. I have to unplug the
 network cable and plug it back in for these to work.

Is there a way I can monitor the status of the rx fifo?
Andrew Boyd(deleted)
11/03/2009 2:53 PM
post41260
RE: RE: Squelch Test Errors   
> Is there a way I can monitor the status of the rx fifo?

Not quite sure what you mean.  Either the rx fifo
is overflowing, or it isn't - it's binary.  Each 
time the rx fifo overruns, the SQE counter will be
incremented in the nicinfo for the interface.

You don't really want a lot of rx fifo overruns, 
because each time that happens, you lost a packet,
which will cause a software protocol timeout, etc.

Devnp-i82544.so getting out of sync with the link
over time is a new one on me.  When it does, what
does nicinfo say about the link status?  Does it
think it is up, or down?  Is the speed and duplex
correct?  Speaking of that, I hope you aren't using
the speed and duplex options, which I detest.

If you start the devnp-i82544.so with the verbose
option, is there any more interesting information
in sloginfo when the link gets quiet?

What does the other end says about the link when
it gets quiet?

--
aboyd







_______________________________________________

Networking Drivers
http://community.qnx.com/sf/go/post41233
R Brown
11/04/2009 11:40 AM
post41328
Re: RE: RE: Squelch Test Errors   
> > Is there a way I can monitor the status of the rx fifo?
> 
> Not quite sure what you mean.  Either the rx fifo
> is overflowing, or it isn't - it's binary.  Each 
> time the rx fifo overruns, the SQE counter will be
> incremented in the nicinfo for the interface.
 

I was looking to see if there is a way to monitor the margin to FIFO overrun or maybe this happens so quickley that this
 functionality is useless.

Not sure if matters or not but we are using multicast communications.

 
> Devnp-i82544.so getting out of sync with the link
> over time is a new one on me.  When it does, what
> does nicinfo say about the link status?  Does it
> think it is up, or down?  Is the speed and duplex
> correct?  Speaking of that, I hope you aren't using
> the speed and duplex options, which I detest.

I simply swap devnp-e1000.so with devnp-i82544.so in the /etc/system/enum/devices/net file.

I can't recall if nicinfo reported LINK DOWN or not but I can definitely say it reported it was 0 Mbs and communication 
from the node was a no go.

> If you start the devnp-i82544.so with the verbose
> option, is there any more interesting information
> in sloginfo when the link gets quiet?

I won't be able to get back to testing this hardware for a few days. I will ensure I start the driver in versbose mode.

> What does the other end says about the link when
> it gets quiet?

I didn't think to check what the remote end was seeing. I will try this when I get the condition to re-occur.

- Richard

Return


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