Hi:

FWIW:
> 18:01 < jcristau> <
> [email protected]> sounds like
> it might be worth fixing in stable
> 18:05 < bwh^> Should be fixed in d-i; noone promises that ETHTOOL_GLINK
> yields
>              0 or 1
> 18:06 < bwh^> Simple test for the ethtool API: does ethtool uses that
> feature?
>              if not, don't assume it works.
>
> Otavio, it seems this ought to be fixed on the d-i side?
>
> Cheers,
> Julien
>
>

I've solved the problem, it was not related to the bug in the kernel that I
mention in the last mail.
In the netcfg code, the ethtool code (in the ethtool-lite.c), doesn't wait
for "1", only for
"different from 0" (so it is not the problem):

[ethtool-lite.c from line 69]

    if (ioctl (fd, SIOCETHTOOL, &ifr) < 0)
        di_info("ethtool ioctl on %s failed\n", iface);

    if (edata.data)
    {
        di_info("%s is connected.\n", iface);
        return CONNECTED;
    }

(In the second if we can see that the problem is not the data (1 or 2) that
returns in the
SIOCETHTOOL ioctl).

The problem is that the time that lapses between up the interface, and
the card detects that the link is up is higer than the fixed usleep located
in netcfg.c, and the interface is not up after this usleep:

[netcfg.c from line 115]

                    interface_up(*ifaces);

                    usleep(250);

                    if (ethtool_lite (*ifaces) == 1) /* CONNECTED */ {
                        defiface = strdup(*ifaces);
                        interface_down(*ifaces);
                        break;
                    }

Increasing this usleep to a sleep of 2 seconds, the problem is fixed.

I've reproduced the problem in two 82573L net cards from two different
taiwaneese vendors
(Portwell and Nexcom).
This can be a concrete problem of the cards (a hardware problem), or
something related
of the driver with this chipset (I've reproduced with e1000e and e1000).

This is the lspci -n  line of the net card:

02:00.0 0200: 8086:109a

Sorry about sending the first mail without totally confirm the issue.

I don't know how to afford this, I've solved this problem in my custom
installers increasing the sleep
time, but, I don't know if this problem is only a card design problem or can
be something else.

BR:
Jon Ander Ortiz



> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCAAGBQJMocPTAAoJEDEBgAUJBeQMg7QQAIbwh6g9c5uwKtcnIW83Hh/i
> wwp+xtWTPo3413GVckBoy/G+jCW7JugsDd5Lt7/+tXiycj8V/oAE9CsNypoJUxLz
> oge4vdOhBj0cZ2b09rBmpIPFCqeuQwA73mxRIgjKfA9hCTEmHZnZow4c+dHcblo8
> Mk3ALfL2+w25gFLpeu7U4D13EDR+Ll3XljakEXTMaX7uc7p3MB3+82g0tbXOvMG/
> qPs4X8P+YCwYs1L3CUOmxRIW4hrzx6XDzqeW+hup0muxaHSoEdw5JpXKTMTKwBow
> wBw9MuAaNGMKzdMMhnxocSmspILS7ABJ7NKsmPuC+cbFVpfL8PVFCVZn5bJ6Ae83
> ZcTBXCIa6L5JIFkKVoefzd1Pywcpo6LgOY1sftzVY5Cil+fe6TrkUkO8G1NwHb2g
> o/7SsUpmPWMxfQhXWsx8cFSsGBYjil32Skvk7Xpeo3rB1pQVDHm2zAFyeA87uCvG
> /VCqK7TKlptmLfPzPjxrv6ugfLEAgAyMePWvLMzJJWgLCr8W8L3o7SAn0eRCNJrv
> H4LAK+nmxL0XVmliPcJo7wvxJBmcHm4cYuDMF/EE6Xk0epRr7bWMv2zS1T682RU9
> pxcO/WYBlqzk1m60pOMEekdrxzhoCLQNumsuH3/+3z2qucT+pOdOmQiIEp0o7ucv
> bBIHWSKSPrThMh6CjFFo
> =E3tY
> -----END PGP SIGNATURE-----
>
>

Reply via email to