I have an embedded cPCI system which has
the ethernet chip 21143 integrated onto the CPU
card. After witnessing occasional slow network
response, the Net.tulip driver was upgraded to the
latest available, 4.25P.
Now performance is okay for the first couple of
hours or so, then degrades noticeably thereafter.
If it is left to run idle overnight, the node eventually
becomes unreachable (“no route to host”), yet
running “alive” on the node indicates that the node
is still “up”.
The Net.tulip driver has a “-d” option to “Disable Rx
Errata Code”. This was introduced in Revision H,
the last revision before shipping with QNX 4.25.
Exercising the “-d” option does not improve the
performance problem.
In the 4.25P upgrade, a “tdump” utility was included
to provide an additional level of detail about the 21143
chip, allowing a user to report any anomalies back to
QSSL. In particular, information about the chip is
requested for any chip that is detected as being
“Generic PHY”
The 21143 chip on this CPU card was identified as
being “Generic PHY” by the “tdump” utility.
Does anyone know what “Generic PHY” means with
respect to the 21143 ethernet driver chip?
Has anyone encountered similar performance issues
as these, and were able to resolve them?
Thanks.
In article <9cv3q2$as4$1@inn.qnx.com>, pthomas@ise.bc.ca says…
I have an embedded cPCI system which has
the ethernet chip 21143 integrated onto the CPU
card. After witnessing occasional slow network
response, the Net.tulip driver was upgraded to the
latest available, 4.25P.
Now performance is okay for the first couple of
hours or so, then degrades noticeably thereafter.
If it is left to run idle overnight, the node eventually
becomes unreachable (“no route to host”), yet
running “alive” on the node indicates that the node
is still “up”.
The Net.tulip driver has a “-d” option to “Disable Rx
Errata Code”. This was introduced in Revision H,
the last revision before shipping with QNX 4.25.
Exercising the “-d” option does not improve the
performance problem.
In the 4.25P upgrade, a “tdump” utility was included
to provide an additional level of detail about the 21143
chip, allowing a user to report any anomalies back to
QSSL. In particular, information about the chip is
requested for any chip that is detected as being
“Generic PHY”
The 21143 chip on this CPU card was identified as
being “Generic PHY” by the “tdump” utility.
Does anyone know what “Generic PHY” means with
respect to the 21143 ethernet driver chip?
Yup! The 21143 needs an additional chip - the PHY chip - to actually
connect it to the physical (hence the PHY) medium. There are a whole
raft of these chips in two varieties. SYM PHYs and MII PHYs. There
should be no problem with SYM PHYs as they are cheap (and comparatively
dumb) chips. MII PHYs, however come from a number of different
manufacturers with a number of unique variations, but all based on the
MII interface standard(s). They also have a mechanism to allow software
to identify the actual manufacturer and model of MII PHY chip. Depending
on the model of MII PHY chip, the tulip driver must use certain pieces of
custom code to handle the differences.
If the MII chip is not known by the tulip code, you get the “Generic PHY”
situation. At this point code is used that is based on the common MII
standards only. Hopefully, this is enough to run the MII successfully,
but (depending on the specs of the MII PHY) may not be!
Has anyone encountered similar performance issues
as these, and were able to resolve them?
Have not seen this particular problem.
Thanks.
–
Stephen Munnings
Software Developer
Corman Technologies Inc.
Yup! The 21143 needs an additional chip - the PHY chip - to actually
connect it to the physical (hence the PHY) medium. There are a whole
raft of these chips in two varieties. SYM PHYs and MII PHYs. There
should be no problem with SYM PHYs as they are cheap (and comparatively
dumb) chips.
The CPU User’s Manual indicates that the Ethernet Physical Layer is
QS6611, which corresponds to SYM PHY. It seems odd, then, that
the “tdump” utility reports a “Generic PHY”.
In verbose mode, the Tulip driver reports the following:
Media Selected: MII MII - No Link
It would seem that the Tulip driver has not successfully identified the
physical layer chip.
The driver thinks its MII PHY when its actually SYM PHY, then it fails
to discover what kind of MII, so it defaults to “Generic PHY”