[gPXE] Intel NIC Link-state problem
Christopher Armenio
Christopher.Armenio at resquared.com
Fri Apr 16 10:00:51 EDT 2010
Marty,
I forgot to post this yesterday...
I fumbled around with some of the link checking code on my own and wound up
removing the
link state check. I compiled it and everything worked like a charm...here is
my simple change:
--- eepro100.c 2010-04-16 09:56:56.753307333 -0400
+++ /home/arsinio/Desktop/eepro100.c 2010-04-16 07:55:15.000000000 -0400
@@ -586,8 +586,7 @@
/* Check to see if network cable is plugged in. */
if ( ! ( ifec_mdio_read ( netdev, mdio_register & 0x1f, 1 )
& ( 1 << 2 ) ) ) {
-// return 0;
- return 1;
+ return 0;
}
return 1;
}
Let me know if you still want me to try your change. I'm not sure what
direction everyone
would like to take this development, be it removing link state checking, or
fixing the link
state checking problem. Either way, I'm more than willing to help with
finding a
permanent solution.
Thanks!
-Chris
On Fri, Apr 16, 2010 at 8:26 AM, Marty Connor <mdc at etherboot.org> wrote:
> Christopher Armenio wrote on 4/13/10 6:17 PM:
> > Hi there,
> > I seem to be having a problem getting gPXE to correctly interact with my
> > intel NIC (integrated intel eepro100). I believe gPXE is incorrectly
> > reporting the link as being down. There are both link and activity lights
> on
> > the physical interface, and I can see the RX counter incrementing using
> the
> > 'ifstat' command.
> >
> > Any thoughts/suggestions?
> > Thanks!
> > -Chris
>
> Hi Chris,
>
> If you are able to compile gPXE, could you make the following change and
> recompile:
>
> --- a/src/drivers/net/eepro100.c
> +++ b/src/drivers/net/eepro100.c
> @@ -600,6 +600,9 @@ static void ifec_link_update ( struct net_device
> *netdev )
> {
> DBGP ( "ifec_link_update\n" );
>
> + netdev_link_up ( netdev );
> + return;
> +
> /* Update link state */
> if ( ifec_link_check ( netdev ) )
> netdev_link_up ( netdev );
>
>
> -----------
>
> What this does is to assert that the link state is "up". I notice that
> most of our drivers don't do elaborate link state checking, but
> eepro100 does, and it appears that the card is reporting a value during
> that
> check that says the link is down, even if it is up.
>
> Since there's really nothing we can do if the link isn't up, I think the
> check is probably not needed.
>
> The patch above simply short-circuits the check for link, and always
> indicates
> to the core that link is up.
>
> If this patch works, we can just remove the extra link_state checking logic
> from src/drivers/net/eepro100.c, since other drivers don't do it, and it
> seems
> to cause a problem for some eepro100 cards.
>
> If editing and compiling this is a problem for you, I or someone else would
> be more than happy to make a test image for you.
>
> Thanks again for your help debugging this!
>
> / Marty /
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://etherboot.org/pipermail/gpxe/attachments/20100416/3b577d23/attachment.html
More information about the gPXE
mailing list