That did the trick! I recompiled the DVEVM 1.10 kernel with your patch and
I have no more ethernet issues when hooking up to the hub. Thanks!
Regards,
Andy
> 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
