Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Jun 2004 09:32:56 -0400
From:      ming fu <fming@borderware.com>
To:        freebsd-net@freebsd.org
Subject:   FreeBSD em ether driver lockup
Message-ID:  <40D04C08.2080703@borderware.com>

next in thread | raw e-mail | index | archive | help
Hi,

I have experienced em driver lockup. One of a port on a multi-port Intel 
Gigbit card would lockup. It can be unlocked by
    #ifconfig em2 down
    #ifconfig em2 up

I beleive I have been hit by the same bug reported as kern/66634

Looking through the em driver code, I noticed the watchdog function is 
somewhat strange:

static void
em_watchdog(struct ifnet *ifp)
{
    struct adapter * adapter;
    adapter = ifp->if_softc;

    /* If we are in this routine because of pause frames, then
     * don't reset the hardware.
     */
    if (E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF) {
        ifp->if_timer = EM_TX_TIMEOUT;
        return;
    }

    if (em_check_for_link(&adapter->hw))
        printf("em%d: watchdog timeout -- resetting\n", adapter->unit);

    ifp->if_flags &= ~IFF_RUNNING;

    em_stop(adapter);
    em_init(adapter);

    ifp->if_oerrors++;
    return;
}


Would the
    if (E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)
ever be false on a configured device? I checked several other watchdog 
function of different ether device drivers (fxp, bge). All pretty much 
go straight to stop / init the device.

I think the watchdog is the last attempt the kernel try to bring back an 
interface, why subject this desperate action to a bit on the device's 
hardware? The hardware could be insane at the moment.

Is there a suggestion on how to trigger the watchdog to be called. It is 
really time consuming to diagnose this as it takes hours or dates for 
the em to lockup once.

Regards,
Ming




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40D04C08.2080703>