Hello -
As pointed out in another thread ("Problems after updating to DVEVM 1.10"
started by Andy ([EMAIL PROTECTED]), there seems to be problems
connecting a DVEVM to an ethernet "hub".
As I said in the other thread, I also had problems going through a 10/100
hub (half-duplex). There were MAJOR (several second) delays using the
NFS-mounted root filesystem when going through a 'hub' (but bypassing the
hub, it works fine).
I've experimented more, and found that this combination fails (is slow):
DVEVM -> HUB -> SWITCH -> PC
But this one works:
DVEVM -> SWITCH -> HUB -> SWITCH -> PC
The only difference in these two scenarios is that the DVEVM would be
talking 'half duplex' to the HUB in the first case, and talking 'full
duplex' to the SWITCH in the second case (and that SWITCH would talk 'half
duplex' to the HUB). If the HUB is introducing collisions/packet loss/etc,
it would be the same number of errors in both cases. But, the speed is
dramatically SLOWER when the DVEVM is directly connected to the HUB.
As Andy pointed out in the earlier thread, the kernel that came with DVSDK
"1.00" worked fine with a HUB, but the kernel with DVSDK "1.10" has this
problem (I've confirmed that here). I've also confirmed that a recent 'git'
kernel also has this slow-down with the HUB.
I believe I've found the problem, and have a fix. The change is to
"davinci_emac.c" in "driver/net". At line 3997 (function
"emac_update_phy_status()"), the original code (from DVSDK "1.10" source)
reads:
if (set_phy_mode & SNWAY_LPBK) {
dev->status.phy_duplex = 1;
} else {
dev->status.phy_duplex = emac_mdio_get_duplex();
}
The problem is that the code in "davinci_emac.c" treats
"dev->status.phy_duplex" as a 'boolean' : non-zero means full-duplex, and
zero means half duplex. The function "emac_mdio_get_duplex()" returns an
integer, with the following meanings:
0 - Auto-negotiate
1 - Unknown
2 - Half-duplex
3 - Full-duplex
So, there are three possible non-zero return value, but only one of them
("3") means full-duplex.
I've changed my copy of the code to this instead:
if (set_phy_mode & SNWAY_LPBK) {
dev->status.phy_duplex = 1;
} else {
dev->status.phy_duplex =
((emac_mdio_get_duplex() == 3) ? 1 : 0);
}
(Only set "dev->status.phy_duplex" to "1" if the emac_mdio_get_duplex()
return value is "3" (full-duplex). Otherwise, assume half-duplex).
Because collision detection/recovery is only enabled in the hardware in
'half duplex' mode, the 'bug' above meant that collisions were never
detected (you could see that from "ifconfig" output). With the above 'fix',
collisions are now detected/handled correctly.
I've only done limited testing on this 'fix'. I'd appreciate it if someone
else would give it a try/confirm my findings.
I hope this helps others having the same problem.
- Paulb
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
